Re: [boost] Multiprecision vs. xint

Subject: Re: [boost] Multiprecision vs. xint
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-06-15 18:56:20

> Dear All,

> I'd like to encourage people who are looking at the proposed
> Multiprecision library to remind themselves of the xint review
> last year.  See e.g.

<snip>

Thank you for your words, Phil.

Your post is of central importance to the concept of Boost.Multiprecision.
These matters constitute a rich and deep topic in the area of
high-performance computing.

Even though I may not be an experienced booster, I would like to
express my detailed opinion on them. I suppose I will get in
trouble for this on the weekend.

> Multiprecision addresses many of the problems of xint, and also
> extends the scope into areas that xint did not address at all.

At the present time, neither boost nor C++ supports extended
integers, big floats or fixed-points. C++ only supports a handful
of built-in integral and floating-point types. Those interested in
high-performance computing or ultra fast fixed-point
(e.g. for embedded systems) must, therefore, unavoidably
write specialized types.

In my opinion, Boost.Multiprecision does the following:

	1. Provide a uniform template abstraction for extended numeric types.
	2. Provide default implementations of integer, rational and float.
	3. Allow for a future default implementation of fixed-point.
	4. Allow for use with a future extended complex class.Although the proposed Boost.Multiprecision provides default
implementations of int, rational and float, its main goal is not to
compete with the world's best performing implementations thereof.

I would prefer spending review time working on the long-game
of boost and C++. How will boost or C++ potentially specify
extended number types?

template<typename back_end_numeric_type,
                typename numeric_traits,
                typename allocator_type,
                typename expression_method>
mp_number
{
};

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.

John's concept takes the first step toward establishing an
architecture for extended numeric types.

In this way, the previous discussions about default styles
of template expression and the proposed name of the abstraction
(mp_number or simply number) are more relevant than
detailed performance analyses of the types made available
in the first release of a proposed Boost.Multiprecision---of course,
assuming that they are not embarrassingly slow.

> However it still suffers some of the same problems: if I want an int128_t
> that is just 128 bits of data, it doesn't help me.

The proposed Boost.Multiprecision says, "You have to write it yourself!"
Just like a compiler supplier would. That's the concept of the proposed
Boost.Multiprecision.

I do, however, have UINT128 and INT128. I wrote them sometime
around 2002. If you *really* would like, I could approach John
and ask how we could make these boost.ready. I also have UINT24
for embedded systems.

> Furthermore, it doesn't help me to build the int128_t that I want.

Again, the proposed Boost.Multiprecision is not aimed to
solve this problem. We can, however, talk about generating
a sensible back-end for binary fixed-size INT128 in the future,
as mentioned above.

> Although Multiprecision is divided into "front" and "back"-ends,
> this division is not in the right place to let me substitute my own
> backend that just provides the 128 bits of storage.

I disagree. Perhaps I am wrong. If you write INT128 with
the back-end requirements for an integer type, then it will
successfully be abstracted by mp_number.

> In the xint reviews, we suggested that the algorithms should
> be decoupled from the data structures and the same applies here.

(Please interpret this as my opinion. Others will have different opinion.)

In my opinion, the suggestion was not correct, but understandable.
Just because the proposed Boost.Multiprecision provides a template
abstraction for arithmetic operations and C99 elementary transcendental
functions, does not mean we would like the template itself to be modifiable.

We don't expect std::basic_string to provide a hookup-point for making a
better implementation of signed char. Rather, we expect basic_string to be
used with an existing character implementation that has traits and possibly
a special allocator. Similarly, it is not the role of the proposed
Boost.Multiprecision to allow customization of its limbs, add, multiply, divide, etc.
Boost.Multiprecision is a template, not the implementation. The reference
implementations for integer, rational and float that we provide are only
defaults for the reference application. The duty of achieving optimal
performance lies with the back-end author.

> Similarly, this implementation doesn't provide hooks that would
> allow me to substitute e.g. assembler implementations of the algorithms.
> Regards,  Phil.

(Please interpret this as my opinion. Others will have different opinion.)

This is correct for Boost.Multiprecision, and it is as it should be.
Please don't expect to put hand-written assembler optimizations in
the template. If you can do it better than GMP and MPFR,
then you must do it in the back-end---an entire back-end.

I hope I have clarified at least my opinion with this long response.

Best regards, Chris.