Re: [boost] [xpressive] Performance Tuning?

Subject: Re: [boost] [xpressive] Performance Tuning?
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-07-30 19:46:50

On Thu, Jul 30, 2009 at 3:24 PM, Edward Grace<ej.grace_at_[hidden]> wrote:
>>> 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.
>
> With -Werror any warnings will be interpreted as errors.  If there are
> compilation errors it won't build the object / executable.
>
>> 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
>
> Hmm..  I've never come across that before.  It looks like it's flagging an
> error relating to something in the setup of the iterators for parse_qi.
>
>
>> 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!
>
> As a future tip it's better to remove -Werror if needed - that way you will
> still get any warnings - but they won't be mapped to errors.
>
>> 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!
>
> Hmm.  Very similar to my results - except for you strtol is slower than
> atoi.
>
>> 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...
>
> Indeed - an open issue.  Perhaps I will play with some other options (march
> etc.) to see if there's something I've overlooked.  Well, I have to say I'm
> gaining more respect for the MS compiler - I last used it a very long time
> ago, back then it was awful!
>

*scratches head*

I must be missing something very obvious, but I do not see how your
and OvermindDL benchmarks can support this conclusion: as far as I can
tell, you two never compared the two compilers directly, what you are
seeing is that on GCC the speed up of qi_parse over atoi/strtol is
less than that of MSVC, but this tells nothing about the absolute
performance of the two compilers on this test (i.e. you never showed
any absolute times).

For what we know the gcc atoi might just be faster than msvc one. And
in fact a quick google search brings these two pages:

  http://tinyurl.com/mqa5yl [msvc8 atoi performance is 58% of that of msvc6]
  http://tinyurl.com/mzyw66 [thread containing a comparison of atoi
functions of different languages and compilers, in particular it seems
that MSVC atoi is really 2 times slower than gcc atoi]

A slow atoi on MSVC would explain such a difference in the tests,
assuming that the ability of both compilers to optimize qi_parse is
about the same.

Finally, I see from the error messages that OvermindDL is using
gcc.3.4, which is now fairly old, maybe he should try with a more
recent one. Also -march=native or whatever architecture he is using
might help.

HTH,

-- 
gpd