3 ms·

I disagree; Itanium was fundamentally flawed for general purpose computing and especially time-shared generally purpose computing. VLIW is not practical in time

by bri3d 1y ago

I disagree; Itanium was fundamentally flawed for general purpose computing and especially time-shared generally purpose computing. VLIW is not practical in time-sharing systems without completely rethinking the way cache works, and Itanium didn't really do that. As soon as a system has variable instruction latency, VLIW completely stops working; the entire concept is predicated on the compiler knowing how many cycles each instruction will take to retire ahead of time. With memory access hierarchy and a nondeterministic workload, the system inherently cannot know how many cycles an instruction will take to retire because it doesn't know what tier of memory its data dependencies live in up front. The advantage of out-of-order execution is that it dynamically adapts to data availability. This is also why VLIW works well where data availability is _not_ dynamic, for example in DSP applications. As for this Electron thing, the linked article is too puffed to tell what it's actually doing. The first paragraph says something about "no caches" but the block diagram has a bunch of caches in it. It sort of sounds like an FPGA with bigger primitives (configurable instruction tiles rather than gates), which means that synchronization is going to continue to be the problem and I don't know how they'll solve for variable latency.

als0 1y ago
> VLIW is not practical in time-sharing systems without completely rethinking the way cache works Just curious as to how you would rethink the design of caches to solve this problem. Would you need a dedicated cache per execution context?
- bri3d 1y ago
  That's the simplest and most obvious way I can think of. I know the Mill folks were deeply into this space and probably invented something more clever but I haven't kept up with their research in many years.
hawflakes 1y ago
Not to detract form your point, but Itanium's design was to address the code compatibility between generations. You could have code optimized for a wider chip run on a narrower chip because of the stop bits. The compiler still needs to know how to schedule to optimize for a specific microarchitecture but the code would still run albeit not as efficiently. As an aside, I never looked into the perf numbers but having adjustable register windows while cool probably made for terrible context switching and/or spilling performance.

by bri3d 1y ago

als0 1y ago

> VLIW is not practical in time-sharing systems without completely rethinking the way cache works Just curious as to how you would rethink the design of caches to solve this problem. Would you need a dedicated cache per execution context?

bri3d 1y ago
That's the simplest and most obvious way I can think of. I know the Mill folks were deeply into this space and probably invented something more clever but I haven't kept up with their research in many years.

hawflakes 1y ago

Not to detract form your point, but Itanium's design was to address the code compatibility between generations. You could have code optimized for a wider chip run on a narrower chip because of the stop bits. The compiler still needs to know how to schedule to optimize for a specific microarchitecture but the code would still run albeit not as efficiently. As an aside, I never looked into the perf numbers but having adjustable register windows while cool probably made for terrible context switching and/or spilling performance.