Re: [boost] [XInt] Some after thoughts

Subject: Re: [boost] [XInt] Some after thoughts
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2011-03-10 19:54:04

On 03/10/2011 04:06 PM, Simonson, Lucanus J wrote:

> I can attest that it is generally not compatible with generation of optimal code.  Others may disagree, but I've had some unique experience with trying to create a C++ abstraction on vector instruction sets.  Other than the fact that I couldn't do some necessary AST transformations in the ETs of our DSEL for vector operations because there is no way to identify whether two arguments to an expression are the same varaible, only the same type, there were many, many other problems that caused the reality to fall short of our expectations and promising results early on.  Frankly, if you want fast SSE accelerated code you should do it by hand in assembler.  For infinite precision integer in particular you need access to the carry bit that is generated by vector artihmetic and other instruction
>   level features.  Just replacing int with int_128_t isn't going to get you too far.  You need to hand unroll loops and generally put a lot of thought into what you are doing at the instructio
>   n level to get the best implementation and everything needs to be driven by benchmark results.  Even intrisics don't give you the ammount of control that is needed to get max performance because the compiler can't run benchmarks to guide its choices the way you can.  (Well, Intel compiler actually can to some extent...)  Instead of writing assember we should provide points of customization to allow the user to override all the algorithms with their own implementation.  That could be gmp, their own hand coded assembly or some high level code that has been optimized through Intel parallel building blocks, for example, which accomplishes with vector type abstraction in C++ what ETs cannot through use of a JIT compilation step.
>

Relying on "customization points" to customize the performance, rather 
than behavior, runs counter to the whole point of a library.  The idea, 
after all, is to provide a fast arbitrary precision integer library, not 
to merely provide an interface, and then ask the user to write the 
implementation.  Editing the source code itself is the appropriate 
customization point for optimizing the implementation.  Any such 
performance optimizations should just be submitted back and included in 
the official version of the library, rather than forcing all users to 
individually waste their time reimplementing the optimizations.  If 
possible, a compile-time/preprocessor option to replace the existing C++ 
implementation with calls to GMP, for instance, would seem to be quite 
useful and also compatible with Boost licensing.