[xpressive] Performance Tuning?

[OvermindDL1]

On Fri, Jul 17, 2009 at 8:07 PM, OvermindDL1<overminddl1@...> wrote:

> On Fri, Jul 17, 2009 at 6:35 PM, OvermindDL1<overminddl1@...> wrote:
>> /* snip */
>
> Okay, I cannot for the life of me get that above attached price.cpp
> file to compile.
> It is missing includes (apparently expressive needs something that I
> cannot find either).  It is missing a whole core:: namespace worth of
> functions that both the custom and the xpressive code reference.
> Other things too.  This code is completely worthless until someone
> gives me something complete that I can actually compile.
>

Okay, I finally got the xpressive version running, and I made a
threadsafe version of the spirit version and a grammar version of the
spirit version.  All I need now is some code of the original version
to get that working.  I also put in a high-resolution timer and a
testing setup.  Here is one run:
Loop count:  10000000
Parsing:  42.5
xpressive:  48.3714
spirit-quick(static):  2.73373
spirit-quick_new(threadsafe):  2.8916
spirit-grammar(threadsafe/reusable):  11.5694
Yes, 7 zero's, not 6, so this test is 10 times slower then what the
other email linked.
xpressive is about 50% faster then the times that other email gave, so
my compiler and processor probably optimize better and run faster.
The Spirit version, even the slowest method, blows it out of the water
though, to put it mildly.

So, if anyone can give me an actual USEFUL version of the above
price.cpp that someone else attached, then I can test the original
customized version.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Fri, Jul 17, 2009 at 11:32 PM, OvermindDL1<overminddl1@...> wrote:

> On Fri, Jul 17, 2009 at 8:07 PM, OvermindDL1<overminddl1@...> wrote:
>> On Fri, Jul 17, 2009 at 6:35 PM, OvermindDL1<overminddl1@...> wrote:
>>> /* snip */
>>
>> Okay, I cannot for the life of me get that above attached price.cpp
>> file to compile.
>> It is missing includes (apparently expressive needs something that I
>> cannot find either).  It is missing a whole core:: namespace worth of
>> functions that both the custom and the xpressive code reference.
>> Other things too.  This code is completely worthless until someone
>> gives me something complete that I can actually compile.
>>
>
> Okay, I finally got the xpressive version running, and I made a
> threadsafe version of the spirit version and a grammar version of the
> spirit version.  All I need now is some code of the original version
> to get that working.  I also put in a high-resolution timer and a
> testing setup.  Here is one run:
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  48.3714
> spirit-quick(static):  2.73373
> spirit-quick_new(threadsafe):  2.8916
> spirit-grammar(threadsafe/reusable):  11.5694

Er, correction, the grammar version I forgot to cache something,
making it much slower then it should have been.
Here are two other correct runs:

Loop count:  1000000
Parsing:  42.5
xpressive:  4.62519
spirit-quick(static):  0.27437
spirit-quick_new(threadsafe):  0.278761
spirit-grammar(threadsafe/reusable):  0.311138

Loop count:  10000000
Parsing:  42.5
xpressive:  46.1108
spirit-quick(static):  2.72641
spirit-quick_new(threadsafe):  2.84515
spirit-grammar(threadsafe/reusable):  3.1393

So yea, this looks a *lot* better.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Michael Caisse-2]

OvermindDL1 wrote:

> Er, correction, the grammar version I forgot to cache something,
> making it much slower then it should have been.
> Here are two other correct runs:
>
> Loop count:  1000000
> Parsing:  42.5
> xpressive:  4.62519
> spirit-quick(static):  0.27437
> spirit-quick_new(threadsafe):  0.278761
> spirit-grammar(threadsafe/reusable):  0.311138
>
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  46.1108
> spirit-quick(static):  2.72641
> spirit-quick_new(threadsafe):  2.84515
> spirit-grammar(threadsafe/reusable):  3.1393
>
> So yea, this looks a *lot* better.
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>  

Thank you for pulling this together. Would you mind sharing your test suite?


--

----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Eric Niebler-3]

Michael Caisse wrote:
> OvermindDL1 wrote:
>> Parsing:  42.5
<snip>
>> spirit-grammar(threadsafe/reusable):  3.1393
>
> Thank you for pulling this together. Would you mind sharing your test
> suite?

Yes, please. I know Spirit2 is great tech, but I have to wonder how it's
over 10X faster than the hand-coded parser.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Sat, Jul 18, 2009 at 2:13 AM, Eric Niebler<eric@...> wrote:

> Michael Caisse wrote:
>>
>> OvermindDL1 wrote:
>>>
>>> Parsing:  42.5
>
> <snip>
>>>
>>> spirit-grammar(threadsafe/reusable):  3.1393
>>
>> Thank you for pulling this together. Would you mind sharing your test
>> suite?

Er, I meant to attach it, it is attached now.  :)
It requires Boost trunk, and the timer file hpp I include is part of
the Boost.Spirit2.1 examples/test/somewhere_in_there area, but I
included it with my cpp file too so you do not need to hunt for it.
The defines at the top control what parts to compile or not, 0 to
disable compiling for that part, 1 to enable it.

My build is built with Visual Studio 8 (2005) with SP1.  Compiler
options are basically defaults, except getting rid of the secure crt
crap that Microsoft screwed up (enabling that crap slows down Spirit
parsers on my system, a *lot*).  The exe I built is in the 7zip file
attached.  As stated, I have heard that Visual Studio handles template
stuff like Spirit better then GCC, so I am very curious how GCC's
timings on this file would be.  There are still more changes to make
that I intend to make, but I really want the original code in a way
that I can use it.
To be honest, I had to change the core::to_number lines (commented
out) to boost::lexical_cast (right below the commented version), so
the xpressive version could be slightly faster if I actually had the
implementation of core::to_number available, and core::to_number was
well made.  The xpressive code also throws a nice 100 line long
warning in my build log, all just about a conversion warning from
double to int_64, no clue how to fix that, I do not know xpressive, so
I would gladly like it if someone could get rid of that nasty warning
in my nice clean buildlog.  In my compiler, my Spirit2.1 grammar
builds perfectly clean, I would like it if xpressive was the same way.

