4 ms·

> I guess the utterly competent designers were actually stupid eejits then? No, I don't think that. But I don't think they had some superhuman foresight either

by jabl 4y ago

> I guess the utterly competent designers were actually stupid eejits then? No, I don't think that. But I don't think they had some superhuman foresight either, and they made some decisions that in retrospect were not correct. And with the memory consistency model, they made the classic RISC mistake of encoding an idiosyncrasy of their early implementation into the ISA (similar to delay slots on many early RISC's). > You could learn a lot from it - I did. I used Alpha workstations, servers and supercomputers for my work for several years back in the day. They were good, but not magical, and even back then it was quite clear there was no long term future for Alpha.

_a_a_a_ 4y ago
I'm not a chip designer, far from it, but my understanding is that they really knew what they were doing and this was quite deliberate. See this comment https://news.ycombinator.com/item?id=17672467 https://news.ycombinator.com/item?id=17672467 I never suggested alphas were magical, but they did seem extremely good and they were designed for future expansion, it seemed to me they were killed off very much not by competitor supremacy. Good answr, thanks
- Tuna-Fish 4y ago
  It was a deliberate choice, but it was a poor one. It made implementing a fast cpu easier, but it also made the consistency model very hard for programmers to reason about, and required much more explicit barriers than any other consistency model. These barriers also meant that correct multi-threaded alpha code was no longer particularly fast, because you have to insert expensive memory barriers basically everywhere. Had Alpha not died early, they would absolutely have eventually moved towards a more strict memory model. As it was, it was essentially an irrelevant architecture by the time people started really hitting all the pitfalls.
  - _a_a_a_ 4y ago
    IIRC alpha-model memory barriers are still used in the linux kernel. That said, I can't find a clear statement of that so I don't know if it is true or was, or just my own memory. > These barriers also meant that correct multi-threaded alpha code was no longer particularly fast, because you have to insert expensive memory barriers basically everywhere. I don't buy it. MBs are for multi-core code, and in such code you typically do much work on a single core then have a quick chat with another core. So the MBs are there for the inter-core chatter only. In that case having fast monocore code is a big win.
    - jabl 4y ago
      > IIRC alpha-model memory barriers are still used in the linux kernel. That said, I can't find a clear statement of that so I don't know if it is true or was, or just my own memory. The various memory barriers and locking primitives are arch-specific code, and at least smp_read_barrier_depends() is a no-op on all architectures except Alpha. Apparently around the 4.15-4.16 kernels there was a bit of de-Alphafication going on which entailed removing much Alpha-specific code from core kernel code. Further in 5.9 {smp_,}read_barrier_depends() were removed from the core barriers, at the cost of making some of the remaining memory barriers on Alpha needlessly strong. For more info, search for Alpha e.g. in https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p0124r7.html https://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p0124r7... https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2022.09.25a.pdf https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul...
      - _a_a_a_ 4y ago
        Another cracking answer, I'll have a dive in this evening, thanks.

by jabl 4y ago

_a_a_a_ 4y ago

I'm not a chip designer, far from it, but my understanding is that they really knew what they were doing and this was quite deliberate. See this comment https://news.ycombinator.com/item?id=17672467 https://news.ycombinator.com/item?id=17672467 I never suggested alphas were magical, but they did seem extremely good and they were designed for future expansion, it seemed to me they were killed off very much not by competitor supremacy. Good answr, thanks

Tuna-Fish 4y ago
It was a deliberate choice, but it was a poor one. It made implementing a fast cpu easier, but it also made the consistency model very hard for programmers to reason about, and required much more explicit barriers than any other consistency model. These barriers also meant that correct multi-threaded alpha code was no longer particularly fast, because you have to insert expensive memory barriers basically everywhere. Had Alpha not died early, they would absolutely have eventually moved towards a more strict memory model. As it was, it was essentially an irrelevant architecture by the time people started really hitting all the pitfalls.
- _a_a_a_ 4y ago
  IIRC alpha-model memory barriers are still used in the linux kernel. That said, I can't find a clear statement of that so I don't know if it is true or was, or just my own memory. > These barriers also meant that correct multi-threaded alpha code was no longer particularly fast, because you have to insert expensive memory barriers basically everywhere. I don't buy it. MBs are for multi-core code, and in such code you typically do much work on a single core then have a quick chat with another core. So the MBs are there for the inter-core chatter only. In that case having fast monocore code is a big win.
  - jabl 4y ago
    > IIRC alpha-model memory barriers are still used in the linux kernel. That said, I can't find a clear statement of that so I don't know if it is true or was, or just my own memory. The various memory barriers and locking primitives are arch-specific code, and at least smp_read_barrier_depends() is a no-op on all architectures except Alpha. Apparently around the 4.15-4.16 kernels there was a bit of de-Alphafication going on which entailed removing much Alpha-specific code from core kernel code. Further in 5.9 {smp_,}read_barrier_depends() were removed from the core barriers, at the cost of making some of the remaining memory barriers on Alpha needlessly strong. For more info, search for Alpha e.g. in https://www.kernel.org/doc/Documentation/memory-barriers.txt https://www.kernel.org/doc/Documentation/memory-barriers.txt https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... https://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p0124r7.html https://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p0124r7... https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2022.09.25a.pdf https://mirrors.edge.kernel.org/pub/linux/kernel/people/paul...
    - _a_a_a_ 4y ago
      Another cracking answer, I'll have a dive in this evening, thanks.