3 ms·

>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 architect

by 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.
- formerly_proven 3y ago
  The "oh we can't make the cache as big as we'd like so we just make it two fully independent banks and bake the lack of synchronization of them into the ISA" in DEC Alpha very clearly falls into the "baking restrictions of today into the ISA", which virtually always turns out to be a bad idea.
  - jacquesm 3y ago
    That I'll be happy to agree with but compared to the 640 k limit it's clearly a manageable one, and one that end users of the system normally do not have to concern themselves with. I've written a (small) OS for x86/32 just prior to getting my hands on an Alpha and compared to that the Alpha looked (and still looks) like a model of sanity to me (as does 68xxx). Just the number of tricks required to get an x86 system properly booted up is off the scale, you have to deal with a whole pile of memory insanity including repeated switches between modes (and memory models) in order to get your stuff even loaded. I spent weeks debugging that loader, to the point that I had a reset switch connected to a musical instrument foot pedal so I didn't have dive under the desk 10 times per hour to reset the box I was writing this on. If not for DJGPP to validate the 32 bit code ahead of time I doubt I would have been able to bring it up at all (note this was well before VMs became a thing on consumer hardware).
- monocasa 3y ago
  Java was one of the first machines (virtual or physical) to take a stab at defining its memory model in modern way. It's also pretty sane while also scaling to large systems as Azul's 768 core boxes showed.

by xxs 3y ago

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.
formerly_proven 3y ago
The "oh we can't make the cache as big as we'd like so we just make it two fully independent banks and bake the lack of synchronization of them into the ISA" in DEC Alpha very clearly falls into the "baking restrictions of today into the ISA", which virtually always turns out to be a bad idea.
- jacquesm 3y ago
  That I'll be happy to agree with but compared to the 640 k limit it's clearly a manageable one, and one that end users of the system normally do not have to concern themselves with. I've written a (small) OS for x86/32 just prior to getting my hands on an Alpha and compared to that the Alpha looked (and still looks) like a model of sanity to me (as does 68xxx). Just the number of tricks required to get an x86 system properly booted up is off the scale, you have to deal with a whole pile of memory insanity including repeated switches between modes (and memory models) in order to get your stuff even loaded. I spent weeks debugging that loader, to the point that I had a reset switch connected to a musical instrument foot pedal so I didn't have dive under the desk 10 times per hour to reset the box I was writing this on. If not for DJGPP to validate the 32 bit code ahead of time I doubt I would have been able to bring it up at all (note this was well before VMs became a thing on consumer hardware).
monocasa 3y ago
Java was one of the first machines (virtual or physical) to take a stab at defining its memory model in modern way. It's also pretty sane while also scaling to large systems as Azul's 768 core boxes showed.