On Fri, 05 Jun 2020 21:21:24 +0100, Gareth Evans wrote:

> I was talking here recently of the possibility of a Dreadnought 64-bit
> only language for the RPi, but it seems that I might have been pipped at
> the post by the DEC Alpha.
>
> As far as I can gather, the Alpha instruction set only supported 64 and
> 32 bit variables.
>
> Am I misinformed?
>
If I'm reading this: https://en.wikipedia.org/wiki/DEC_Alpha - right, it
could always address individual bytes in RAM but didn't have any opcodes
that could operate on bytes or 16 bit ints before EV56.

I designed and programmed a system that ran on Alphaservers in 1999-2001
but IIRC these were EV4 or EV5 chips, running DEC's Mach-based Unix and
were programming in C. I was certainly using char and char[] array
variables but never needed to peer into C's guts to see what it was up to
at the memory addressing level or how it messed with chars in those 32
bit registers.

I only found two performance crimes in the innards of the Alpha chip or
DEC Unix:

(1) the Mach kernel could multi-task different low-level API-modules but
insisted on single-threading queues for each different API-module, which
could and did give horrid performance (think of a data warehouse with
with a segmented fact table - any time you applied, say chmod() or a
resizing operation to it this affected all its segments and so the
operation was horribly slow because the Mach kernel serialised the
operation as applied to each individual segment.

(2) we did a lot of stuff using very large in-memory B-trees, but it
turned out that each node needed 3 mallocs (pointers, key and data all
had separate, linked chunks of memory) so operations such as building a
large tree were also very slow because (surpise!) malloc was serialised
too). The development server (with an EV4 chip) could never add nodes at
better than 700/sec using library code. We discovered that malloc() speed
was the problem, rewrote the B-tree code (thanks Sedgewick!) to use one
malloc per node and got a 3x speedup to 2100/sec Not enough. We needed at
least 7500/sec, so I wrote a new memory scheme in which malloc() grabbed
RAM in megabyte multiples and stacked the B-tree nodes in these chunks,
grabbing another as the current one got filled. This got the speed up to
25,000/sec so this particular issue was never a problem after that.

Apart from these two points, the Alpha servers were great: even the EV4
box could support 10 developers, each with two logins and their own
datawarehouse instance. At the time this was something I didn't expect to
see, considerng that server was small enough to live under one of our
desks.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05