gmpxx and allocation

[Marc Glisse]

On Tue, 6 Mar 2012, Richard B. Kreckel wrote:

> On 03/06/2012 01:07 AM, Marc Glisse wrote:
>> * For the small object optimization, I used flint's fmpz_t. It computes
>> with integers as long as numbers fit in a pointer minus a few bits and
>> only uses gmp when they don't (and in that case uses a pool approach).
>> Note that this is a classical technique (some standard libraries use it
>> for std::string, integers in guile (scheme) are implemented that way),
>> flint was just the first one I found for this test. If done properly,
>> one can get a speed within a small factor of builtin operations as long
>> as the numbers fit (although it is hard to convince the compiler to
>> generate optimal code without writing the whole function in asm).
>
> Can you, please, check the assembler code? Are there still calls to 
> operator+, operator-, and operator*, or are these being inlined somehow? (I 
> suppose the calls are there: CLN also does the fixnum/bignum thing and the 
> speedup is about the same with the optimzation coming from avoiding 
> allocation, deallocation, and assignment and the speed being limited by the 
> three arithmetic operator calls.)

(CLN (cool, it is packaged by my distribution, I should have used that one 
for the comparison) appears slightly slower than flint here, something 
like 0.18s)

Sorry, my flint installation is gone, so I can't check the assembler. 
However, I am pretty sure that calls to add/sub/mul were still there. The 
code for them is in a separate library, and I didn't ask the compiler to 
do link-time optimization (or inter-procedural optimization, or whatever 
they call it these days). Besides, I would be disappointed if the 
performance wasn't better with an inlined fast-path (note that now gcc can 
do link-time optimization and partial inlining, it could in principle 
inline just the fast path if passed the right options).

-- 
Marc Glisse