51–60 of 83 posts
EDIT: It looks like it might be this one: https://github.com/syunnPC/qemu-system-ia64
Earlier quoted context omitted.
[flagged]
I think they meant EPIC https://en.wikipedia.org/wiki/Explicitly_parallel_instructio... , not EPYC https://en.wikipedia.org/wiki/Epyc .
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
Earlier quoted context omitted.
Right. PPC was significantly faster than m68k. Intel was significantly faster again. Finally ARM was yet again. (ARM and Intel especially on laptops) They could pay the emulation price and still come out equal or usually on top. Even when equal there were often other benefits, like reduced heat. As I remember hearing Itanium was a dog with x86 code. It never got fast enough to compete let alone supplant it during emu…
IIRC Itanium was faster on natively compiled HPC code, presumably because it had more FPUs and larger cache than the Pentium 4. But in general it probably wasn't a good upgrade and Intel would have had to sandbag x86 a lot to force Itanium adoption.
Earlier quoted context omitted.
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,…
Itanium had all sorts of specialized machinery so that you could issue a load that's required in the future, and then keep chugging away at the instruction stream, similar to what an OoO processor does with it's reordering logic. One example was "advanced loads" which allowed you to issue a load as soon as you knew the address, even in the face of potential pointer aliasing in the future, and then later complete the…
Earlier quoted context omitted.
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,…
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 No…
When it comes to Itanium all I can think of is how I wish I could have an Alpha. And how no one should care about Itanium. It’s the product of companies bent on doing all the wrong things.
Earlier quoted context omitted.
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 leverag…
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)
It seems more like they have a high willingness to switch architectures.
Predicting which one is better in the year that you do it or the couple of years after isn't that hard. The question is, where is it going to be in a decade or two?
Each time they picked a huge company you wouldn't have expected to fail in that year, first IBM, then Intel. But that's the problem with huge companies, after a few years on top they tend to get complacent and stagnate.
Now Apple itself is the big company, but it remains to be seen if they're not still going to end up on e.g. RISC-V within the next ten years or so.
Earlier quoted context omitted.
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 No…
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.
Very few modern languages handle parallel scaling gracefully, and bodged on CUDA still isn't great either. As Moore's law ends, people have to reevaluate how they approach traditionally monolithic architectural design. =3
Earlier quoted context omitted.
Itanium had all sorts of specialized machinery so that you could issue a load that's required in the future, and then keep chugging away at the instruction stream, similar to what an OoO processor does with it's reordering logic. One example was "advanced loads" which allowed you to issue a load as soon as you knew the address, even in the face of potential pointer aliasing in the future, and then later complete the…
These worked well for “known” intra-task pointer aliasing situations, but if you don’t know what will be in cache due to preemption of any kind, you still don’t know how many cycles the speculative loads will take, so you get the same stall risks across a dependency hazard.