Re: [boost] [mp_math] a multi precision signed integer library

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

-- 
gpd