3 ms·

“It runs quite slowly, (486-levels of performance on a Ryzen 5000 series according to this discord channel)” I’m sure there’s a joke about that being a huge le

by qubex 2mo ago

“It runs quite slowly, (486-levels of performance on a Ryzen 5000 series according to this discord channel)” I’m sure there’s a joke about that being a huge leap in performance for Windows on IA-64 over the past 23 years waiting to be made from this.

Joel_Mckay 2mo ago
To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3
- qubex 2mo ago
  Yeah EPIC pushed too much effort onto compilers and removed the context awareness of out of order reordering etc and the result was just a lame duck.
  - Joel_Mckay 2mo ago
    [flagged]
    - kstrauser 2mo ago
      You've mentioned Intel's compilers a few times but they're not a magic thing that could make Itanic not-suck. Suppose they make general purpose code that's twice as fast as GCC when the whole computer is dedicated to running one specific process. They don't, but let's pretend. Even in that ideal scenario, it falls apart as soon as you're processing unpredictable input. VLIW sucks hard at chewing through data that's not precisely what it's expecting. You could probably make a video codec that performed really well, but it would be impossible to make a database that performed consistently not-badly. It's not that the existing compilers weren't good enough, not even the magic Intel ones. It's that it's not possible to pre-generate VLIW opcodes that do well when the input value isn't a homogeneous stream. Even if Intel's code was 2x better than GCC's — and again, it wasn't — twice abominable was still abominable. I wasted more time SSHed into an Itanic than most people had to, so I'm speaking from first-hand experience. Some very, very specific Itanium code was a bit faster than the equivalent x86 or similar. That was always some very tightly scoped thing that did the exact same tight loop a gazillion times, like en-/decrypting a data stream. Anything more heterogenous ran poorly, as in multiple times the wall-clock time of the same workload on the x86 server next to it that cost a tenth as much. And that's even when using the magic Intel compilers. Itanium was bad. The compiler tech didn't exist to make it not-bad, and in retrospect I think it become obvious that it couldn't exist. It wasn't a matter of the compiler authors needing to be clever. It was more like making Itanium live up to the hype required making P=NP.
      - Joel_Mckay 2mo ago
        My point was most modern software developers still do not understand systems at an architectural level. I don't buy the VLIW paradigm was inherently inferior argument, but the code written for it with mystery failure modes at the time was a mess. And ia64 was only around 23% slower and several times more costly than amd64 options at the time. Both toads had their warts, but one was actually usable by mere mortals. Its true just about everything either ran slow on not at all on ia64... Thankfully, we were still running Sparc based platforms at that time, as the Intel clown-show still looked like more work. But I do empathize with the ia64 trauma, as the roll out had a lot of collateral damage in some firms as people started jumping ship early to avoid accountability. =3
        qubex 2mo ago
        One immediate advantage that rescheduling-capable cores have that rigid compiler-based ones don’t nor ever would is that reschedules can notice patterns in execution in the current context and keep the ALU fed from well-provisioned caches even going as far as speculative execution. IA-64 and typeless or typed-at-runtime (JIT scripts, for example, like JavaScript or Python) would’ve been implemented very differently on Itanium.
    - abbeyj 2mo ago
      I think they meant EPIC https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio..., not EPYC https://en.wikipedia.org/wiki/Epyc https://en.wikipedia.org/wiki/Epyc.
      - Joel_Mckay 2mo ago
        Indeed, my point was not all chips do well with Desktop application loads. People were bad at handling parallelism with ia64, and still have problems today on better amd platforms with less janky compilers. The fact an $800 chip still can beat a $14000 chip at some tasks probably should tell people something about concurrency scaling overhead. =3
        qubex 2mo ago
        EPIC was Explicit Parallel Instruction Computing, the underlying engineering architecture of AI-64. Epyc is an AMD brand name. And pivoting to concurrency on a rescheduler-intensive core as opposed to concurrency on a scheduler-based core isn’t very pertinent, particularly since we have 25 years of Moore’s Law between then and now.
        Joel_Mckay 2mo ago
        "AI" responses are silly, and optimal 24 core count efficiency premise in Desktop applications offer diminishing returns on a highly concurrent 32/64/192 core Epyc line of OoO chips... How many strings does a Bass play with in water? =3
    - shrubble 2mo ago
      EPIC is Explicitly Parallel Instruction Computing; nothing to do with the AMD trademark word, EPYC.
      - Joel_Mckay 2mo ago
        Indeed, the post does not conflate the two... look closer. =3
