Re: [boost] mcs::units informal review request

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-01-28 16:08:40

Matthias Schabel wrote:

> Any input on optimizing the library would be most welcome - I expect  
> that it should
> be possible to have code using quantities run exactly as fast as for  
> built in types,
> but that remains to be proven...

So far that seems to run true if you use the highest optimization level
for g++.  In VC++ I'm finding otherwise.
> 
>> as deep a recursion level without a seg fault...this is actually by
>> quite a margin...several orders of magnitude.  Both versions fail  
>> at the
>> same point.  Here is test code...add a 0 to the end of tlim and I  
>> get a
>> crash on the quantity version:
> 
> I'm personally more concerned about runtime performance than  
> recursion at this
> point, but this is an interesting point... I'm not completely clear  
> on what you mean
> about increasing tlim : do you mean that the equivalent code with  
> doubles can
> recurse several orders of magnitude deeper, and mcs::units recurses  
> one order
> of magnitude deeper than your quantity code?

tlim is the variable in the code I pasted that sets the recursion depth.
 Yours and mine both have the same issue and crash at the same level (or
close enough).  Doubles can recurse several orders of magnitude deeper.
 If you add a zero to 50000 then that is the point with both mcs units,
and my own similar construct, crash...

> 
> It looks like I'm having a dumb day today. Do you mean that there are  
> more operations
> in the quantity code than there are for doubles???

There must be but I haven't looked at the asm.  It is possible that even
the recursive double function is getting inlined and the quantity
version not but I used recursion hoping the actual functions wouldn't be
and only the quantity would so I could get an accurate assessment of
double vs. quantity speed.  It is important in my case that they are the
same or close to it.

Having a recursion limit depth of 50,000 isn't a big deal..not for me
anyway, but it is interesting to note.

BTW, my project, which has different goals than yours but some similar
constructs (and similar issues), is unitlib on sourceforge.