I honestly do not know *why* the Spirit version is so much faster then
the xpressive version, the spirit-quick version (the non-threadsafe) I
whipped up in about 2 minutes.  The threadsafe version took about 5
minutes, the grammar/threadsafe/reusable version took about 10
minutes, and I know a lot more work was put into the xpressive
version, especially with the auto macros added and all such as well.
I would love it if someone could find out way.  If someone else with
MSVC, and someone with GCC and perhaps other things could build it and
display the results that it prints out too, I would be much
appreciative.  I do have a linux computer here, but, to be honest, no
clue what to pass to gcc to build something, the command line switches
I pass to MSVC's version is rather monstrous, so trying to convert
that to GCC's seems nightmarish from my point of view.


On Sat, Jul 18, 2009 at 2:13 AM, Eric Niebler<eric@...> wrote:
> Yes, please. I know Spirit2 is great tech, but I have to wonder how it's
> over 10X faster than the hand-coded parser.
And I have not tested the hand-coded parser as I cannot get it to
compile.  If you can get me a code-complete standalone version of it,
I would be very happy.  :)

Either way, Windows users, could you please run the attached exe (that
is in the 7zip file) and paste the results it tells you in an email to
this thread, along with your windows version and basic hardware?

Before I attach this, I am going to run the release exe through a
profiler right quick.

With 1000000 iterations (one million so the xpressive version does not
take so long), with just the xpressive version enabled, the top 10
slowest functions:
CS:EIP   Symbol + Offset


                                                          64-bit CPU
clocks IPC   DC miss rate DTLB L1M L2M rate Misalign rate
        Mispredict rate
0x421860 strcmp


                                                                2248
      1.98 0             0                 0             0
0x42bc84 __strgtold12_l


                                                                1196
      1.1   0             0                 0.02           0.01
0x4068a0 std::operator<<<std::char_traits<char> >


                                                                744
      1.06 0             0                 0             0.02
0x41d864 TrailUpVec


                                                                686
      0.03 0.11         0                 0             0
0x40e0e0 std::num_get<char,std::istreambuf_iterator<char,std::char_traits<char>
> >::_Getffld

                                                      571
        0.94 0             0                 0             0.01
0x42d344 __mtold12


                                                                447
      2.2   0             0                 0             0
0x4170a0 std::basic_istream<char,std::char_traits<char> >::operator>>


                                                                406
      0.38 0             0                 0.05           0.08
0x414150 boost::xpressive::detail::posix_charset_matcher<boost::xpressive::cpp_regex_traits<char>
>::match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>
>,boost::xpressive::detail::static_xpression<boost::xpressive::detail::true_matcher,
                358         1.36 0             0                 0
    0
0x419231 std::_Lockit::~_Lockit


                                                                334
      0.26 0             0                 0             0
0x42b200 _ld12tod


                                                                333
      1.05 0             0                 0.01           0.01

10 functions, 700 instructions, Total: 48191 samples, 50.01% of
samples in the module, 31.99% of total session samples

So it looks like strcmp i massively hobbling it, taking almost twice
the time of the next highest user.  Now for 1000000 (one million) of
just the spirit quick version (all calls, surprisingly few):
CS:EIP   Symbol + Offset


                                                          64-bit CPU
clocks IPC   DC miss rate DTLB L1M L2M rate Misalign rate
        Mispredict rate
0x4188c9 _pow_pentium4


                                                                358
      1.04 0             0                 0             0
0x404d70 ??$phrase_parse@PBDU?$expr@Ubitwise_or@tag@proto@boost@@U?$list2@ABU?$expr@Ushift_right@tag@proto@boost@@U?$list2@ABU?$expr@Ushift_right@tag@proto@boost@@U?$list2@ABU?$expr@Usubscript@tag@proto@boost@@U?$list2@ABU?$terminal073d7121f2c9203b84cbac5f1ea1214c
          116         1.71 0             0                 0
        0
0x405080 boost::spirit::qi::detail::real_impl<double,boost::spirit::qi::real_policies<double>
>::parse<char const *,double>

                                        76         1.21 0
  0                 0             0
0x405f90 boost::spirit::qi::detail::extract_int<__int64,10,1,-1,boost::spirit::qi::detail::positive_accumulator<10>,0>::parse_main<char
const *,__int64>
                                                             
        68         2.35 0             0                 0             0
0x405550 boost::spirit::qi::detail::extract_int<double,10,1,-1,boost::spirit::qi::detail::positive_accumulator<10>,0>::parse_main<char
const *,double>
                                                               
        66         1.82 0             0                 0             0
