4 ms·

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

by xxs 3y ago

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.

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

by 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.