4 ms·

The last part I actually agree with, at the time Itanium was made, there was a sense of "It's the next big thing (tm)". And I don't actually disagree that VLIW

The last part I actually agree with, at the time Itanium was made, there was a sense of "It's the next big thing (tm)". And I don't actually disagree that VLIW is best suited for some specific workloads as opposed to general workloads. All I'm saying is that those workloads, such as decoding, video and a few others, are becoming more important as the consumer smartphone workload and that most smartphone CPUs can't do much more than 3 instructions in parallel anyways, which is close to the generally agreed 2-3 ilp that VLIW compiler can extract. Power consumption is heavily restricted on a smartphone as well. That being said, data movement is the big issue nowadays, so I'm not sure how much that will help.

CalChris 9y ago
A smartphone like the iPhone 7 doesn't use its A10 Hurricane Arm to decode audio or video. There's a 6-core GPU for that. This then skews the Arm's workload to be even more general purpose.
acdha 9y ago
I agree that those workloads are becoming more important but as CalChris noted there's a narrow range where that's both a significant workload and not offloaded entirely to purpose-built silicon. I would be interested in learning more about the reasoning which caused AMD to move away from VLIW in their GPU designs since that seems like a relatively favorable area: very performance sensitive, people put time into optimization and tooling, and they don't need to run arbitrary legacy business apps.
- deepnotderp 9y ago
  No, for GPUs it would be stupid to go VLIW only, SIMD is a much better approach and VLIW-SIMD is even better. The last one is actually the approach taken by some of the newer GPU-esque architectures like movidius (although I take serious issue to almost everything else about their architecture). By the ways, the NOP padding argument never convinced me because you can just use variable length instructions, and even current x86 decoders are variable length.

CalChris 9y ago

A smartphone like the iPhone 7 doesn't use its A10 Hurricane Arm to decode audio or video. There's a 6-core GPU for that. This then skews the Arm's workload to be even more general purpose.

acdha 9y ago

I agree that those workloads are becoming more important but as CalChris noted there's a narrow range where that's both a significant workload and not offloaded entirely to purpose-built silicon. I would be interested in learning more about the reasoning which caused AMD to move away from VLIW in their GPU designs since that seems like a relatively favorable area: very performance sensitive, people put time into optimization and tooling, and they don't need to run arbitrary legacy business apps.

deepnotderp 9y ago
No, for GPUs it would be stupid to go VLIW only, SIMD is a much better approach and VLIW-SIMD is even better. The last one is actually the approach taken by some of the newer GPU-esque architectures like movidius (although I take serious issue to almost everything else about their architecture). By the ways, the NOP padding argument never convinced me because you can just use variable length instructions, and even current x86 decoders are variable length.