0x4053e0 boost::spirit::qi::detail::`anonymous
namespace'::scale_number<double>


                63         1.14 0             0                 0
            0
0x404300 parse_price_spirit_quick<char const *>


                                                                62
      1.31 0             0                 0             0.03
0x4054e0 boost::spirit::qi::detail::fail_function<char const
*,boost::fusion::unused_type const
,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::spirit::char_encoding::ascii>
> >::operator()<boost::spirit::qi::action<boost:       59
        1.78 0             0                 0             0
0x404f30 boost::spirit::qi::skip_over<char const
*,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::spirit::char_encoding::ascii>
> >
                              58         1.59 0             0
            0             0
0x417b90 floor


                                                                48
      0.67 0             0                 0             0
0x417b16 _ftol2


                                                                46
      2.37 0             0                 0             0
0x4018f0 dotNumber


                                                                42
      0.86 0             0                 0             0
0x404fa0 boost::spirit::qi::action<boost::spirit::qi::real_parser_impl<double,boost::spirit::qi::real_policies<double>
>,void (__cdecl*)(double)>::parse<char const
*,boost::fusion::unused_type const
,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::s
                41         1.12 0             0                 0
    0
0x405660 boost::spirit::qi::detail::extract_int<double,10,1,-1,boost::spirit::qi::detail::positive_accumulator<10>,1>::parse_main<char
const *,double>
                                                               
        31         1.29 0             0                 0             0
0x417890 _CIpow


                                                                31
      1.68 0             0                 0             0
0x405af0 boost::spirit::qi::int_parser_impl<__int64,10,1,-1>::parse<char
const *,boost::fusion::unused_type const
,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::spirit::char_encoding::ascii>
>,__int64>                           29         0.48 0
        0                 0             0
0x405010 boost::spirit::qi::action<boost::spirit::qi::real_parser_impl<double,boost::spirit::qi::real_policies<double>
>,void (__cdecl*)(double)>::parse<char const
*,boost::fusion::unused_type const
,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::s
                27         1.04 0             0                 0
    0
0x4174c0 _allmul


                                                                27
      1     0             0                 0             0
0x405b60 boost::spirit::qi::not_predicate<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard,1,0>
>::parse<char const *,boost::fusion::unused_type const
,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::s
                25         1     0             0                 0
    0
0x404ec0 bo$phrase_parse@PBDU?$expr@Ubitwise_or@tag@proto@boost@@U?$list2@ABU?$expr@Ushift_right@tag@proto@boost@@U?$list2@ABU?$expr@Ushift_right@tag@proto@boost@@U?$list2@ABU?$expr@Usubscript@tag@proto@boost@@U?$list2@ABU?$terminal073d7121f2c9203b84cbac5f1ea1214c
          23         0.17 0             0                 0
        0.12
0x417bd0 _floor_pentium4


                                                                17
      0.24 0             0                 0             0
0x4188b0 _CIpow_pentium4


                                                                14
      0     0             0                 0             0
0x401970 main


                                                                9
      0.11 0             0                 0             0.3
0x404f10 boost::spirit::qi::skip_over<char const
*,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::spirit::char_encoding::ascii>
> >
                              4           0     0             0
            0             0
0x40cc02 _flsbuf


                                                                1
      0     0             0                 0             0
0x40e8b0 __SEH_prolog4


                                                                0
      0     0             0                 0             0

26 functions, 447 instructions, Total: 6513 samples, 100.00% of
samples in the module, 69.20% of total session samples


Now for the same, but with the spirit grammar version, since it is so
much slower then the quick for some reason (all calls again, not that
many):
CS:EIP   Symbol + Offset


                                                          64-bit CPU
clocks IPC   DC miss rate DTLB L1M L2M rate Misalign rate
        Mispredict rate
0x419909 _pow_pentium4


                                                                365
      0.97 0             0                 0             0
0x4056a0 boost::function4<bool,char const * &,char const * const
&,boost::spirit::context<boost::fusion::cons<__int64
&,boost::fusion::nil>,boost::fusion::vector0<void> >
&,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::sp
                129         1.19 0             0                 0
    0.02
0x405780 boost::detail::function::function_obj_invoker4<boost::spirit::qi::detail::parser_binder<boost::spirit::qi::alternative<boost::fusion::cons<boost::spirit::qi::reference<boost::spirit::qi::rule<char
const *,__int64 __cdecl(void),boost::proto::exprns_::expr<boos
        99         1.12 0             0                 0
        0.03
0x406f50 boost::spirit::qi::detail::extract_int<__int64,10,1,-1,boost::spirit::qi::detail::positive_accumulator<10>,0>::parse_main<char
const *,__int64>
                                                             
        81         1.28 0             0                 0             0
0x406100 boost::spirit::qi::detail::real_impl<double,boost::spirit::qi::real_policies<double>
>::parse<char const *,double>

                                        77         1.38 0
  0                 0             0
0x406bc0 boost::spirit::qi::rule<char const *,__int64
__cdecl(void),boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::spirit::char_encoding::ascii>
>,0>,boost::fusion::unu       77         0.87 0             0
            0             0.04
0x406c30 boost::spirit::qi::action<boost::spirit::qi::int_parser_impl<__int64,10,1,-1>,boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::assign_eval,boost::fusion::vector<boost::spirit::attribute<0>,boost::phoenix::composite<boost::phoenix::multiplies_ev
                74         1.61 0             0                 0
    0
0x406620 boost::spirit::qi::detail::extract_int<double,10,1,-1,boost::spirit::qi::detail::positive_accumulator<10>,0>::parse_main<char
const *,double>
                                                               
        64         1.22 0             0                 0             0
0x4050b0 boost::spirit::qi::phrase_parse<char const
*,price_grammar<char const
*>,boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::blank,boost::spirit::char_encoding::ascii>
>,0>,__in       56         0.29 0             0
        0             0.11
0x406460 boost::spirit::qi::detail::`anonymous
namespace'::scale_number<double>


                53         1.79 0             0                 0
            0
0x405810 boost::detail::function::function_obj_invoker4<boost::spirit::qi::detail::parser_binder<boost::spirit::qi::alternative<boost::fusion::cons<boost::spirit::qi::reference<boost::spirit::qi::rule<char
const *,__int64 __cdecl(void),boost::proto::exprns_::expr<boos
        52         1.98 0             0                 0
        0.02
0x418b56 _ftol2


                                                                50
      1.68 0             0                 0             0
0x401940 main


                                                                45
      0.67 0             0                 0             0.04
0x405fe0 boost::spirit::traits::action_dispatch<boost::spirit::qi::real_parser_impl<double,boost::spirit::qi::real_policies<double>
> >::operator()<dot_number_to_long_long_function,double,boost::spirit::context<boost::fusion::cons<__int64
&,boost::fusion::nil>,boost::       43         1.19 0
        0                 0             0
0x405f70 boost::spirit::qi::action<boost::spirit::qi::real_parser_impl<double,boost::spirit::qi::real_policies<double>
>,dot_number_to_long_long_function>::parse<char const
*,boost::spirit::context<boost::fusion::cons<__int64
&,boost::fusion::nil>,boost::fusion::vecto       41         0.83
        0             0                 0             0
0x405930 boost::detail::function::function_obj_invoker4<boost::spirit::qi::detail::parser_binder<boost::spirit::qi::action<boost::spirit::qi::real_parser_impl<double,boost::spirit::qi::real_policies<double>
>,dot_number_to_long_long_function>,boost::mpl::bool_<0> >,bo
        36         2     0             0                 0             0
0x418bd0 floor


                                                                34
      1.12 0             0                 0             0
0x405e60 boost::spirit::qi::action<boost::spirit::qi::real_parser_impl<double,boost::spirit::qi::real_policies<double>
>,dot_number_to_long_long_function>::parse<char const
*,boost::spirit::context<boost::fusion::cons<__int64
&,boost::fusion::nil>,boost::fusion::vecto       33         0.15
        0             0                 0             0.28
0x4182a0 _allmul


                                                                33
      3.42 0             0                 0             0
0x4188d0 _CIpow


                                                                27
      0.52 0             0                 0             0