- bri3d 2mo ago
  No (sorry, I post this every time the Mythical Compiler Myth reappears), the problem with VLIW is that it fundamentally doesn’t work for anything with unpredictable memory access patterns, and modern general purpose computing has moved almost exclusively in this direction. For VLIW to work, you need to either guess correctly what is in cache or not have a cache at all; as soon as you mispredict what has been loaded, you stall while an OoO processor keeps going and a speculative OoO processor even keeps guessing. With multiple workloads on the same hardware (virtualization, multitasking, multitenancy) this becomes an intractable problem even in the presence of the magic compiler which can solve for software based unpredictability (branch likelihood and pointer chasing), because every context switch clobbers an unknown set of cache lines and blows the entire thing up. VLIW works for single workloads. It works exceptionally well for single workloads with no or explicit cache like DSP. You can trade the footprint and complexity from OoO for a wider execution unit and more SRAM. It works well for HPC, too, for the same reason. But for anything where more than one process exists, it just really doesn’t work, and that’s most modern workload. Itanium also has a unique set of self inflicted issues due in large part to Intel trying to make a wide variety of cross compatible parts, but IMO even if they’d got it right, it still would have died.
  - Joel_Mckay 2mo ago
    We agree it probably would have still failed, but mostly it was the legacy code-motion compatibility/performance issues that were practically inescapable without refactoring millions of lines of code. gcc maintained the ia64 target a long time for unclear reasons, but it was also still inefficient on other platforms. The FOSS compiler worked, but that was its only performance metric that counted for many users. =3 Not sure why you think the Intel compilers were a myth, as they are still around working far better than gcc in many use-cases: "An Overview of the Intel® IA-64 Compiler" https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/IntelIA64Compiler.pdf https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/In...
    - bri3d 2mo ago
      The myth I was referring to was the overarching theme that “VLIW would have been practical if only a better compiler existed,” which I don’t believe to be true for modern or Itanium-contemporary general purpose computing patterns.
- ColdStream 2mo ago
  Itanium is yet another example of how difficult it is to fight software ecosystem momentum. It had potential but until you have an easy transition path, few will consider it. Apple figured that out during the 68K > PPC > X86 > ARM transitions.
  - Joel_Mckay 2mo ago
    Agreed, everyone has a pet architecture that fascinates them, but if its so good only 5 people can code for the target... it is e-waste within a year. Apple is an exception as it has always had a walled-garden ecosystem with the OS, so can force shifts in architectures unlike most companies. The M3/M4 Pro series with unified GPUs is probably the best design on the consumer market right now, but people are not leveraging it as much as they would have in other ecosystems. Have a wonderful day =3
    - MBCook 2mo ago
      The walled garden is an advantage of some sort, but they’ve also never made a bad call on switching architectures. We don’t know what it would look like if Apple had chosen something that ended up like Itanium. It’s quite possible they don’t have the clout to pull it off. (Maybe they should have gone Intel instead of PPC, but both were significantly better than m68k at that point)
      - Joel_Mckay 2mo ago
        >We don’t know what it would look like if Apple had chosen something that ended up like Itanium Apple made a few mistakes, but mostly by trying to compete with doomed hype markets like AR/VR. Some also ponder what the ecosystem would look like today if the Windows NT kernel had stayed on RISC like initially planned. The "What if __ ?" universe are fun to imagine, but ultimately less important than the "What now?" universe we live in. =3
        MBCook 2mo ago
        Oh sure, Apple has TONS of mistakes if we look overall. I was only talking about CPU transitions.

