4 ms·

DEC Alpha had the weakest memory model, which while cool to write for with its all memory barriers/concurrency - it's quite annoying to work with in the real wo

by xxs 3y ago

DEC Alpha had the weakest memory model, which while cool to write for with its all memory barriers/concurrency - it's quite annoying to work with in the real world, a major reason while DEC failed.

jacquesm 3y ago
Compared to the madness that was x86 memory models the Alpha was quite sane. I'm not sure what you base your 'weakest' on (it suggests a comparison with others) but when Alpha was released there wasn't much to compare it to besides the R4000 and that just as hard if not harder to source than the Alpha machines were. I had a bunch of them (SGI boxes of various plumage) and the OS hardly took advantage of the chip, but on the Alpha it all just worked at 64 bits out of the box.
- xxs 3y ago
  >I'm not sure what you base your 'weakest' Linux kernel has memory barriers, Alpha makes an exception with needing virtually all of them - with other architectures (esp. the total store order ones) some (most) of the barriers are nop. Yet, overall Alpha is famous for how crazy the memory model is. There is nothing like any longer (personally I am happy with Java Memory Model). Just to make sure it's understood "weak" attributed to :memory model: just means how concurrent with regards to reads and writes it is. A quote[0]: AND THEN THERE'S THE ALPHA -------------------------- The DEC Alpha CPU is one of the most relaxed CPUs there is. Not only that, some versions of the Alpha CPU have a split data cache, permitting them to have two semantically-related cache lines updated at separate times. This is where the address-dependency barrier really becomes necessary as this synchronises both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. [0]: https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt
  - jacquesm 3y ago
    That's what allows the Alpha to be multi-processor. And if you like the 'Java Memory Model' I'm not sure what your point really is, you're comparing a virtual machine with actual hardware.
    - xxs 3y ago
      >you're comparing a virtual machine with actual hardware. The memory model is meant for developers - and how many&different memory barriers they have to issue.
      - jacquesm 3y ago
        Your typical Java developer has zero knowledge about this and on the UNIX versions that shipped with the Alpha (for me, at the time that was RedHat) fairly elegantly hid that complexity to the point that you could just forget about it unless you cared about extreme performance. In my case the ability to address large amounts of memory and a filesystem that wasn't limited by the 32 bit limitation was the key factor and while it took another decade for x86 to catch up I was happily shipping.
        xxs 3y ago
        >Your typical Java developer has zero knowledge about this That's bit much of stereotyping, depends I guess - "Java Concurrency in Practice" is one of the most sold books (when it comes to Java), and it covers some parts quite well. I have met quite a few folks that understand the matters pretty well, admittedly part of jsr-166. It was the "double-checked idiom" vs the original Java memory model is effectively what brought sane memory models even to C++. >unless you cared about extreme performance That's the whole purpose of the weak memory models. Albeit, they did fail to deliver - very error prone, close to impossible to debug, effectively outclassed by x86-64 and Sun Sparc (both being total store order), even arm-64 became "stronger".
        jacquesm 3y ago
        > That's bit much of stereotyping, depends I guess - "Java Concurrency in Practice" is one of the most sold books (when it comes to Java), and it covers some parts quite well. That's because Java concurrency in practice is harder than it should be. I've seen plenty of teams struggling with what should be trivial problems trying to work their way around the various limitations and/or bugs in the JVM. > Albeit, they did fail to deliver - very error prone, close to impossible to debug, effectively outclassed by x86-64 and Sun Sparc (both being total store order), even arm-64 became "stronger". That's true, but at that time those weren't shipping 64 bit systems. It was pretty much R4000, Alpha or bust and the Alpha - even taking into account those limitations - worked surprisingly well for real world problems. In fact the systems that I'm talking about worked non-stop for more than a decade until they got de-commissioned and I never heard a single peep from those that took over the project that the memory model of the Alpha was somehow either a problem in practice or a concern. Could it have been done better: sure, but with the knowledge of the time these seemed to be pretty reasonable choices and compared to what the alternatives were they were doing great. If anything the failure of the Alpha architecture is one of marketing more than anything. Pjlmp has some good information elsewhere in this thread, which pretty much corresponds with my experience of the time. There were some systems on the drawing board that were better in theory and they were still better in theory 10 years later, meanwhile DEC was shipping. That they squandered their head start has nothing to do with the memory model, but everything to do with how they ran their business.