0x406730 boost::spirit::qi::detail::extract_int<double,10,1,-1,boost::spirit::qi::detail::positive_accumulator<10>,1>::parse_main<char
const *,double>
                                                               
        26         2.62 0             0                 0             0
0x406560 boost::spirit::qi::int_parser_impl<__int64,10,1,-1>::parse<char
const *,boost::spirit::context<boost::fusion::cons<__int64
&,boost::fusion::nil>,boost::fusion::vector0<void>
>,boost::spirit::qi::char_class<boost::spirit::tag::char_code<boost::spirit::tag::bla
                19         0.16 0             0                 0
    0
0x418c10 _floor_pentium4


                                                                16
      0     0             0                 0             0
0x406ca0 boost::spirit::qi::not_predicate<boost::spirit::qi::literal_char<boost::spirit::char_encoding::standard,1,0>
>::parse<char const
*,boost::spirit::context<boost::fusion::cons<__int64
&,boost::fusion::nil>,boost::fusion::vector0<void>
>,boost::spirit::qi::char_       11         0.36 0             0
                0             0
0x4198f0 _CIpow_pentium4


                                                                11
      0     0             0                 0             0
0x40b090 _flush


                                                                1
      0     0             0                 0             0

26 functions, 451 instructions, Total: 7342 samples, 100.00% of
samples in the module, 71.73% of total session samples



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Eric Niebler-3]

OvermindDL1 wrote:
> To be honest, I had to change the core::to_number lines (commented
> out) to boost::lexical_cast (right below the commented version), so
> the xpressive version could be slightly faster if I actually had the
> implementation of core::to_number available, and core::to_number was
> well made.

This could very well be the source of a major slow-down. Doesn't
lexical_cast use string streams to do the conversion? It seems to me
that you're comparing apples to oranges.

Also, the warning you saw came from the user-created semantic action,
not from xpressive.

Robert, can you please post your complete code so that we can actually
have meaningful numbers to look at? Thanks.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Bytheway-2]

OvermindDL1 wrote:
<snip>
> As stated, I have heard that Visual Studio handles template
> stuff like Spirit better then GCC, so I am very curious how GCC's
> timings on this file would be.

