Subject: [boost] Multiprecision Review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2012-06-24 13:46:39
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
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?
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
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?
Do you think the library should be accepted as a Boost library?
(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".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk