11 ms·

It wasn't better. Observe: "According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's en

• mhh__ 3y ago
  Who cares about the memory model being weak? Arm is really weak too.
  • jeffbee 3y ago
    Alpha is extra-weak. As in, even with dozens of grizzled systems programmers at the table you will still not be able to reason about the observable result of any sequence of loads and stores. This is at least a developer productivity issue, and becomes a performance issue if you are inserting fences all over the place whether they are required or you just aren’t sure.
    • wbl 3y ago
      Only if you have racy accesses which you should not.
      • jeffbee 3y ago
        If you think it's that simple you are exactly the kind of developer who would never have succeeded in programming the DEC Alpha. On the Alpha, even dependent loads and stores can be reordered by the hardware and observed in any non-program order on other CPUs. So if CPU 1 sets X to 42 and takes the address of X, and CPU 2 dereferences X, it can observe any value of X, 42 or whatever, even if both CPUs used explicit memory fences with regards to the address of X. This was so hard to grok that the Linux kernel was broken on Alpha during the entire lifetime of the CPU, not fixed until January 2018. The Alpha is so weak and hard to use that half the C++11 explicit memory ordering stuff is only relevant to that CPU.
        • mhh__ 3y ago
          How many people independently need to work it out? I doubt most python programmers know what atomics are and yet they persist.
          • jeffbee 3y ago
            In this context it is relevant. Nobody was programming anything in Python in 1992. The question is, how much of Alpha's apparent performance was real, and how much was due to the missing memory barriers causing programs to go faster and produce surprising (incorrect) results, interspersed with the odd mysterious crash?
            • mhh__ 3y ago
              How many threaded programs in general were there? The only SPEC (or SPEC-like) benchmarks I tend to pay attention to are single-threaded, multi-process (i.e. compile times) - Unless these bugs were in te kernel I'd imagine most unix-y workflows would be unaffected.
            • notacoward 3y ago
              I don't think you're giving much credit to people who were programming multi-processor systems at that time. As @mhh_ points out, the vast majority weren't writing code that was multi-threaded at all. Of those who were, fewer still were writing the kind of code that was so tightly synchronized that these issues would even surface. OS engineers (such as myself) and others who did so were typically much closer to the hardware and aware that it was a rapidly evolving field, so they knew to watch out for these kinds of land mines. If you want to cite "surprising results" and "odd mysterious crashes" try making it more than conjecture by providing some data. I was there and such things didn't seem particularly more common on Alpha than elsewhere. Years later, as I said somewhere in this thread, I worked with another (MIPS-based) chip designed by some of the Alpha engineers, with the same predilection for weak memory ordering. In about two years, I found three bugs related to missing memory barriers - one in NFS, one in NBD, and one in Lustre (which isn't even part of the kernel). Yes, they were a pain to debug. Part of the reason is that they would occur so damn rarely. Damn near 100% of the time the "vulnerable" code would run just fine anyway. Writing reproducers was a serious challenge. More importantly, these bugs were dwarfed by bugs of many other more familiar types - use after free, deadlock, protocol errors, etc. Any bugginess attributable to the weak memory model was noise. So yeah, Alpha's performance was very real. Using hypotheticals to bash it in pseudo-retrospect seems uncharitable, to say the least.
    • hinkley 3y ago
      Alpha was my introduction to the term NUMA.
    • mhh__ 3y ago
      Still doesn't matter much. How many times have you actually cared about atomics, even ignoring that the most common case by miles is 0 contention - for productivity you just get it right once and reuse the code. Especially for the time, most code has been and is painfully single threaded, only really relenting quite recently. Having an extremely strong memory model is also potentially a performance issue because the CPU is much more expensive for the same performance.
  • peterfirefly 3y ago
    Not quite as weak, though. Alpha's was absurdly weak.
• spamizbad 3y ago
  I don't think weak memory models are inherently bad. It's a trade-off. Keep in mind it was conceived during the early days of SMP - there wasn't the industry preference for stronger models, which was largely a side-effect of x86 chips choosing that approach with SMP years later.
  • hinkley 3y ago
    And everyone wanting to be able to claim top shelf Java support. Say what you will about Java, but a lot of OSes and hardware had to get a lot better at multithreading pretty quickly or be relegated. Even Solaris struggled for a time.
  • chasil 3y ago
    > "early days of SMP" This is vastly incorrect. UNIX was ported to the Univac architecture in the late '70s. It ran as a client on EXEC 8, and was the first SMP implementation. "The UNIVAC 1108 computer was announced in 1964 and delivered in late 1965. The first 1108 computers used Exec I and Exec II, which had been developed for the UNIVAC 1107. However, UNIVAC planned to offer symmetric multiprocessor versions of the 1108 with up to 4 processors and the earlier operating systems (really basic monitor programs) weren't designed for that, even though they supported limited multiprogramming." https://en.wikipedia.org/wiki/OS_2200 https://en.wikipedia.org/wiki/OS_2200
    • spamizbad 3y ago
      The 1108 had simplistic memory protection and didn't have cache so there was no concerns around cache coherency. The 1100/80 which came 15 years later finally introduced a cache that was really just a buffer and, to my knowledge, had no coherency scheme largely because of the way the architecture of those systems worked. The Alpha team was working on a much more sophisticated system and had to solve a much coherency problem. Weaker models allow greater throughput and save transistors (and reduce power/heat) at the expense of more carefully written software and operating systems.
• notacoward 3y ago
  Yes, it had a weak memory model, which I had to deal with when I was working with a chip subsequently designed by some of the same people so I know its drawbacks better than most. But saying that means it wasn't better is a non sequitur unless your only standard is the strength of the memory model. The weak memory model is, in a way, a continuation of the RISC philosophy: drive up clock speed and IPC by moving complexity from hardware to software. Just like load and branch delays, or (spit) register windows. As time has gone by we've gotten better at hiding those things under a hardware front end, but at the time it was a good choice borne out by the massive success of machines - not just DEC's - based on that philosophy. Yes, it was a pain to deal with, but achieving top-tier performance has always been a pain one way or the other.
• hinkley 3y ago
  The Alpha was the first machine I saw with something approaching a modern heat sink. In that era the thing was ridiculous. It was the next generation of Intel and AMD hardware where users started learning about heat sinks. Things like you could fry your CPU in under a second if you accidentally turned it on with no heat sink.
• sillywalk 3y ago
  For somebody who knows little about these topics, why was the memory model made the way it was? I assume it's so that the chip would be simpler / more RISCy, and faster?
  • FullyFunctional 3y ago
    Weaker => more freedom to reorder => issue loads sooner => higher IPC/perf. Really that simple. You can get some of this with speculation and later checking, but that has its own costs and limitation. People feel _very_ strongly about these topics. RISC-V eventually compromised and allows both TSO (~ x86) and a weak model (~ Arm). As far as I know, all commercial silicon supports the weak model and I suspect they only support that.
• FullyFunctional 3y ago
  "Better" depends on your metric. It is obviously easier to make a wide OoO superscalar implementation based on the Alpha ISA, but the archaic 32-bit x86 probably had slightly better code density. I'd love to know the assumptions behind the claim that a low-power Alpha couldn't be made. Maybe it was as simple as comparing a 32-bit CPU with 16 registers to a 64-bit CPU with 32 registers (4X the leakage for RF alone and > 2X the data path cost). Aarch64 is a bigger ISA than Alpha so I guess we crossed that bridge.