On Fri 4/22/2011 2:32 AM, Vicente BOTET wrote:
In most cases, smaller WILL be the faster implementation. Where this is not the case, the compiler can hopefully help out and provide most of the benefits of hand-tuning for a particular architecture.
Maybe sometimes, but not always. So I will prefer to been able to state explicitly if I need the smallest builtin representation or the faster one. Up to the implementation to ensure that.
For how many architectures and generations do you expect this to be optimized? Don't forget that what might be faster to compute in registers could result in a much more significant performance drop, once arrays of these numbers are written/read to/from memory. Using smaller types also tells the compiler whether there's useful information in the MSBs, enabling the compiler to do more optimizations. IMO, smaller is the safer bet, performance-wise. If a user knows that a given CPU is going to do 64-bit arithmetic faster than 32-bit or 16-bit, then the user typically has the option to coerce this behavior by padding out the MSBs. And as a last resort, there's always the option to hand-code select parts. That said, if there's a way to influence the type used for internal representation without a lot of interface clutter/baggage (e.g. some kind of traits interface), I'd be all for it. But my expectation would be for knowledgable users to use it for their own tuning, rather than any promises made by the library.
I think the result type should be deduced from the parameters type and the operation of course. We need of course to consider when the resulting type can not be represented using the available builtin types.
Agreed. A static assert is one option. As a user, I want to be notified when I might inadvertently lose range or precision. When this happens, I would then perform an explicit conversion to a type with fewer significant bits *before* the operation. Either that, or perhaps invoke a named, "unchecked" function, in place of the operator. Matt