Subject: Re: [boost] [xpressive] Performance Tuning? - was (Re: [regex] "I want everything" should build "out of the box"(onWindows))
From: Edward Grace (ej.grace_at_[hidden])
Date: 2009-07-29 11:17:29
>>> it seems (you
>>> said you were using GCC yes?).
>> Yes.... I wonder why am I starting to feel sheepish about that...
> Heh, I do have cygwin completely installed and fully updated on my
> computer here (the recommended beta version that uses gcc 4.3 as I
> recall) and I do have boost trunk (from a couple weeks ago anyway) in
> there and compiled for it. If you can tell me what command I need to
> type to compile the file with all necessary optimizations, I will do
> that here too.
* Your homed directory is $HOME
* Spirit2 is in $HOME/spirit21_root, which should contain boost/
* The latest Boost is in $HOME/boost_root, which should contain
* cycle.h is in the same directory as the file
* The ejg timer stuff is in $HOME/ejg_root, this should contain
the following stanza will work in bash (note the backslashes to break
the line), first we define some environment variables for legibility,
then fire up g++,
# ------ cut -----
g++ -DNDEBUG -O3 -ansi -pedantic -Wall -Wno-long-long -Werror \
-I$SPIRIT2 -I$BOOST -I$EJG -o ejg_uint_parser \
# ----- cut -------
The following is a synopsis of what the bits mean, in case it's not
-DNDEBUG -> equivalent to #define NDEBUG, should switch off any debug
parts of Boost
-O3 -> Optimisation level 3 - pretty much all in!
-ansi -> Require ANSI compliance of the language!
-pedantic -> Really really mean it!
-Wall -> Warn about everything (alegedly)
-Wno-long-long -> Do not warn about long long not being a mandated C+
+ standard type.
-Werror -> Convert warnings to errors
-I<blah> -> Include <blah> as a directory to search for include files
along with the standard locations.
-o <blah> -> Generate the binary file <blah>
I often forget about -DNDEBUG - this can have a significant impact
~10% for Spirit2 over atoi. Presumably you define NDEBUG when
compiling on Windows (or is that automatically assumed for 'Release'
> Since I will be running it on the exact same computer
> with the same OS, but different compilers, that will prove if it
> really is GCC being much slower then VC, or if they are near the same
> on my computer, then it is something else.
I await with trepidation....
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk