Re: [boost] Multiprecision vs. xint

Subject: Re: [boost] Multiprecision vs. xint
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2012-06-18 07:31:22

John Maddock wrote:
> Rob Stewart wrote:
> > Christopher Kormanyos wrote:
>
> > Of course it needn't compete with the world-class
> > implementations, at least not initially.  However, it must be
> > fast enough to be usable in enough use cases to get
> > sufficient experience to determine whether the interface is
> > right and whether the customization points are appropriate,
> > in order to have a solid foundation for a standard proposal.
>
> Point taken, however it does wrap many world class
> implementations such as GMP and MPFR.  Frankly in the general
> case it's foolish to believe that Boost can compete with those
> guys.

No argument

> However, basic C++ implementations for integer and floating
> point types are provided which are much better than toys, much
> less than world class, but perfectly usable for most cases (or
> where a non-GNU license is necessary).

I wasn't trying to disparage what you've done.  Rather, I was arguing that if a class of potential users, exemplified by Phil, are not well satisfied, there might be issues with the library's abstractions.  Please note the conditional and vague phrasing in that last sentence: if, potential, well, might.

> >> I would prefer to work on the interface, not the performance
> >> of the default classes that John and I have provided. If we
> >> bicker about these, we will never get to the real matter at
> >> hand which is specifying the abstraction for non-built-in
> >> types.
> >
> > While I agree with your sentiment, note that Phil's concern
> > about being able to create a fast, slightly-larger-than-
> > built-in type is important. Showing how such a type can be
> > created is an important exercise because it will show whether
> > the abstraction and points of customization have been
> > properly conceived to permit creating such types.
> >
> > Indeed, given the likelihood of folks wanting to do what
> > Phil did, the library could provide a template-based backend
> > implementation that does most of the heavy lifting.
>
> There is a problem here - in that there is no "one true way"
> for a slightly larger integer type - it all depends on how much
> larger, and the particular size of the integers it encounters
> in practice.

What about int_fast32_t and friends as models?  That is, might there be different types for different purposes that can be selected based upon how the main class template is parameterized?  IOW, allow the user to indicate which backend (or intermediate bridge layer) to use based upon the user's own preference or performance analysis.

> For example:
>
> * For int128, simplicity will probably always win out, making
> the "naive" implementation the best.
> * By the time you get to say int1024, computational
> complexity wins out, so something like the fixed sized integers
> already provided are likely to be best (modulo the fact that
> more profiling and fine tuning is still required).  That's why
> I was persuaded to switch to those prior to the review from a
> more traditional fixed int (like Phil's).
> * To complicate matters more, for say int1024, the "naive"
> version wins if most of the values use all the bits, where as
> the version that maintains a runtime-length wins when most
> values are small.

Cannot those options be selected by the user?

> Having said all that, I think it is true that a weakness of
> the library is inherent overhead when dealing with "trivial"
> types that are extremely close to the metal to begin with.
> Probably that reflects the original focus of the library where
> this is a non-issue.

Surely templates can select an optimal backend and erase all overhead in using it.  For example, if the user selects the naïve, but optimal, backend for a 128 bit integer type, must there necessarily be overhead that wouldn't exist in a customized 128 bit integer type?  If your current design imposes such overhead, might there be a way to refactor the design such that one interface (the user-facing class template) can select the right IL to bridge that interface and the optimal backend?

> >> John's concept takes the first step toward establishing an
> >> architecture for extended numeric types.
> >
> > It is reasonable to view this as "the first step" and leave
> > the fulfillment of some of these other requirements for
> > later. However, if there is no proof of concept for the
> > various use cases, then you can't be sure the abstraction and
> > points of customizations are correct.
>
> True.  However, you can't carry on forever, you have to ask
> for a review at some point.  At present the focus is more on
> "breadth" than "depth".

I cannot argue your point beyond saying I'd hate to think that your library was accepted and then six months later you realized a fundamental oversight (and I don't assert there is one).  OTOH, there is no requirement for backward compatibility in Boost and if you did discover such an oversight, you could choose to break compatibility -- for a fledgling library -- for the sake of significant improvement and avoidance of having to creating BMP2.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.