Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-06-10 17:45:17

Chad Nelson wrote:
>> My experience with GMP has been that reusing existing GMP objects
>> instead of declaring new ones was a significant performance
>> enhancement.  I don't think it is true that cost of operations is
>> even greater than the cost of allocation, mush less significantly so,
>> in general.
> 
> That depends on the size you're using and what you're doing with it.
> For 
> a 65-bit integer like you mentioned, doing nothing but addition and
> subtraction, you're right. For a 4096-bit one using a lot of
> exponentiation (think RSA encryption), the cost of the operations will
> *definitely* outweigh the cost of allocation, and by such a large
> margin 
> that the allocation will be completely unnoticeable.
> 
> Most examples will fall somewhere between those two extremes.
> 
>> It is reasonable, particularly with fixed integer, to expect that the
>> common case will be operations on a number of bits only slightly
>> larger than the built in integer types support. If I need 65 bits
>> (and I do) I will code it myself rather than pay for an allocation
>> (and I did).
> 
> That's certainly a viable option, if you've got the luxury of the time
> and interest to do it. Your average developer often doesn't, or values
> his own time more than he needs efficiency in that part of his
> program. 
> 
> The library is designed for large integers -- something that's usually
> noticeably larger than 65 bits -- so it probably won't be optimal for
> really small integers like that. It'll get the job done though, so I
> don't consider that a problem.

There is a sort of odd dynamic here.  On the one hand we all care about performance.  On the other there is no way to implement this library in C++ to be efficient on modern hardware because the C++ standard doesn't provide access to integer overflow flags and the compilers are next to worthless for vectorizing general code.  Obviously no one expects you to special case the hardware at run time and provide inline assembly where it is warrented, however, where do we draw the line and say "past this line we do care about performance."  A performance delta of 10X is not unreasonable between this library and GMP with hand crafted SSE assembly code that takes advantage of overflow flags competing with whatever scalar code the compiler manages to produce, so I suppose we can set performance completely aside for now and focus on the interface.  However, the issue will certainly come up during review.

Regards,
Luke