News for hackers. Stuff that matters.

A comment on Intel releases the last Itanium chip, the 9700. Parent comment

Re:Intel releases the last Itanium chip, the 9700 by deepnotderp on Saturday May 13, 2017 @01:37PM (#14332044)
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.

[ Parent | on HN ]
Re:Intel releases the last Itanium chip, the 9700 by CalChris on Saturday May 13, 2017 @02:00PM (#14332133)
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.
[ Parent | on HN ]
Re:Intel releases the last Itanium chip, the 9700 by acdha on Saturday May 13, 2017 @02:22PM (#14332243)
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.

[ Parent | on HN ]
Re:Intel releases the last Itanium chip, the 9700 by deepnotderp on Saturday May 13, 2017 @03:05PM (#14332452)
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.

[ Parent | on HN ]