Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-03 11:10:09

On Thu, 03 Mar 2011 14:46:41 +0100
Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:

> On 03/03/2011 02:28, Chad Nelson wrote:
>
>> I don't recall the reason for passing by value offhand, but I believe
>> Boost.Move was part of it. I'll research that before the next update.
>
> You quote Dave's "Want Speed? Pass by value" article as motivation.
> [...]

Yes, I rediscovered that in the documentation last night, and I plan to
reread the article to see whether it really applies or not, or if there
are other reasons for it too.

>> Eliminating sixteen bits of overhead, on an integer that is almost
>> always going to be larger than 64 bits (and often *much* larger),
>> seems to be a premature optimization at best.
>
> Consider a language like Python. All integers can be arbitrarily
> large, yet in practice, they rarely are.

Not the same case at all. XInt isn't a language, it's a library that's
explicitly designed for very large numbers. If someone didn't need
numbers larger than the built-in types can handle, they wouldn't use it.

> Can your library allow me to choose a memory layout optimal for the 
> application of my choosing?
> Probably not. How about you let me choose my own layout and let me 
> interface with your algorithms?

If you want that sort of flexibility, you'd probably be better off with
something like GMP. XInt isn't designed for that, and in my opinion,
shouldn't be.

>>> - I would quite like to get an interface to iterate the integer
>>> digit per digit or byte per byte.
>>
>> Why?
>
> - So that the library is easily extendable

What would you want to do to the internals of it that it doesn't
already provide, and that I wouldn't be willing or even eager to add?

> - So that the algorithms only require a range of digits as input if
>   that's all they need, allowing them to work with arbitrary types
>   of my choosing without having to copy or convert to your types

If it exposed the internal details of a number, then I'd never be able
to change the way it works without breaking existing client code. That
would be a much worse design.

> [...] If the user provides a SIMD type as a digit, you'll get
> optimized SIMD code for free, for example, in a completely
> externalized way. Now *that* would be awesome. [...]

Yes, it would. But it would come at a cost.

>>> - XInt cannot do SBO
>>
>> A large-integer math library would be able to take advantage of SBO
>> only rarely, and every number object would have to carry around the
>> overhead, at least in all the SBO designs I've ever seen. If you were
>> complaining about sixteen bits of sometimes-unneeded overhead, I'd
>> hate to see how you reacted to, for instance, 128.
>
> "sometimes-unneeded"? COW is disabled by default,

Disabled by default on *external* numbers. It's still used internally,
where it's completely safe and much faster to do so.

> and should never be used anyway, since it is a hack that only makes
> sense in a language without move semantics.

Which C++ still is, until C++0x is official and built into almost every
platform's compilers. Which won't happen for a number of years yet.

> And this is mostly a problem due to bad code design, there is no
> reason why you couldn't be rid of those two words in the non-COW case,
> and why you couldn't be rid of the buffer size in the fixed-width
> case.

Your opinion is noted.

> Something else, I went through a code a bit, and I saw virtual 
> inheritance. Just why do you need dynamic dispatch in a design where
> all information is purely static?

For the policy-based options.
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*