EPIC failure (to cancel the project when it was first failing)

Posted Nov 17, 2023 14:57 UTC (Fri) by foom (subscriber, #14868)
In reply to: EPIC failure (to cancel the project when it was first failing) by anton
Parent article: The push to save Itanium

When I first read about itanium, I thought that surely Intel must be targeting it to JIT-compiled languages, and just didn't care that much about ahead-of-time compiled languages. (Java is the future, right?)

Because, in the context of a JIT, many of the impossible static scheduling problems of the in order EPIC architecture seem to go away.

You can have the CPU _measure_ the latencies, stalls, dependencies, etc, and then have software just reorder the function so the next executions are more optimally arranged to take advantage of that observed behavior. You should be able to make more complex and flexible decisions in your software JIT than e.g. a hardware branch predictor can do, while still being able to react to changing dynamic execution conditions unlike AOT compiled code.

But, I guess Transmeta thought so too; their architecture was to have a software JIT compiler translating from X86 to a private internal EPIC ISA. And that didn't really work either...

EPIC failure (to cancel the project when it was first failing)

Posted Nov 17, 2023 15:44 UTC (Fri) by paulj (subscriber, #341) [Link]

If hardware can apply an optimisation, a software JIT should be able to as well. The question must then be:

- Can the transistors (and pipeline depth) saved in hardware then be used to gain performance?

Transmeta did well on power, but was not fast. Which suggests the primary benefit is an increase in performance/watt from the transistor savings - not outright performance. Either that, or Transmeta simply didn't have the resources (design time, expertise) to use the extra transistor budget / simpler pipeline to improve outright performance.