[boost] [xint] Formal Review Result

Subject: [boost] [xint] Formal Review Result
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-04-30 12:00:14

I apologize for the delay in producing the final summary and result of the
Boost.Xint review, but here it is.

Votes
=====

YES:

- Christian Henning
- Steven Watanabe
- Jarrad Waterloo
- Edward Diener
- Paul A. Bristow

NO : 
- Mathias Gaunard
- Joel Falcou
- Anders Dalvander
- Joachim Faulhaber
- Phil Endecott
- Domagoj Saric
- Gordon Woodhull ("fraction of a vote")

I might have missed somebody inside the 454 messages I have
as result of the review, but the overall picture is clear --
the votes are split.

High-level issues
=================

- The claim that the library is "fast" is not necessary true. Phil has did some checking
against hand-written assembler that don't look too good.

- It is not clear whether the design allows for improving performance of fixed-size
integers using specialization (again, see Phil's comments)

- There were concerns about COW. In particular, it was very clearly stated that
if COW is used, it should work fine in multi-threaded programs.

- It was suggested to use ET.

- Some folks suggested better separation between algorithms and data 
representation.

Specific issues
===============

- It was pointed out that "a + b + c" creates a pile of temporaries, and this
can be improved without using ET.

- Joachim's review raised a lot of valid points. Section 3 of his reviews
in something that should be addressed, more or less entirely. Note that
while we normally don't force specific coding style, some of formatting
pointed out is simply unacceptable if this code is to be read by
anybody.

- 'Secure' flag is probably not so much of it.
   

Future directions
=================

I think that reviews by Phil and Joachim are most important in specying
evolutionary directions for Boost.XInt.

Chad made several comments about what he plans to do, in particular:

- http://article.gmane.org/gmane.comp.lib.boost.devel/216935

Conclusion
==========

I think there's no doubt that (i) this domain is important and (ii) Chad
has put a lot of work into this library, producing several iterations.
It was pointed out that we have many arbitrary-precision libraries skeletons
all around Boost, and providing such a solid offering for review is
a significant accomplishment. And it everybody learned a lot during
the review.

There was a couple of important meta-points raised during review --
whether review should focus on external interface only, and what is the
scope of the library.

Some reviewers argued that only external interface matters. However, it
seems to me (as review manager), that concerns about internal design
are valid, and may not be rejected offhand. After all, external interface
of an integer library is more or less defined by mathematics, and internal
design plays a key role in successfull evolution of the library.

There was also heated discussion about the scope of the library, in 
particular support for fixed-width integers. I think that it's abstractly
OK for this library to treat fixed-width integers as second-class
citizens. However, I am having hard time determining the intended
scope of the library.

If I'm doing cryptography, would I really want to implement cryptography
algorithms from the books with Boost.XInt, only to introduce bugs that
are probably fixed in existing implementations (often, included in the OS).
And if I'm really intent on doing that, I probably want raw performance,
including a way to plug in optimized backends using SSE 2011, CUDA, and
whatever fancy technology is there.

If I'm doing general programming, then I'm most likely interested in
not too big integers. They might be fixed-width 128-bit integers, or they
might be something larger-than-64, but not necessary fixed. However,
such integers are not the scope of the library, and they were found to
have suboptimal performance.

It is certainly possible to refine/define the scope, optimize everything for
that scope, accomodate the proposals made during review, and obtain an
excellent Boost library. However, there are some many suggestions, and so many
planned redesigns and changes, that we need a second look at the
library. Further, because of the global nature of the changes, it would be
very hard to identify a specific subset that must be improved and then
go through mini-review. For that reason, I've arrived at the the following
result:

        Boost.Xint library is not accepted at this time. We'll be happy to have
        another full review of the library when the next version is ready.

Thanks to Chad for the submission and for everybody who participated in the
review!

- Volodya

-- 
Vladimir Prus
Mentor Graphics
[phone]