4 ms·

Last sentence of the article has the phrase "sufficiently intelligent compilers". :) Intentional in-joke? Wikipedia's definition: "Sufficiently Smart Compiler,

Last sentence of the article has the phrase "sufficiently intelligent compilers". :) Intentional in-joke? Wikipedia's definition: "Sufficiently Smart Compiler, any of a family of theoretically possible compilers able to perform sophisticated but unrealistic code optimizations" > Given sufficiently intelligent compilers, Itanium could begin to make economic sense in fields that couldn't previously justify the high cost of optimizing for the chip. https://duckduckgo.com/?q=%22sufficiently+smart+compiler%22 https://duckduckgo.com/?q=%22sufficiently+smart+compiler%22

kd0amg 16y ago
I would probably read it differently depending on the background of the person who wrote it (mostly based on how aware I'd expect the writer to be of the problems involved). I've seen people with a basic understanding of compilers stumble over it and not know why others in the room chuckled. In this particular case, I don't know enough about the author to say, but EPIC/VLIW architectures are kind of known for making things difficult for the compiler (meaning the joke would be very appropriate here).
- jacques_chester 16y ago
  The entire bet for EPIC was that a sufficiently smart compiler would mean you could free up die space for processing transistors by ditching branch detection, prefetch logic, speculative execution, caches etc. As you point out, the SSC has yet to appear. Just look at that layout: it's dominated by cache.
  - scott_s 16y ago
    I think even in the ideal SSC case, you'd still want as much cache as you can get. Even if the compiler can insert perfect prefetching instructions, the prefetched data has to go somewhere. And the more somewhere you have, the more aggressively you can prefetch. I think the main benefit would be much simpler instruction pipelines, which would include the points you mentioned (branch prediction, prefetch) but also all of the logic needed to keep track of dependencies in an out-of-order processor.
    - jacques_chester 16y ago
      Absolutely. I studied the Itanium design philosophy back in 2000 and this is exactly what they were aiming to do: drop all the complex logic devoted to keeping the pipelines full and all the units busy. True about data, though I vaguely recall EPIC had advantages there too because without needing to do branch prediction, you didn't need to speculatively fetch multiple memory addresses; meaning the same D-cache went further.

kd0amg 16y ago

I would probably read it differently depending on the background of the person who wrote it (mostly based on how aware I'd expect the writer to be of the problems involved). I've seen people with a basic understanding of compilers stumble over it and not know why others in the room chuckled. In this particular case, I don't know enough about the author to say, but EPIC/VLIW architectures are kind of known for making things difficult for the compiler (meaning the joke would be very appropriate here).

jacques_chester 16y ago
The entire bet for EPIC was that a sufficiently smart compiler would mean you could free up die space for processing transistors by ditching branch detection, prefetch logic, speculative execution, caches etc. As you point out, the SSC has yet to appear. Just look at that layout: it's dominated by cache.
- scott_s 16y ago
  I think even in the ideal SSC case, you'd still want as much cache as you can get. Even if the compiler can insert perfect prefetching instructions, the prefetched data has to go somewhere. And the more somewhere you have, the more aggressively you can prefetch. I think the main benefit would be much simpler instruction pipelines, which would include the points you mentioned (branch prediction, prefetch) but also all of the logic needed to keep track of dependencies in an out-of-order processor.
  - jacques_chester 16y ago
    Absolutely. I studied the Itanium design philosophy back in 2000 and this is exactly what they were aiming to do: drop all the complex logic devoted to keeping the pipelines full and all the units busy. True about data, though I vaguely recall EPIC had advantages there too because without needing to do branch prediction, you didn't need to speculatively fetch multiple memory addresses; meaning the same D-cache went further.