Re: [boost] [units]

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-04-02 15:39:39

Just a reminder to interested parties - two more days left in the  
proposed Boost.Units review. We'd love to get some more reviews...

> It is just the noncontradicted repetition of the "zero-overhead"  
> keyword
> over and over again, that irritates me. This indicates that
> performance is not so unimportant anyhow.

OK - the library itself doesn't introduce any overhead, so in that  
context the zero-overhead description is correct. As we've already  
established, achieving zero-overhead with current compilers can be  
non-trivial. I will add documentation clarifying performance issues  
and warning library users that any use of this library in performance- 
critical code should be tested, etc...

> a cache miss or other kinds of data dependencies may already hide  
> this.
> In essence, I would qualify that library as "zero- to low-overhead".

OK - we will temper statements on performance and point out that, as  
the library is still in development, compiler-specific optimizations  
have not been undertaken for the most part.

> system would be faster? I have to apologize then. I tried to convice
> you (and anybody else) that it would be better to have a dynamic  
> system
> that is closely integrated with the static one (and vice-versa).
> A dynamic system enables to create additional benefits, going far

Assuming the existing library ultimately finds its way into Boost, we  
would be happy to work with you to provide support in integrating a  
run-time system that you envisage with the existing compile-time  
system. I have never denied the potential usefulness of runtime unit  
support, and would be 100% behind an effort to write a runtime  
library that complements this one.

> Consequently, I opt against rational exponents, as I consider them  
> to be
> an obstacle for such an integration.

See noise-density for an example of a unit in use that has a  
fractional exponent : http://swiss.csail.mit.edu/~jaffer/MIXF

> Furthermore, I tried to point out that inside of computation kernels
> (thats where performance really matters), you probably go without any
> unit library.

We are investigating ways of guaranteeing that the layout of, e.g.  
std::vector<quantity<length,double> > is identical to  
std::vector<double>, so that safe casting is possible when using  
computational libraries that do not support units. For most compilers/ 
operating systems this should be the case as the quantity class  
doesn't have any virtual member functions or anything else that would  
alter the layout in memory.

Matthias