On Mon, Mar 31, 2008 at 8:59 PM, Stephen Nuchia <snuchia@statsoft.com> 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