I've decided I will live dangerously and jump in on this thread. It is very
interesting, but a little academic for me, as I can't afford any of the systems that
are being discussed!


> Irix, Solaris, Digital UNix are all UNix variants that will run a native
> windowing system on top of a fairly standard Unix Sys5 kernel. Some run only
> X-based ressources, others have their own (Irix, SOlaris...) Depending on age,
> all these systems have migrated to full 64-bit. However, and this is important
> for the present purpose, the applications you use must *also* be compiled to
> take advantage the 64-bit hardware and OS. Most 32-bit apps (and even 16-bit
> apps) will run under 64-bit pathes but will not be able to avail themselves of
> performance improvements inherent in the architecture...

The 64bit alignment issue is one of the main reasons for the SDIF initiative at
CNMAT. This for me highlights the problem for us - 64bits are all very well, but so
much of our raw material is still at 16bit granularity, now edging towards 32 with
the f/p audio formats. So just how efficient is a 64bit machine going to be jiggling
all those shorts around? ( It must be even worse for text editing - unless, I
suppose, we all move over to Unicode).  How easy will it be to maintain source-code
portability across machines with such different architectures, when everyone wants
Csound optimized for their own machine?

I have always assumed that these machines are targeted  at the server market, where
the primary task is to shift huge blocks of data as quickly as possible. Even
Rhapsody, I have heard, is apparently being 'realigned' to this market, and may not
be released for use on 'ordinary' machines. A pity, as I was looking forward to this
as a significant new platform for digital audio ('At last - a Mac with a commandline
interface'!).

> err.. correction: there has been a full rewrite: Extended-Csound. That runs only
> on Sharc/ADI hardware

Hmm, well, I have the Analog card, and I am looking at the APIs which send a full
commandline to the card, the usage messages, and the 'instr alloc' messages, and the
error messages, and the absence of re-entrancy, and it seems to me that this is
still a port, and not quite a 'full rewrite', yet. Depending on which bits you look
at,  the SHARC  is a 32bit or 48bit chip, certainly not 64.

Just my eight-bytes worth...

Richard Dobson

Richard Dobson  writes:

> So just how efficient is a 64bit machine going to be jiggling
> all those shorts around? ( It must be even worse for text editing - unless,
> I suppose, we all move over to Unicode).  How easy will it be to maintain
> source-code portability across machines with such different architectures,
> when everyone wants Csound optimized for their own machine?

Any reasonable 64-bit architecture should be able to handle smaller
elements efficiently, given care.  Older Alphas were a bit of an
exception, since they lacked 8- and 16-bit load/store instructions;
that's been fixed, now.  But they (and all other 64-bitters I'm aware
of) have always handled 32-bit quantities quite efficiently--either
int's or floats--and usually only show their 64-bittedness by their
robust support for 64-bit quantities and their use of 64-bit addresses
(in C, "pointers").  They have the rather common characteristic of liking
N-bit entities aligned on N-bit boundaries, so Csound's use of pointers
implies 64-bit alignments for data structures.  This is what created
the problem I first described: Alphas have problems with Csound's
assumption that 32-bit alignment is "good enough" for pointers.

Folks who know about the whole 16-bit vs. 32-bit issue in the PC world
might assume that 32-bit vs. 64-bit is of a similar nature.  That's not
true, since the hairiest problem in the 16-bit to 32-bit conversion was
the change from segmented to linear addressing.  64-bit addressing is
still, in its basic form, linear, just like 32-bit addressing.  As long
as a program doesn't assume that sizeof(pointer) == sizeof(int), or
sizeof(int) == sizeof(long), and doesn't cast pointers from one type
to another, a simple recompile will take it from a 32-bit architecture
to a 64-bit architecture (modulo any OS issues).  Alas, Csound isn't
such a program.

I really don't think the issue is having Csound optimized for each and
every architecture.  A good C compiler should take care of most architecture
issues on its own.  The issue is that Csound's internal memory allocation
assumes that 32-bit granularity is sufficient and efficient, and takes
control away from the compiler by using type puns, pointer arithmetic,
and other on-the-metal C coding practices.  Csound's job is to turn the
orchestra and score files into sonic miracles as quickly as possible.
On a 32-bit CPU with 32-bit data paths, its assumptions are close to
optimal.  But computer hardware has evolved since Csound's core was
written, and those assumptions are starting to fail.  I think it is
quite possible to re-tune Csound away from these assumptions in a general
way, and bring it into the 64-bit world without any chip-specific
modifications.

After 3 paragraphs of excess verbiage, let me get concrete: three
changes, involving a half-dozen or so lines of code, made the central
score and orchestra processing of Csound 64-bit compatible.  The only
downside to these changes is that 32 bits of extra padding is occasionally 
"wasted" to bring things into alignment.  I'm almost certain that other
issues remain in specific table- and signal-generation units, but the
same basic technique will in all likelihood suffice in these areas as
well.  The downside: on 32-bit machines the extra padding is an
unnecessary waste of memory, so these changes should probably be a
compile-time option for 64-bit machines only.  There may be a more
sophisticated approach that reduces or eliminates the need for padding,
but the changes to Csound's mechanisms would undoubtedly be far greater.
My estimate is that about 5% more memory is consumed, on average, a
figure that would vary for different scores and orchestras...

		-Ed Hall
		edhall@ayched.com