Re: Revised Motion 26 decoration scheme
On 2011-07-20 09:42:40 -0500, Nate Hayes wrote:
> Vincent Lefevre wrote:
> >As long as you don't need a format for data interchange between two
> >different applications, this is not a problem. The compiler could
> >optimize to store data in some more optimized way than taking a
> >full 32-bit or 64-bit word for the decoration (e.g. by packing
> >decorations in a word).
>
> It doesn't matter. In fact, now the problem might be worse, since you are
> breaking the interval data into different pieces with different memory
> alignments: there is more memory locations to be accessed and some of those
> memory locations are now more likely not to be aligned.
>
> So memory traffic on the bus increases, the cache is more heavily taxed, and
> many of the moves may be unaligned (which as Ian points out are even more
> detrimental to performance).
That's the goal of the compiler to ensure that data are aligned. For
instance, if a 64-bit alignment is OK, then 8 decorated intervals
(I1,D1), ..., (I8,D8) could be stored in the following way:
I1 I2 ... I8 [D1 D2 ... D8]
where the 8 decorations are packed in a 64-bit word (4 would be
sufficient for a 32-bit alignment).
Of course, packing in such a way should be done with data locality
in mind. There may be compromises between the efficiency of packing
and the locality.
> >I suppose that concerning (b), you would want the size of a FP datum
> >to be reduced, so that it is possible to store the decoration in the
> >holes?
>
> No.
>
> Bare intervals and bare decorations can fit in those holes using standard
> IEEE 754 bit patterns.
Do you mean dropping decorations when an interval needs to be returned?
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)