Re: Code density and performance?


In article <3kpk31Fukb5lU1@xxxxxxxxxxxxxx>,
=?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen-not@xxxxxxxxxxx> writes:
|>
|> > |> Memory's cheap right? Heck, IPF memory requirements make
|> > |> Alpha look VAX-like. But seriously, it would take some pretty warped
|> > |> code for this to cause a memory utilization problem, and efficiency...
|> > |> well, things are usually faster/simpler when you can align on on a
|> > |> quadword.
|> >
|> > It wasn't when the Alpha was designed.
|>
|> What wasn't at that point in time - memory cheap, or aligned accesses
|> faster/simpler?

Memory wasn't that cheap, then. A factor of two increase (which
was sometimes needed) was a lot of money.

|> I believe that even on the VAX, you always got quadword-aligned blocks
|> on malloc() et al. And it was quite clear that at the latest with the
|> VAX 8600, aligned accesses were significantly faster than unaligned
|> accesses.

The first is irrelevant, as the issue is individual declarations
and arrays with elements distributed across CPUs. The overhead
of a quadword-aligned malloc is negligible in all except the most
extreme programs.

And please don't bring in red herrings. I am not talking about
unaligned accesses, but about aligned ones for objects smaller
than a 'memory unit'.

|> > It's not packed data. It is separate as far as the specification
|> > that the programmer is provided with.
|>
|> Which specification - POSIX!? That anything to do with POSIX and parallel
|> processing is terminally broken has been clear for a long time, so why
|> flog this particular dead horse again?

It is NOT just POSIX. It is virtually every 'third generation'
programming language from Fortran onwards, Unix and Unix-derived
systems (including Microsoft Windows) and many other operating
systems, too.

|> All other documentation I have seen made it quite clear what would work,
|> and what wouldn't, for parallel accesses...except for that little thing
|> that DEC's own compilers did go by the architecture spec and put some
|> instructions between LL and SC that weren't allowed, but happened to work
|> on the first implementations.

I never found any, and I looked. But I didn't look at the Alpha
VMS documentation, which may well have been better than the OSF/1
(a.k.a. Tru64) stuff.


Regards,
Nick Maclaren.
.