Alas, gcc doesn't do so well.  I had to make a few tweaks to your code
(you typedefed int64_t at global scope which clashes with the one in the
C library headers, and you used an INT64 macro which doesn't exist here)
but then I got a very long error ending with this:

.../boost-trunk/boost/proto/transform/call.hpp:146: internal compiler
error: Segmentation fault

I guess the metaprogramming is too much for it :(.

That was with -O3 -DNDEBUG -march=native and gcc version:
gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3


So then I tried icc 10.1 (essentially same options) which takes over a
minute to compile this, but does succeed.  With that I got:

$ ./price-icc
Loop count:  10000000
Parsing:  42.5
xpressive:  27.4704
spirit-quick(static):  1.58132
spirit-quick_new(threadsafe):  1.52971
spirit-grammar(threadsafe/reusable):  1.64666

which are much the same as your results (except ~1.7 times faster all
round), but the Parsing result is obviously meaningless and the
xpressive also dubious because of lexical_cast.

I then tried with icc's inter-procedural optimisations turned on too,
which improves the xpressive code significantly, but doesn't obviously
affect spirit:

$ ./price-icc-ipo
Loop count:  10000000
Parsing:  42.5
xpressive:  17.3577
spirit-quick(static):  1.52487
spirit-quick_new(threadsafe):  1.51834
spirit-grammar(threadsafe/reusable):  1.65164

Finally I used static linking, and the xpressive time improved again,
and maybe the others a little.  This surprised me.

$ ./price-icc-ipo-static
Loop count:  10000000
Parsing:  42.5
xpressive:  12.6157
spirit-quick(static):  1.49887
spirit-quick_new(threadsafe):  1.48146
spirit-grammar(threadsafe/reusable):  1.62731

John Bytheway

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Sat, Jul 18, 2009 at 9:15 AM, Eric Niebler<eric@...> wrote:

> OvermindDL1 wrote:
>>
>> To be honest, I had to change the core::to_number lines (commented
>> out) to boost::lexical_cast (right below the commented version), so
>> the xpressive version could be slightly faster if I actually had the
>> implementation of core::to_number available, and core::to_number was
>> well made.
>
> This could very well be the source of a major slow-down. Doesn't
> lexical_cast use string streams to do the conversion? It seems to me that
> you're comparing apples to oranges.

Yes, as I complained about multiple times in this thread about people
not posting complete code snippets, what am I supposed to make of a
function call that does not exist?


On Sat, Jul 18, 2009 at 1:51 PM, John Bytheway<jbytheway+boost@...> wrote:

> OvermindDL1 wrote:
> <snip>
>> As stated, I have heard that Visual Studio handles template
>> stuff like Spirit better then GCC, so I am very curious how GCC's
>> timings on this file would be.
>
> Alas, gcc doesn't do so well.  I had to make a few tweaks to your code
> (you typedefed int64_t at global scope which clashes with the one in the
> C library headers, and you used an INT64 macro which doesn't exist here)
> but then I got a very long error ending with this:
>
> .../boost-trunk/boost/proto/transform/call.hpp:146: internal compiler
> error: Segmentation fault
>
> I guess the metaprogramming is too much for it :(.
>
> That was with -O3 -DNDEBUG -march=native and gcc version:
> gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3

I do not get that, GCC usually handles more templates then MSVC ever
has, just usually not as optimized, so I do not understand how you
could be getting a compiler error.


On Sat, Jul 18, 2009 at 1:51 PM, John Bytheway<jbytheway+boost@...> wrote:

> So then I tried icc 10.1 (essentially same options) which takes over a
> minute to compile this, but does succeed.  With that I got:
>
> $ ./price-icc
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  27.4704
> spirit-quick(static):  1.58132
> spirit-quick_new(threadsafe):  1.52971
> spirit-grammar(threadsafe/reusable):  1.64666
>
> which are much the same as your results (except ~1.7 times faster all
> round), but the Parsing result is obviously meaningless and the
> xpressive also dubious because of lexical_cast.
>
> I then tried with icc's inter-procedural optimisations turned on too,
> which improves the xpressive code significantly, but doesn't obviously
> affect spirit:
>
> $ ./price-icc-ipo
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  17.3577
> spirit-quick(static):  1.52487
> spirit-quick_new(threadsafe):  1.51834
> spirit-grammar(threadsafe/reusable):  1.65164
>
> Finally I used static linking, and the xpressive time improved again,
> and maybe the others a little.  This surprised me.
>
> $ ./price-icc-ipo-static
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  12.6157
> spirit-quick(static):  1.49887
> spirit-quick_new(threadsafe):  1.48146
> spirit-grammar(threadsafe/reusable):  1.62731

Regardless, all of these numbers and times are vastly higher then what
the previous person posted, so very nice.  We just need the compilable
original code to see how it compares now.

Hmm, I might try to replace all the lexical_cast's with a spirit
parser for just that number, for a single extraction like that, Spirit
compiles to *very* little assembly, quite impressive actually.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> >> OvermindDL1 wrote:
> >>>
> >>> Parsing:  42.5
> >
> > <snip>
> >>>
> >>> spirit-grammar(threadsafe/reusable):  3.1393
> >>
> >> Thank you for pulling this together. Would you mind sharing your
> test
> >> suite?
>
> Er, I meant to attach it, it is attached now.  :) It requires Boost
> trunk, and the timer file hpp I include is part of the Boost.Spirit2.1
> examples/test/somewhere_in_there area, but I included it with my cpp
> file too so you do not need to hunt for it.
> The defines at the top control what parts to compile or not, 0 to
> disable compiling for that part, 1 to enable it.
>
> My build is built with Visual Studio 8 (2005) with SP1.  Compiler
> options are basically defaults, except getting rid of the secure crt
> crap that Microsoft screwed up (enabling that crap slows down Spirit
> parsers on my system, a *lot*).  The exe I built is in the 7zip file
> attached.  As stated, I have heard that Visual Studio handles template
> stuff like Spirit better then GCC, so I am very curious how GCC's
> timings on this file would be.  There are still more changes to make
> that I intend to make, but I really want the original code in a way
> that I can use it.
> To be honest, I had to change the core::to_number lines (commented
> out) to boost::lexical_cast (right below the commented version), so the
> xpressive version could be slightly faster if I actually had the
> implementation of core::to_number available, and core::to_number was
> well made.  The xpressive code also throws a nice 100 line long warning
> in my build log, all just about a conversion warning from double to
> int_64, no clue how to fix that, I do not know xpressive, so I would
> gladly like it if someone could get rid of that nasty warning in my
> nice clean buildlog.  In my compiler, my Spirit2.1 grammar builds
> perfectly clean, I would like it if xpressive was the same way.

Here are my results (platform: Windows7, Intel Core Duo(tm) Processor,
2.8GHz, 4GByte RAM), I reduced the number of iterations to 1e6.

VC8SP1/32Bit
Loop count:  1000000
Parsing:  42.5
xpressive:  4.53867
spirit-quick(static):  0.213174
spirit-quick_new(threadsafe):  0.255517
spirit-grammar(threadsafe/reusable):  0.228167

VC10 beta/32Bit:
Loop count:  1000000
Parsing:  42.5
xpressive:  4.68044
spirit-quick(static):  0.245641
spirit-quick_new(threadsafe):  0.279981
spirit-grammar(threadsafe/reusable):  0.252697

VC10 beta/64Bit:
Loop count:  1000000
Parsing:  42.5
xpressive:  3.7877
spirit-quick(static):  0.17625
spirit-quick_new(threadsafe):  0.175377
spirit-grammar(threadsafe/reusable):  0.137707

gcc 4.4.1 (MinGW)/32bit
Loop count:  1000000
Parsing:  42.5
xpressive:  13.5003
spirit-quick(static):  0.274027
spirit-quick_new(threadsafe):  0.261029
spirit-grammar(threadsafe/reusable):  0.325813

gcc 4.4.1 (MinGW)/64bit
Loop count:  1000000
Parsing:  42.5
xpressive:  10.2381
spirit-quick(static):  0.0868965
spirit-quick_new(threadsafe):  0.0820163
spirit-grammar(threadsafe/reusable):  0.228892

Regards Hartmut




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Sat, Jul 18, 2009 at 7:50 PM, Hartmut Kaiser<hartmut.kaiser@...> wrote:

>> >> OvermindDL1 wrote:
>> >>>
>> >>> Parsing:  42.5
>> >
>> > <snip>
>> >>>
>> >>> spirit-grammar(threadsafe/reusable):  3.1393
>> >>
>> >> Thank you for pulling this together. Would you mind sharing your
>> test
>> >> suite?
>>
>> Er, I meant to attach it, it is attached now.  :) It requires Boost
>> trunk, and the timer file hpp I include is part of the Boost.Spirit2.1
>> examples/test/somewhere_in_there area, but I included it with my cpp
>> file too so you do not need to hunt for it.
>> The defines at the top control what parts to compile or not, 0 to
>> disable compiling for that part, 1 to enable it.
>>
>> My build is built with Visual Studio 8 (2005) with SP1.  Compiler
>> options are basically defaults, except getting rid of the secure crt
>> crap that Microsoft screwed up (enabling that crap slows down Spirit
>> parsers on my system, a *lot*).  The exe I built is in the 7zip file
>> attached.  As stated, I have heard that Visual Studio handles template
>> stuff like Spirit better then GCC, so I am very curious how GCC's
>> timings on this file would be.  There are still more changes to make
>> that I intend to make, but I really want the original code in a way
>> that I can use it.
>> To be honest, I had to change the core::to_number lines (commented
>> out) to boost::lexical_cast (right below the commented version), so the
>> xpressive version could be slightly faster if I actually had the
>> implementation of core::to_number available, and core::to_number was
>> well made.  The xpressive code also throws a nice 100 line long warning
>> in my build log, all just about a conversion warning from double to
>> int_64, no clue how to fix that, I do not know xpressive, so I would
>> gladly like it if someone could get rid of that nasty warning in my
>> nice clean buildlog.  In my compiler, my Spirit2.1 grammar builds
>> perfectly clean, I would like it if xpressive was the same way.
>
> Here are my results (platform: Windows7, Intel Core Duo(tm) Processor,
> 2.8GHz, 4GByte RAM), I reduced the number of iterations to 1e6.
>
> VC8SP1/32Bit
> Loop count:  1000000
> Parsing:  42.5
> xpressive:  4.53867
> spirit-quick(static):  0.213174
> spirit-quick_new(threadsafe):  0.255517
> spirit-grammar(threadsafe/reusable):  0.228167
>
> VC10 beta/32Bit:
> Loop count:  1000000
> Parsing:  42.5
> xpressive:  4.68044
> spirit-quick(static):  0.245641
> spirit-quick_new(threadsafe):  0.279981
> spirit-grammar(threadsafe/reusable):  0.252697
>
> VC10 beta/64Bit:
> Loop count:  1000000
> Parsing:  42.5
> xpressive:  3.7877
> spirit-quick(static):  0.17625
> spirit-quick_new(threadsafe):  0.175377
> spirit-grammar(threadsafe/reusable):  0.137707
>
> gcc 4.4.1 (MinGW)/32bit
> Loop count:  1000000
> Parsing:  42.5
> xpressive:  13.5003
> spirit-quick(static):  0.274027
> spirit-quick_new(threadsafe):  0.261029
> spirit-grammar(threadsafe/reusable):  0.325813
>
> gcc 4.4.1 (MinGW)/64bit
> Loop count:  1000000
> Parsing:  42.5
> xpressive:  10.2381
> spirit-quick(static):  0.0868965
> spirit-quick_new(threadsafe):  0.0820163
> spirit-grammar(threadsafe/reusable):  0.228892
>
> Regards Hartmut

Very nice and detailed, thanks.

I just changed the file to use spirit for parsing where I had used
lexical_cast got very different timings for xpressive now, so now,
with xpressive using a bit of spirit I get:
Loop count:  10000000
Parsing:  42.5
xpressive:  15.4841
spirit-quick(static):  3.01117
spirit-quick_new(threadsafe):  3.10548
spirit-grammar(threadsafe/reusable):  3.81694

Vast increase, 3x faster xpressive is now.
Also, how do you fix that rather bloody massive warning about
double->int64 truncation?
I also changed all int64_t to boost::long_long_type since they are the
same thing anyway (on 32-bit at least?), as well as it being
multi-platform unlike int64_t.
My changed file is attached.  Do not know if this is considered
cheating now that xpressive is using some spirit now.  ;-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Bytheway-2]

OvermindDL1 wrote:

> I just changed the file to use spirit for parsing where I had used
> lexical_cast got very different timings for xpressive now, so now,
> with xpressive using a bit of spirit I get:
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  15.4841
> spirit-quick(static):  3.01117
> spirit-quick_new(threadsafe):  3.10548
> spirit-grammar(threadsafe/reusable):  3.81694
>
> Vast increase, 3x faster xpressive is now.
> Also, how do you fix that rather bloody massive warning about
> double->int64 truncation?
> I also changed all int64_t to boost::long_long_type since they are the
> same thing anyway (on 32-bit at least?), as well as it being
> multi-platform unlike int64_t.
> My changed file is attached.  Do not know if this is considered
> cheating now that xpressive is using some spirit now.  ;-)

