[PD] 64 bit PD
matju at sympatico.ca
Tue Sep 7 13:25:25 CEST 2004
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 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
More information about the Pd-list