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

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-03 12:53:04

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/03/2010 09:40 AM, Marius Stoica wrote:

>> I found a way, thanks to a suggestion from John Bytheway. :-)
> 
> That's really awsome :)

Yup. I'm happy with it. :-)

>>> It's just a compile-time option like the other ones.
>>
>> Not entirely, due to those two extra functions. And logically it's a
>> distinct type.
> 
> The more i think about it i think you should go for a policy based design.
> Rigth now there is the obvious problem that you don't have a 
> nothrow_fixed_integer.

I don't see that as a problem. The fixed_integer class is a convenience,
because one fellow here requested it; it does nothing that
nothrow_integer can't do just as well and nearly as easily.

> Maby you can do something like this :
> 
> integer_t <
> 	throws<false>,
> 	size<128>, // 0 means unlimited
>  	thread_safe<false>> myint;
> 
> You could also have some other policies 
>   -overflow policy( become nan, overflow to negative)
>   -signed/unsigned policy

I'm not sure that's really an improvement. The current design separates
throwing and nonthrowing for a reason; take a look at some of the
function implementations and you'll see why. Combining those would mean,
at the very least, an extra if statement in every function.

If you look at the fixed_integer versus integer_t templates, you'll see
that they really only differ in the digitmanager_t that they use. I
considered combining them, or deriving one from the other, but it seemed
cleaner and more straightforward to make them unique types.

>> That might save a few bytes of memory, but it would make the
>> entire library slower, because it would have to check to see
>> whether to use the data_t object or not before every operation.
>> Memory isn't so precious that I'd consider that a good trade-off.
> 
> Doesn't seem to bad to me, the advantages quite serious
> -if you have a lot of small ints you save a lot of memory( i think an data_t 
> would be more than 3x larger)

If you have a lot of small ints, you're better off storing them as ints
and constructing large integer types from them if and when necessary.
The library is explicitly designed for storing and manipulating *large*
integers, things that are too big for the built-in types. I'd rather not
dilute that by trying to make it all things to all people.

> -for example you can put them in a vector without having pointers to 
> everywhere(less fragmentation)

If you need that quality, the fixed_integer type will always allocate
exactly the same amount of memory, no more and no less, making it easy
to prevent fragmentation. And you can provide your own allocator to get
complete control over the memory.

> -you can allocate them on the stack without needing to dynamically
> allocate memory wich is quite expensive and nondeterministic

Not part of the library's design goals. The expense of dynamic memory
allocation is dwarfed by the time it takes to process numbers of any
reasonable size.

> For that you will need to
> 
> -add a few instructions to every function(not very much)
> -check a flag (not very costly xoring and comparing are the cheapest ops and it 
> will have good branch prediction )
> -add another pointer(probably the most serious issue, but you already have a 3 
> pointer indirection -  maby you can make it so you can keep that ? )

The fact that it takes any at all means that it would slow the library
down further. Just adding support for user-selected allocators slowed it
down by 2.3 to 2.5 percent, something I am not very happy about. I'd
need a *very* compelling reason to slow it any further.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwH3fAACgkQp9x9jeZ9/wRq3wCeNbAwHMl8OXpvKVe9oDU7iqdK
wU8An0lFEF1TKo6YmG3hMjWCAh6czC5q
=oj9X
-----END PGP SIGNATURE-----