That one doesn't compile for me.  On line 402:

boost::spirit::qi::parse(va.begin(), va.end(),
boost::spirit::double_[boost::phoenix::ref(value)]);

I get

no instance of overloaded function "boost::spirit::qi::parse" matches
the argument list

(and the same on all the similar lines)

and indeed I see can't see an appropriate overload in the spirit headers
(in boost trunk), but it's hard to be sure since there are so many
functions called parse!

John Bytheway

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Sun, Jul 19, 2009 at 2:29 AM, John Bytheway<jbytheway+boost@...> wrote:

> OvermindDL1 wrote:
>> I just changed the file to use spirit for parsing where I had used
>> lexical_cast got very different timings for xpressive now, so now,
>> with xpressive using a bit of spirit I get:
>> Loop count:  10000000
>> Parsing:  42.5
>> xpressive:  15.4841
>> spirit-quick(static):  3.01117
>> spirit-quick_new(threadsafe):  3.10548
>> spirit-grammar(threadsafe/reusable):  3.81694
>>
>> Vast increase, 3x faster xpressive is now.
>> Also, how do you fix that rather bloody massive warning about
>> double->int64 truncation?
>> I also changed all int64_t to boost::long_long_type since they are the
>> same thing anyway (on 32-bit at least?), as well as it being
>> multi-platform unlike int64_t.
>> My changed file is attached.  Do not know if this is considered
>> cheating now that xpressive is using some spirit now.  ;-)
>
>
> That one doesn't compile for me.  On line 402:
>
> boost::spirit::qi::parse(va.begin(), va.end(),
> boost::spirit::double_[boost::phoenix::ref(value)]);
>
> I get
>
> no instance of overloaded function "boost::spirit::qi::parse" matches
> the argument list
>
> (and the same on all the similar lines)
>
> and indeed I see can't see an appropriate overload in the spirit headers
> (in boost trunk), but it's hard to be sure since there are so many
> functions called parse!

You are running Boost Trunk?  Compiles fine here in MSVC, and I last
synced to trunk less then a week ago.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel de Guzman-2]

OvermindDL1 wrote:

> I just changed the file to use spirit for parsing where I had used
> lexical_cast got very different timings for xpressive now, so now,
> with xpressive using a bit of spirit I get:
> Loop count:  10000000
> Parsing:  42.5
> xpressive:  15.4841
> spirit-quick(static):  3.01117
> spirit-quick_new(threadsafe):  3.10548
> spirit-grammar(threadsafe/reusable):  3.81694
>
> Vast increase, 3x faster xpressive is now.
> Also, how do you fix that rather bloody massive warning about
> double->int64 truncation?
> I also changed all int64_t to boost::long_long_type since they are the
> same thing anyway (on 32-bit at least?), as well as it being
> multi-platform unlike int64_t.
> My changed file is attached.  Do not know if this is considered
> cheating now that xpressive is using some spirit now.  ;-)

This is somewhat cheating. We've tuned the numeric parsers of Spirit
with TMP tricks, loop unrolling, etc. Those are very finely tuned
numeric parsers you see there that beats the fastest C code such as
strtol and atoi. The following benchmarks reveal 2X+ speed against
low level strtol and atoi (attached). I am getting:

   atoi: 0.82528 [s]
   strtol: 0.792227 [s]
   int_: 0.358016 [s]

