Boost logo

Boost :

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 :

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at