Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at