Re: [boost] [xpressive] Performance Tuning?

Subject: Re: [boost] [xpressive] Performance Tuning?
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-07-29 20:48:49

On Wed, Jul 29, 2009 at 9:17 AM, Edward Grace<ej.grace_at_[hidden]> wrote:
>>>
>>>> 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.
>
> Hi, assuming:
>
>  * Your homed directory is $HOME
>  * Spirit2 is in $HOME/spirit21_root, which should contain
> boost/spirit/actor.hpp
>  * The latest Boost is in $HOME/boost_root, which should contain
> boost/any.hpp
>  * cycle.h is in the same directory as the file
> ejg_uint_parser_0_0_4_bind_1.cpp
>  * The ejg timer stuff is in $HOME/ejg_root, this should contain
> ejg/timer.hpp
>
> 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 -----
>
> SPIRIT2=$HOME/spirit21_root
> BOOST=$HOME/boost_root
> EJG=$HOME/ejg_root
>
> g++ -DNDEBUG -O3 -ansi -pedantic -Wall -Wno-long-long -Werror \
>  -I$SPIRIT2 -I$BOOST -I$EJG -o ejg_uint_parser \
>  ejg_uint_parser_0_0_4_bind_1.cpp
>
>
> # ----- cut -------
>
> The following is a synopsis of what the bits mean, in case it's not obvious.
>
> -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' builds?).
>
>> 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....

Very useful info, thanks.  I altered slightly to support my setup,
since boost trunk is in the /etc/usr/lib or something like that, it is
picked up globally.  I tried compiling it multiple times, got the same
warning each time, never could find the output file.  Here is my
latest attempt, I tried fully qualified names, did not help:
OvermindDL1_at_overmind /cygdrive/s/cygwin/home/OvermindDL1/ejg_test
$ g++ -DNDEBUG -O3 -ansi -pedantic -Wall -Wno-long-long -Werror
-I/cygdrive/s/cygwin/home/OvermindDL1/ejg_test/other_includes -o
/cygdrive/s/cygwin/home/OvermindDL1/ejg_test/ejg_uint_parser
ejg_uint_parser_0_0_4_bind_1.cpp
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:
In copyconstructor `std::vector<_Tp, _Alloc>::vector(const
std::vector<_Tp, _Alloc>&) [with _Tp = std::string, _Alloc =
std::allocator<std::string>]':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82:
warning: '__cur' might be used uninitialized in this function

So I 'guess' it worked?  But I cannot find any file it created at all...

Hmm, I am going to try removing -Wall.
Yep!  It worked!
Executing it now, results:
Enter buffer size: 10000
initializing input strings...

Checking that the parsers are functioning  correctly...
atoi is behaving itself!
strtol is behaving itself!
qi is behaving itself!

Proceeding to timing tests.Calibrating overhead......done
Timer overhead (t_c) ~= : 9.67512
Jitter               ~= : 7.47951
qi_parse vs atoi     : 78.1417 81.6005 86.3038% faster.
qi_parse vs strtol  : 76.5284 85.2148 86.8329% faster.
strtol vs atoi       : -4.67955 -2.60676 -0.488886% faster.
qi_parse vs qi_parse : -0.900454 0.465715 1.85072% faster.

All done!

I ran the Visual Studio build again, still got about the same as I got
in my last email, so yea, Visual Studio is a lot better on templates
then GCC is.  I wonder why GCC performs so much worse...