Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-point numbers

Subject: Re: [boost] [boostcon][proto] Suggestion for LIAW session: fixed-point numbers
From: Ravi (lists_ravi_at_[hidden])
Date: 2011-04-24 00:12:02

On Friday 22 April 2011 00:04:31 Gruenke, Matt 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 could not figure out a way to change the underlying type based on some 
traits. As far as a suggestion for LIAW goes, this detail is immaterial. 

As Matt stated earlier, his view is that the underlying type is part of the 
contract, while mine is that the underlying type is an implementation detail. 
My experience with modern CPUs (limited to some x86_64 chips, MIPS, some ARM 
variants and one proprietary embedded processor) in conjunction with maximal 
optimization by modern compilers has led me to discover no general patterns; 
smaller types have been slower as often as they have been faster, even with 
arrays of numbers. In fact, for some problems with very little branching, 
floating point arithmetic was much faster. If the underlying type truly needs 
to be specified, we could use a preprocessor definition.

However, all of this is irrelevant to the idea of fixed-point numbers for a 
LIAW session. We have heard from neither Jeff Garland nor Hartmut Kaiser. 
Until we hear from them, I am doubtful that a proto-based LIAW session would 
be considered feasible by the Boostcon organizers.

Regards,
Ravi