Re: [boost] [xint] Performance of fixed-size large integers

Subject: Re: [boost] [xint] Performance of fixed-size large integers
From: Ivan Le Lann (ivan.lelann_at_[hidden])
Date: 2011-03-04 03:03:16

Le vendredi 04 mars 2011 à 02:10 -0500, Chad Nelson a écrit :
> On Thu, 03 Mar 2011 19:04:44 +0000
> "Phil Endecott" <spam_from_boost_dev_at_[hidden]> wrote:
> 
> > [...] The docs' front page has a link under "Detailed Usage
> > Information" to "Fixed-Length Integers" - which is not really very
> > detailed, and has examples in the notes like "integer_t<8>" that
> > don't work. I established quickly enough that the correct syntax is 
> > integer_t<fixedlength<8>>. 
> 
> Apologies, that was left over from an earlier iteration of the library
> and has now been corrected.
> 
> > Also I noted that the conventions here don't match the built-in
> > (u)intN_t types, i.e. int64_t vs. int63_t and the "wrap-around"
> > behaviour.  Perhaps there is some rationale for this, but I would be
> > happier to see it consistent with the built-in types. [...]
> 
> Sorry, but the library doesn't use two's complement representation
> (there's no high-bit on arbitrary-length integers, so it can't), so
> that would only be possible with code specifically written for
> fixed-length integers.
> 
> > [...] It seems to me that that is several hundred times faster than
> > the Xint code (on my 1.2 GHz ARM test system). [...] This is about
> > half the speed of the assembler, but still hundreds of times faster
> > than the Xint code. [...]
> 
> I'll be happy to accept patches.
> 

I ran no benchmarks but delving through magnitude_manager_t seems enough
to understand the problem. Do you think specializing this class on Bits
parameter to be stack based for non zero values could solve this
performance problem? 

Ivan