Re: [boost] [xpressive] Performance Tuning?

Subject: Re: [boost] [xpressive] Performance Tuning?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-07-14 08:15:35

OvermindDL1 wrote:
> On Fri, Jul 10, 2009 at 7:32 AM, Stewart,
> Robert<Robert.Stewart_at_[hidden]> wrote:
> > Eric Niebler wrote:
> >> Paul Baxter wrote:
> >> >> Thorsten Ottosen wrote:
> >> >>>
> >> >>> It would be good if you could submit your code as a case in
> >> >>> optimizing expressive code.
[snip]
> >> > This has been an incredibly useful thread. Thanks to you all.
> >> >
> >> > As a potential user put off in the past by concerns over
> >> > abstraction penalties with such libraries (even compile time
> >> > libraries often fail to deliver in all but simple cases), I
> >> > urge Eric to embrace such an example to illustrate just how
> >> > powerful and maintainable a solution based on expressive can
> >> > be.
> >>
> >> I think this is a fine idea. All these tips and tricks are
> >> already described in a doc, but they are not described in depth
> >> from an end-user perspective. I think a performance tuning case
> >> study would make a valuable appendix.
> >>
> >> Robert, can you send me the latest version of your regex
> >> grammar and your hand-coded parser? I'll see what I can do.
> >
> > Sure.  I've attached both in one file, but with separate
> > namespaces.
[snip]
> > This code is used to parse whole numbers, real numbers,
> fractions, and mixed numbers from a string creating an
> integer from which the (possibly) fractional value can be
> recovered.  example::lcm<T>::as() returns 160,000 as type T
> for that purpose because 160,000 is the least common multiple
> of all supported denominators.  That aspect of this code
> should probably be removed in order to concentrate on the
> parsing, but was too well entrenched for me to remove.
[snip]
> I find this quite interesting.  I wonder if I might have the
> time tonight to make a Spirit2.1 version of this, the code
> would certainly be a great deal shorter.

That would be great.  I am interested to know if I was doing anything wrong or was just trying more than Spirit v2 was capable of doing in Boost 1.37, which is what I needed to use in this case.

> Just to make sure, from what I gathered looking at the code,
> you are trying to parse out a number from an ascii string that
> could potentially be an integer (64-bit, just digits, always
> base 10), a double (digits as the integer, then a period, then
> more digits parsed as the integer, OR a whole integer, then a
> space(s), followed by an int then a / then an int), it looks
> like that a real number can have a 'g' after it, but what is a
> g?  I know what e's means, but g?

As described above, I'm looking for whole numbers, reals, fractions, and mixed numbers.  The whole numbers are 64b integers.  The reals are any of various formats such as you might get from printf().  The "g" and "G" were from a rapid, overzealous scan of the manpage; I forgot to remove them when I realized they weren't appropriate (they are not supported in the custom version, you'll note).  The fractions are expected to have a positive denominator, and a possibly signed numerator.  The mixed numbers are a whitespace delimited combination of a whole number and a fraction, except the numerator must be non-negative in that case.  As you surmised, the input is assumed to be an ASCII string.

> I am also confused, it seems your types support int64 as well
> as double, but you only ever return an int64, why not a variant
> of both?

The purpose of this code was to produce a 64b integer because the result represents a (possibly fractional) dollar amount: a price.  The 160,000 least common multiple provides rounding for all supported denominators so all supported amounts can be represented exactly in the 64b integer type (the range is, of course, reduced in doing so).

> Should I do this for Spirit2.1?  Spirit2.1 naturally wants to
> use such things anyway so it is actually easier for me to do
> so, and the user would have a more accurate value too as they
> would get either an int64 or a double depending on what it
> parsed, I could also add in other representations like a struct
> of two int64's for a numerator/denominator as well for best
> accuracy.  What would you prefer?

In order to compare your Spirit code against the two versions I supplied, your code would need to behave the same.  Otherwise, you must alter the two versions I supplied to match what you choose to provide in your Spirit version.  The purpose of this exercise is to compare the code and performance, so they must all perform the same task.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.