by qubex 2mo ago

Joel_Mckay 2mo ago

To be fair, most of ia64 performance issues were in the more complicated compilers. The chip itself had potential, but essentially abandoned the DOS/Windows market inertia. =3

qubex 2mo ago
Yeah EPIC pushed too much effort onto compilers and removed the context awareness of out of order reordering etc and the result was just a lame duck.
- Joel_Mckay 2mo ago
  [flagged]
  - kstrauser 2mo ago
    You've mentioned Intel's compilers a few times but they're not a magic thing that could make Itanic not-suck. Suppose they make general purpose code that's twice as fast as GCC when the whole computer is dedicated to running one specific process. They don't, but let's pretend. Even in that ideal scenario, it falls apart as soon as you're processing unpredictable input. VLIW sucks hard at chewing through data that's not precisely what it's expecting. You could probably make a video codec that performed really well, but it would be impossible to make a database that performed consistently not-badly. It's not that the existing compilers weren't good enough, not even the magic Intel ones. It's that it's not possible to pre-generate VLIW opcodes that do well when the input value isn't a homogeneous stream. Even if Intel's code was 2x better than GCC's — and again, it wasn't — twice abominable was still abominable. I wasted more time SSHed into an Itanic than most people had to, so I'm speaking from first-hand experience. Some very, very specific Itanium code was a bit faster than the equivalent x86 or similar. That was always some very tightly scoped thing that did the exact same tight loop a gazillion times, like en-/decrypting a data stream. Anything more heterogenous ran poorly, as in multiple times the wall-clock time of the same workload on the x86 server next to it that cost a tenth as much. And that's even when using the magic Intel compilers. Itanium was bad. The compiler tech didn't exist to make it not-bad, and in retrospect I think it become obvious that it couldn't exist. It wasn't a matter of the compiler authors needing to be clever. It was more like making Itanium live up to the hype required making P=NP.
    - Joel_Mckay 2mo ago
      My point was most modern software developers still do not understand systems at an architectural level. I don't buy the VLIW paradigm was inherently inferior argument, but the code written for it with mystery failure modes at the time was a mess. And ia64 was only around 23% slower and several times more costly than amd64 options at the time. Both toads had their warts, but one was actually usable by mere mortals. Its true just about everything either ran slow on not at all on ia64... Thankfully, we were still running Sparc based platforms at that time, as the Intel clown-show still looked like more work. But I do empathize with the ia64 trauma, as the roll out had a lot of collateral damage in some firms as people started jumping ship early to avoid accountability. =3
      - qubex 2mo ago
        One immediate advantage that rescheduling-capable cores have that rigid compiler-based ones don’t nor ever would is that reschedules can notice patterns in execution in the current context and keep the ALU fed from well-provisioned caches even going as far as speculative execution. IA-64 and typeless or typed-at-runtime (JIT scripts, for example, like JavaScript or Python) would’ve been implemented very differently on Itanium.
  - abbeyj 2mo ago
    I think they meant EPIC https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing https://en.wikipedia.org/wiki/Explicitly_parallel_instructio..., not EPYC https://en.wikipedia.org/wiki/Epyc https://en.wikipedia.org/wiki/Epyc.
    - Joel_Mckay 2mo ago
      Indeed, my point was not all chips do well with Desktop application loads. People were bad at handling parallelism with ia64, and still have problems today on better amd platforms with less janky compilers. The fact an $800 chip still can beat a $14000 chip at some tasks probably should tell people something about concurrency scaling overhead. =3
      - qubex 2mo ago
        EPIC was Explicit Parallel Instruction Computing, the underlying engineering architecture of AI-64. Epyc is an AMD brand name. And pivoting to concurrency on a rescheduler-intensive core as opposed to concurrency on a scheduler-based core isn’t very pertinent, particularly since we have 25 years of Moore’s Law between then and now.
        Joel_Mckay 2mo ago
        "AI" responses are silly, and optimal 24 core count efficiency premise in Desktop applications offer diminishing returns on a highly concurrent 32/64/192 core Epyc line of OoO chips... How many strings does a Bass play with in water? =3
  - shrubble 2mo ago
    EPIC is Explicitly Parallel Instruction Computing; nothing to do with the AMD trademark word, EPYC.
    - Joel_Mckay 2mo ago
      Indeed, the post does not conflate the two... look closer. =3
