Thank you for your review, Phil.
Here is my review of the proposed Multiprecision review.
First a rant: why have so few people contributed to the discussion or written reviews?
<snip> The culprit can only be.... the European Soccer Championships quarter finals! Double over-time and eleven meter, going Italy-England with both teams playing exceptional soccer! <snip>
In particular, I'd like to be able to implement integers of perhaps 128 or 256 bits that behave like the built-in integers. I can quickly throw together something myself that works OK but:
- It's difficult to get the last bit of performance because you need to write asm to use the CPU's carry flag; the work-around probably results in a 2X slowdown. - Writing all the operator overloading etc. is tedious. - It's also error prone, as a mistake in e.g. carry propagation might be detected once in very 2^32 operations.
Again, I see the addition of large numeric types as a long game. Consider the following progression of performance and abstraction. 1) The best of both worlds would be to write highly optimized signed and unsigned versions of integers with 128, 256, 512 and 1024 bits. 2) To the integer types, one should add a highly optimized floating-point (software) implementation of quadruple-precision as specified in IEEE-754:2008. 3) Make these (lower-level) primitives inter-changeable among each other. 4) For larger types, then, one would make the transition to multiple-precision and a higher level of abstraction. John's and my work has focused on part 4. There is, however, no reason to discontinue work on parts 1-3. May I comment, again, on your comment above?
- It's difficult to get the last bit of performance because you need to write asm to use the CPU's carry flag; the work-around probably results in a 2X slowdown.
I don't want to disappoint you, but to be blunt, you need to free yourself from assembly programming. The microprocessor will be twice as fast and half again as expensive in three years or less---no later than the silicon manufacturers do another technology shrink. Take it from an "old-hand" micro-controller professional. Providing for assembly hacks will always lead to portability issues, end-user confusion and a general distraction from high-level C++ that is the whole point of boost in the first place. If you get the algorithms right, it will be fast enough in silicon in the C++ language. Believe it or not, I see great potential in your negative review. This is because your review clearly illuminates the transitional points 1-3 that I suggested above. But I stand by my statement that you have to start somewhere and this is on what multiprecision has focused. Thanks again for taking time to review. Best regards, Chris.