[boost] Multiprecision Review

Subject: [boost] Multiprecision Review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2012-06-24 13:46:39

Dear All,

Here is my review of the proposed Multiprecision review.

First a rant: why have so few people contributed to the discussion or 
written reviews?  I have waited until now before writing this in the 
hope that others would say something useful, but there has been very 
little to read.  Boost will suffer as a result of this.  It has been 
depressing to see that at the same time the mailing list has been full 
of other discussions, so the problem is not that people don't have the 
time to contribute.  In particular, the long thread about 
Boost.Exception makes me want to shout "Why Didn't You Say All This 
When It Was Reviewed?".

My view of the proposed library can be summarised as follows: it 
doesn't do what I want, but maybe it does enough things that other 
users would like to justify its acceptance anyway.  Except probably it 
doesn't, because if it did those other users would have said so, which 
they haven't.

In particular, I'd like to be able to implement integers of perhaps 128 
or 256 bits that behave like the built-in integers.  I can quickly 
throw together something myself that works OK but:

- It's difficult to get the last bit of performance because you need to 
write asm to use the CPU's carry flag; the work-around probably results 
in a 2X slowdown.
- Writing all the operator overloading etc. is tedious.
- It's also error prone, as a mistake in e.g. carry propagation might 
be detected once in very 2^32 operations.

It would have been great if this library could have helped with this.  
Instead, it has produced something worse than my "quick 
throw-together".  It's worse because it has tried to unify this 
smallish fixed-size type with very large variable-size types, and the 
compromises necessary to achieve this have sabotaged the performance.  
It's also worse because it had a subtle bug - which has since been 
corrected, but I would still not be confident of getting correct 
answers without verifying against another implementation.

Ideally, there would still be some parts of the library that could be 
useful to me.  If the library had been decomposed into data structures 
vs. algorithms then perhaps I could have applied the algorithms to my 
simpler data structures.  Unfortunately the library has not been 
organised in this way, and even if it had done the use of 
sign-magnitude representation might have scuppered any re-use.  As far 
as I can see, the only part of the library that I could re-use would be 
the expression template front-end, which doesn't seem to improve 
performance for types of this size anyway.

Here are my answers to the standard review questions:

     What is your evaluation of the design?

Not great for my purposes; see above.

     What is your evaluation of the implementation?

I spent half a day chasing down a bug.  My observations are that (a) 
there are subtle bugs, and (b) the code lacks comments or other clues 
for people like me to quickly pick up what it's all doing.

     What is your evaluation of the documentation?

Satisfactory.

     What is your evaluation of the potential usefulness of the library?

Not useful for me; see above.

     Did you try to use the library? With what compiler? Did you have 
any problems?

I spent perhaps a day working on a small but real benchmark which was 
discussed on the mailing list.

     How much effort did you put into your evaluation? A glance? A quick 
reading? In-depth study?

About a day-and-a-half in all.  I've not looked beyond the areas that 
I've discussed and I'm aware that there is a lot more to the library 
i.e. non-integer types.

     Are you knowledgeable about the problem domain?

Not especially.

     Do you think the library should be accepted as a Boost library?

No, because
(a) I'm not convinced from this discussion that lots of people are 
waiting for this functionality (see above).
(b) Based on previous experience, I'm sceptical about the possibility 
of the performance of Boost libraries being improved after acceptance.

Despite that, I thank John and Chris for their work which is a 
considerable leap forward from the last "big number" submission, "xint".

Regards,  Phil.