bri3d 2mo ago
No (sorry, I post this every time the Mythical Compiler Myth reappears), the problem with VLIW is that it fundamentally doesn’t work for anything with unpredictable memory access patterns, and modern general purpose computing has moved almost exclusively in this direction. For VLIW to work, you need to either guess correctly what is in cache or not have a cache at all; as soon as you mispredict what has been loaded, you stall while an OoO processor keeps going and a speculative OoO processor even keeps guessing. With multiple workloads on the same hardware (virtualization, multitasking, multitenancy) this becomes an intractable problem even in the presence of the magic compiler which can solve for software based unpredictability (branch likelihood and pointer chasing), because every context switch clobbers an unknown set of cache lines and blows the entire thing up. VLIW works for single workloads. It works exceptionally well for single workloads with no or explicit cache like DSP. You can trade the footprint and complexity from OoO for a wider execution unit and more SRAM. It works well for HPC, too, for the same reason. But for anything where more than one process exists, it just really doesn’t work, and that’s most modern workload. Itanium also has a unique set of self inflicted issues due in large part to Intel trying to make a wide variety of cross compatible parts, but IMO even if they’d got it right, it still would have died.
- Joel_Mckay 2mo ago
  We agree it probably would have still failed, but mostly it was the legacy code-motion compatibility/performance issues that were practically inescapable without refactoring millions of lines of code. gcc maintained the ia64 target a long time for unclear reasons, but it was also still inefficient on other platforms. The FOSS compiler worked, but that was its only performance metric that counted for many users. =3 Not sure why you think the Intel compilers were a myth, as they are still around working far better than gcc in many use-cases: "An Overview of the Intel® IA-64 Compiler" https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/IntelIA64Compiler.pdf https://webdocs.cs.ualberta.ca/~amaral/courses/605/papers/In...
  - bri3d 2mo ago
    The myth I was referring to was the overarching theme that “VLIW would have been practical if only a better compiler existed,” which I don’t believe to be true for modern or Itanium-contemporary general purpose computing patterns.
ColdStream 2mo ago
Itanium is yet another example of how difficult it is to fight software ecosystem momentum. It had potential but until you have an easy transition path, few will consider it. Apple figured that out during the 68K > PPC > X86 > ARM transitions.
- Joel_Mckay 2mo ago
  Agreed, everyone has a pet architecture that fascinates them, but if its so good only 5 people can code for the target... it is e-waste within a year. Apple is an exception as it has always had a walled-garden ecosystem with the OS, so can force shifts in architectures unlike most companies. The M3/M4 Pro series with unified GPUs is probably the best design on the consumer market right now, but people are not leveraging it as much as they would have in other ecosystems. Have a wonderful day =3
  - MBCook 2mo ago
    The walled garden is an advantage of some sort, but they’ve also never made a bad call on switching architectures. We don’t know what it would look like if Apple had chosen something that ended up like Itanium. It’s quite possible they don’t have the clout to pull it off. (Maybe they should have gone Intel instead of PPC, but both were significantly better than m68k at that point)
    - Joel_Mckay 2mo ago
      >We don’t know what it would look like if Apple had chosen something that ended up like Itanium Apple made a few mistakes, but mostly by trying to compete with doomed hype markets like AR/VR. Some also ponder what the ecosystem would look like today if the Windows NT kernel had stayed on RISC like initially planned. The "What if __ ?" universe are fun to imagine, but ultimately less important than the "What now?" universe we live in. =3
      - MBCook 2mo ago
        Oh sure, Apple has TONS of mistakes if we look overall. I was only talking about CPU transitions.