The first and second are the low-level C routines. The third is
Spirit's int_ parser. I need not mention that the C routines only
accept C strings while the Spirit int_ parser can accept any
forward iterator. So, in a sense, we're comparing apples and
oranges. But this goes to show that you can write highly optimized
code in generic C++.

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

/*=============================================================================
    Copyright (c) 2001-2009 Joel de Guzman

    Distributed under the Boost Software License, Version 1.0. (See accompanying
    file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
=============================================================================*/
#if defined(BOOST_MSVC)
#pragma inline_depth(255)
#pragma inline_recursion(on)
#define _SECURE_SCL 0
#endif // defined(BOOST_MSVC)

#include "../high_resolution_timer.hpp"
#include <boost/spirit/include/qi.hpp>
#include <boost/lexical_cast.hpp>
#include <climits>
#include <cstdlib>
#include <string>
#include <vector>

#define MAX_ITERATION 10000000

void check(int a, int b)
{
    if (a != b)
    {
        std::cout << "Parse Error" << std::endl;
        abort();
    }
}

int main()
{
    namespace qi = boost::spirit::qi;
    using qi::int_;
   
    std::cout << "initializing input strings..." << std::endl;
    std::vector<int> src(MAX_ITERATION);
    std::vector<std::string> src_str(MAX_ITERATION);
    for (int i = 0; i < MAX_ITERATION; ++i)
    {
        src[i] = std::rand() * std::rand();
        src_str[i] = boost::lexical_cast<std::string>(src[i]);
    }
   
    std::vector<int> v(MAX_ITERATION);

    // test the C libraries atoi function (the most low level function for
    // string conversion available)
    {
        util::high_resolution_timer t;

        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            v[i] = atoi(src_str[i].c_str());
        }

        std::cout << "atoi: " << t.elapsed() << " [s]" << std::flush << std::endl;
       
        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            check(v[i], src[i]);
        }
    }
   
    // test the C libraries strtol function (the most low level function for
    // string conversion available)
    {
        util::high_resolution_timer t;

        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            v[i] = strtol(src_str[i].c_str(), 0, 10);
        }

        std::cout << "strtol: " << t.elapsed() << " [s]" << std::flush << std::endl;
       
        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            check(v[i], src[i]);
        }
    }
   
    // test the Qi int_ parser routines
    {
        std::vector<char const*> f(MAX_ITERATION);
        std::vector<char const*> l(MAX_ITERATION);

        // get the first/last iterators
        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            f[i] = src_str[i].c_str();
            l[i] = f[i];
            while (*l[i])
                l[i]++;
        }
   
        util::high_resolution_timer t;

        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            qi::parse(f[i], l[i], int_, v[i]);
        }

        std::cout << "int_: " << t.elapsed() << " [s]" << std::flush << std::endl;
       
        for (int i = 0; i < MAX_ITERATION; ++i)
        {
            check(v[i], src[i]);
        }
    }

    return 0;
}


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel de Guzman-2]

Joel de Guzman wrote:

> OvermindDL1 wrote:
>
>> I just changed the file to use spirit for parsing where I had used
>> lexical_cast got very different timings for xpressive now, so now,
>> with xpressive using a bit of spirit I get:
>> Loop count:  10000000
>> Parsing:  42.5
>> xpressive:  15.4841
>> spirit-quick(static):  3.01117
>> spirit-quick_new(threadsafe):  3.10548
>> spirit-grammar(threadsafe/reusable):  3.81694
>>
>> Vast increase, 3x faster xpressive is now.
>> Also, how do you fix that rather bloody massive warning about
>> double->int64 truncation?
>> I also changed all int64_t to boost::long_long_type since they are the
>> same thing anyway (on 32-bit at least?), as well as it being
>> multi-platform unlike int64_t.
>> My changed file is attached.  Do not know if this is considered
>> cheating now that xpressive is using some spirit now.  ;-)
>
> This is somewhat cheating. We've tuned the numeric parsers of Spirit
> with TMP tricks, loop unrolling, etc. Those are very finely tuned
> numeric parsers you see there that beats the fastest C code such as
> strtol and atoi. The following benchmarks reveal 2X+ speed against
> low level strtol and atoi (attached). I am getting:
>
>   atoi: 0.82528 [s]
>   strtol: 0.792227 [s]
>   int_: 0.358016 [s]
>
> The first and second are the low-level C routines. The third is
> Spirit's int_ parser. I need not mention that the C routines only
> accept C strings while the Spirit int_ parser can accept any
> forward iterator. So, in a sense, we're comparing apples and
> oranges. But this goes to show that you can write highly optimized
> code in generic C++.

Oh, BTW, that's MSVC 9, on a Core 2 Duo 2.4 Ghz, 3MB RAM.

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Grace]

> This is somewhat cheating. We've tuned the numeric parsers of Spirit

> with TMP tricks, loop unrolling, etc. Those are very finely tuned
> numeric parsers you see there that beats the fastest C code such as
> strtol and atoi. The following benchmarks reveal 2X+ speed against
> low level strtol and atoi (attached). I am getting:
>
>    atoi: 0.82528 [s]
>    strtol: 0.792227 [s]
>    int_: 0.358016 [s]
>
> The first and second are the low-level C routines. The third is
> Spirit's int_ parser. I need not mention that the C routines only
> accept C strings while the Spirit int_ parser can accept any
> forward iterator. So, in a sense, we're comparing apples and
> oranges. But this goes to show that you can write highly optimized
> code in generic C++.

Dear Joel,

Would you mind trying out these examples with my timer?  I'd like to  
see if it gives sensible answers for other people's code on other  
people's machines.  Attached is a reworking of your testbed code  
using my timer which can be obtained from boost vault,

   http://tinyurl.com/ksbukc

I haven't been able to try compiling the attached modification to  
your code myself as I don't have the boost spirit libraries.  Even if  
I did it still wouldn't be your machine!  Since I can't compile it  
there *will* be some errors!  The ugly global variables are sadly an  
unavoidable side effect at the moment.

I have pared down the number of iterations quite significantly.  The  
generic_timer makes repeated calls to the functions under test - as  
many as necessary to 'get the job done' - so there's no need to have  
large run-times in order to effectively get an average time.

Cheers,

-ed






_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel de Guzman-2]

Edward Grace wrote:

>> This is somewhat cheating. We've tuned the numeric parsers of Spirit
>> with TMP tricks, loop unrolling, etc. Those are very finely tuned
>> numeric parsers you see there that beats the fastest C code such as
>> strtol and atoi. The following benchmarks reveal 2X+ speed against
>> low level strtol and atoi (attached). I am getting:
>>
>>    atoi: 0.82528 [s]
>>    strtol: 0.792227 [s]
>>    int_: 0.358016 [s]
>>
>> The first and second are the low-level C routines. The third is
>> Spirit's int_ parser. I need not mention that the C routines only
>> accept C strings while the Spirit int_ parser can accept any
>> forward iterator. So, in a sense, we're comparing apples and
>> oranges. But this goes to show that you can write highly optimized
>> code in generic C++.
>
>
> Dear Joel,
>
> Would you mind trying out these examples with my timer?  I'd like to see
> if it gives sensible answers for other people's code on other people's
> machines.  Attached is a reworking of your testbed code using my timer
> which can be obtained from boost vault,

Hi Edward,

I tried a quick shot at it. There are compilation errors indeed.
Please try to fix the errors first (*). You can get Spirit by getting
the Boost trunk off SVN.

(*) Also, please make sure you try it on Windows too. E.g. <sys/time.h>
is non-standard, AFAIK. My main compiler is VC9. Your library is
intended to be cross platform, right?

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Edward Grace]

> There are compilation errors indeed.

If you've tried building example_timer.cpp can you post up the errors  
you're getting?  I don't have access to a Windows machine.

> Please try to fix the errors first (*). You can get Spirit by getting
> the Boost trunk off SVN.

Ok, will do.

> (*) Also, please make sure you try it on Windows too. E.g. <sys/
> time.h>
> is non-standard, AFAIK.

No can do, I don't have access to a windows machine.

The <sys/time.h> is just for gettimeofday().

The actual generic_timer is chronometer agnostic (or should be) so  
any function you have to get a given high precision time should just  
'go'.  Perhaps if you post up your timer I can try that - or at least  
make an interface that will work.

> My main compiler is VC9. Your library is
> intended to be cross platform, right?

Indeed, *intended* is the operative word. I've only tried it on OS X  
and Linux.

-ed
------------------------------------------------
"No more boom and bust." -- Dr. J. G. Brown, 1997

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel de Guzman-2]

Edward Grace wrote:

> The actual generic_timer is chronometer agnostic (or should be) so any
> function you have to get a given high precision time should just 'go'.  
> Perhaps if you post up your timer I can try that - or at least make an
> interface that will work.

I believe Overmind posted that sometime ago included in the 7Z file
"Spirit_Price_Code1.7z"

Cheers,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Bytheway-2]

OvermindDL1 wrote:

> On Sun, Jul 19, 2009 at 2:29 AM, John Bytheway<jbytheway+boost@...> wrote:
>> That one doesn't compile for me.  On line 402:
>>
>> boost::spirit::qi::parse(va.begin(), va.end(),
>> boost::spirit::double_[boost::phoenix::ref(value)]);
>>
>> I get
>>
>> no instance of overloaded function "boost::spirit::qi::parse" matches
>> the argument list
>
> You are running Boost Trunk?  Compiles fine here in MSVC, and I last
> synced to trunk less then a week ago.

The problem is that parse takes its first argument by reference, and
va.begin() is a temporary.  If I take a copy of va.begin() and pass that
it works fine.  I don't see how this compiled in MSVC (does
string::begin() return a non-const reference?), but anyway.  Here are
the icc results (Intel Core2 Quad 2.83GHz, Gentoo):

Loop count:  10000000
Parsing:  42.5
xpressive:  4.28591
spirit-quick(static):  1.4721
spirit-quick_new(threadsafe):  1.46949
spirit-grammar(threadsafe/reusable):  1.59846

and gcc-4.4.0:

Loop count:  10000000
Parsing:  42.5
xpressive:  3.62948
spirit-quick(static):  1.02657
spirit-quick_new(threadsafe):  1.00637
spirit-grammar(threadsafe/reusable):  1.01748

gcc 4.3 is still ICEing.

John Bytheway

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

> > I just changed the file to use spirit for parsing where I had used
> > lexical_cast got very different timings for xpressive now, so now,
> > with xpressive using a bit of spirit I get:
> > Loop count:  10000000
> > Parsing:  42.5
> > xpressive:  15.4841
> > spirit-quick(static):  3.01117
> > spirit-quick_new(threadsafe):  3.10548
> > spirit-grammar(threadsafe/reusable):  3.81694
> >
> > Vast increase, 3x faster xpressive is now.
> > Also, how do you fix that rather bloody massive warning about
> > double->int64 truncation?
> > I also changed all int64_t to boost::long_long_type since they are
> the
> > same thing anyway (on 32-bit at least?), as well as it being
> > multi-platform unlike int64_t.
> > My changed file is attached.  Do not know if this is considered
> > cheating now that xpressive is using some spirit now.  ;-)
>
> This is somewhat cheating. We've tuned the numeric parsers of Spirit
> with TMP tricks, loop unrolling, etc. Those are very finely tuned
> numeric parsers you see there that beats the fastest C code such as
> strtol and atoi. The following benchmarks reveal 2X+ speed against low
> level strtol and atoi (attached). I am getting:
>
>    atoi: 0.82528 [s]
>    strtol: 0.792227 [s]
>    int_: 0.358016 [s]
>
> The first and second are the low-level C routines. The third is
> Spirit's int_ parser. I need not mention that the C routines only
> accept C strings while the Spirit int_ parser can accept any forward
> iterator. So, in a sense, we're comparing apples and oranges. But this
> goes to show that you can write highly optimized code in generic C++.

Slightly off-topic, but in order to emphasize what Joel said, here are a
couple of benchmark results I published a couple of days ago related to
output formatting: http://tinyurl.com/n4368t. Just an excerpt (Intel Core
Duo(tm) Processor, 2.8GHz, 4GByte RAM, Intel 11.1/64Bit):

Performance comparison for formatting a single double (all times in [s],
1000000 iterations):
sprintf: 0.694
iostreams: 1.354
Boost.Format: 2.011
Karma double_: 0.218

(where double_ is the Spirit.Karma output generator for a default floating
point format)

Regards Hartmut



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost