[PD] 64 bit PD

[Mathieu Bouchard]

On Tue, 7 Sep 2004, Tim Blechmann wrote:

> > By 'move' do you mean process calculations on the CPU?  You would be 
> > describing SIMD and really bad MMX style SIMD at that.  Modern CPUs 
> > have 128 bit wide vector units like Altivec and SSE which are
> > fantastic if actually used.
> the main question is, what can the compiler actually do with the
> hardware ... 
> i'm not familiar with the amd64 architecture, but i suppose it's similar
> to simd instructions ... 

I haven't read much about amd64, but I suppose the major contributions of
a "64-bit architecture" are, on average, mainly that sizeof(any *)==8 and
that all int64 operations are faster.

SSE/SSE2 (which also could be called MMX3/MMX4) support vector opcodes on
registers that are float32[4] each, that is, 128-bit at once; that's
available on P3 and K7, so you don't need a K8 for that.

> - and the compiler will have to know the instructions and _use_ them ...
>   as for now i can say that any compiler i tried (gcc 3.2/3.3, icc) had
>   problems generating the optimal sse instructions ... (this is possibly
>   related to dsp block allocation as it's done in pd at the moment)

I noticed that with GNU C Library, the malloc() function only guarantees
4-byte alignment, which is why GridFlow-0.8 now uses two pointers in the
Grid data structure: one for the pointer that malloc() actually returned,
and another that has guaranteed 8-byte alignment (i may also try 16-byte
alignment in the future). This means all Grids have to be slightly
overallocated but usually that's not a significant amount compared to the
size of the Grid.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju