| Not quite so off-topic: I recently tried to get Csound 3.47 going on
a 533MHz Alpha running Linux, and ran into 64-bit alignment problems.
It seems that a number of Csound's data structures are allocated on
32-bit (== sizeof float) boundaries, though they contain pointers
(which are 64-bits on Alpha and must be so aligned). After some digging,
it's apparent that Csound insists on packing its own data structures
for memory efficiency reasons, with no provision for memory alignment
beyond 32-bits. Although some Alpha OSes (including Linux) will handle
the resulting alignment trap, performance is severely affected.
There are a couple of issues here:
1) 64-bit alignment is a must on Alpha (and likely other 64-bit chips).
My 233MHz AMD K6 runs rings around the Alpha due to the time spent
handling alignment traps in the kernel.
2) Given that many systems (including Pentiums) are more efficient with
data alignment of 64-bits (or greater), and that memory is now a lot
cheaper than it used to be, the whole idea of dense-packing data
structures in Csound deserves some reconsideration. Choosing speed
over compactness should at least be an option.
Tracking down the alignment traps which occurred during the processing
of one particular *.orc and *.sco set, I managed to patch up some
of the major alignment problems in score and orchestra processing in
fairly short order; the Alpha is now 3 times faster than the K6 (which
for Csound, at least, is as fast as comparable Pentiums). But there are
no doubt other parts of Csound, unused by this particular *.orc and *.sco,
which still aren't 64-bit clean.
I'll be happy to share my patches with anyone else attempting to get
Csound going on Alpha, and I'd be interested in hearing from anyone
else who has made progress along these lines.
-Ed Hall
edhall@ayched.com
|