Boost logo

Boost :

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-03-31 17:11:53

On Mon, Mar 31, 2008 at 8:59 PM, Stephen Nuchia <snuchia_at_[hidden]> wrote:
> In large-scale computation code, fine control of allocation is a must.
> The ability to have the major data structures with their hand-tuned
> allocation strategies freely intermix with "casual" variables and
> constants in expressions, as parameters, etc is pretty important.
> Bleeding-edge factorization algorithms for instance allocate large
> numbers of, uhm, numbers all of which have roughly the same number of
> bits. Cache-and-paging efficient allocation for these numbers can make
> the difference between success and failure.

I do not work in the numerical computation field, but of course, agree
in principle.

> But you'd like to be able
> to call functions that were written without awareness of your custom
> allocation strategy.

I they have been written in the spirit of generic programming (and
performance is a must), they will be templated on the numeric type, so
not only you can pass multiprecision
integers using custom allocators, you could even pass *different*
multiprecision integers classes or even plain int.

If performance is not a problem, (I/O maybe?), then you could use an
external polymorphic wrapper to cancel the allocator type. A
boost.multiprecision could even provide it
out of the box. Really, it is nothing new. Boost.function does it for
function objects, adobe any_iterator does it for iterators. It is not
hard to imagine an any_integer class.

> The concerns for both interoperability and efficiency are inescapable.
> I believe the interface should allow for runtime polymorphism but be
> constructed so that a decent optimizing compiler can "almost always"
> infer the correct static call in code that is not intentionally using
> runtime polymorphism.

A static, templated interface always allows for runtime polymorphism.
The reverse is not the case.

> That may take some template specializations but
> it would be worth it.
> Finally, how does this relate to gmp? Are we trying to work around
> licensing issues or is it an interface definition issue? Where the user
> has a tested and tuned gmp implementation, can the new library be
> configured as a wrapper for it?

I have no opinion on this. It is a completely different issue. I think
that gmp could be implemented on top of a templated interface just
Note that GMP might be a good argument against a templated interface.
It works very well (in fact is AFAIK is the fastest multiprecision
library) with runtime allocators.
OTOH it might be a good argument in favor: custom, completely
optimizable-away allocators might be the only way to go beyond GMP


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