by xxs 3y ago

DEC Alpha had the weakest memory model, which while cool to write for with its all memory barriers/concurrency - it's quite annoying to work with in the real world, a major reason while DEC failed.

jacquesm 3y ago

Compared to the madness that was x86 memory models the Alpha was quite sane. I'm not sure what you base your 'weakest' on (it suggests a comparison with others) but when Alpha was released there wasn't much to compare it to besides the R4000 and that just as hard if not harder to source than the Alpha machines were. I had a bunch of them (SGI boxes of various plumage) and the OS hardly took advantage of the chip, but on the Alpha it all just worked at 64 bits out of the box.

xxs 3y ago
>I'm not sure what you base your 'weakest' Linux kernel has memory barriers, Alpha makes an exception with needing virtually all of them - with other architectures (esp. the total store order ones) some (most) of the barriers are nop. Yet, overall Alpha is famous for how crazy the memory model is. There is nothing like any longer (personally I am happy with Java Memory Model). Just to make sure it's understood "weak" attributed to :memory model: just means how concurrent with regards to reads and writes it is. A quote[0]: AND THEN THERE'S THE ALPHA -------------------------- The DEC Alpha CPU is one of the most relaxed CPUs there is. Not only that, some versions of the Alpha CPU have a split data cache, permitting them to have two semantically-related cache lines updated at separate times. This is where the address-dependency barrier really becomes necessary as this synchronises both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. [0]: https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt
- jacquesm 3y ago
  That's what allows the Alpha to be multi-processor. And if you like the 'Java Memory Model' I'm not sure what your point really is, you're comparing a virtual machine with actual hardware.
  - xxs 3y ago
    >you're comparing a virtual machine with actual hardware. The memory model is meant for developers - and how many&different memory barriers they have to issue.
    - jacquesm 3y ago
      Your typical Java developer has zero knowledge about this and on the UNIX versions that shipped with the Alpha (for me, at the time that was RedHat) fairly elegantly hid that complexity to the point that you could just forget about it unless you cared about extreme performance. In my case the ability to address large amounts of memory and a filesystem that wasn't limited by the 32 bit limitation was the key factor and while it took another decade for x86 to catch up I was happily shipping.
      - xxs 3y ago
        >Your typical Java developer has zero knowledge about this That's bit much of stereotyping, depends I guess - "Java Concurrency in Practice" is one of the most sold books (when it comes to Java), and it covers some parts quite well. I have met quite a few folks that understand the matters pretty well, admittedly part of jsr-166. It was the "double-checked idiom" vs the original Java memory model is effectively what brought sane memory models even to C++. >unless you cared about extreme performance That's the whole purpose of the weak memory models. Albeit, they did fail to deliver - very error prone, close to impossible to debug, effectively outclassed by x86-64 and Sun Sparc (both being total store order), even arm-64 became "stronger".
        jacquesm 3y ago
        > That's bit much of stereotyping, depends I guess - "Java Concurrency in Practice" is one of the most sold books (when it comes to Java), and it covers some parts quite well. That's because Java concurrency in practice is harder than it should be. I've seen plenty of teams struggling with what should be trivial problems trying to work their way around the various limitations and/or bugs in the JVM. > Albeit, they did fail to deliver - very error prone, close to impossible to debug, effectively outclassed by x86-64 and Sun Sparc (both being total store order), even arm-64 became "stronger". That's true, but at that time those weren't shipping 64 bit systems. It was pretty much R4000, Alpha or bust and the Alpha - even taking into account those limitations - worked surprisingly well for real world problems. In fact the systems that I'm talking about worked non-stop for more than a decade until they got de-commissioned and I never heard a single peep from those that took over the project that the memory model of the Alpha was somehow either a problem in practice or a concern. Could it have been done better: sure, but with the knowledge of the time these seemed to be pretty reasonable choices and compared to what the alternatives were they were doing great. If anything the failure of the Alpha architecture is one of marketing more than anything. Pjlmp has some good information elsewhere in this thread, which pretty much corresponds with my experience of the time. There were some systems on the drawing board that were better in theory and they were still better in theory 10 years later, meanwhile DEC was shipping. That they squandered their head start has nothing to do with the memory model, but everything to do with how they ran their business.