Re: [Boost-users] [boost] [xint] Formal Review Result

Subject: Re: [Boost-users] [boost] [xint] Formal Review Result
From: Phil Ratzloff (Phil.Ratzloff_at_[hidden])
Date: 2011-05-06 08:51:04

This summary is great! You obviously took a lot of time to digest all the feedback and identify the key points. I did not participate in the review, but I have worked with a variable-precision library enough to understand the issues. This helps me understand what is going on with the library, and it helps me understand the process used to assure high quality of libraries in boost. Thanks for taking the time to do this. 

-----Original Message-----
From: boost-users-bounces_at_[hidden] [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Vladimir Prus
Sent: Saturday, April 30, 2011 12:00 PM
To: boost_at_[hidden]
Subject: [Boost-users] [boost] [xint] Formal Review Result

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]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users