32nm chip in 2017, probably to reduce costs.
Intel releases the last Itanium chip, the 9700
21–30 of 98 posts
Re: Intel releases the last Itanium chip, the 9700
#22We would probably all be working with Itanium servers if not for AMD introducing 64 bit x86. I believe that also accelerated Linux adoption and the decline of all the commercial Unix platforms. Good to see AMD on the rise again. I appreciate their role in heading off Itanium.
Had x86_64 not been released, I also think we'd see a more diverse set of serverside chips as well, such as SPARC and POWER. There wouldn't have been an obvious dominance in the marketplace of a single architecture. Also, had it not been released, we'd probably have seen a larger fracturing of the laptop CPU market with a broader switch to ARM64. In a sense, because AMD forced Intel's hand in supporting x86_64, they…
I dunno. The cost advantage of x86-64 plus Linux and Windows was a tough nut for other RISC vendors to beat. Price/Performance, plus general support. For example, x86-64 servers could get away without SSL acceleration because the handshake was done in optimized ASM for most web servers. For other architectures, it wasn't.
Re: Intel releases the last Itanium chip, the 9700
#23The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be…
"The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. " Well no, it would be more accurate to say "a noteworthy example of when you release a chip that isn't in line with what common programming languages can do". That is, there is nothing wrong with doing the above. There's…
But conventional Intel processors do manage to dynamically extract quite a good deal of ILP don't they? That's been the source of most of our performance increases over the last decade I think. Why does it work dynamically but not statically?
Re: Intel releases the last Itanium chip, the 9700
#24From the article:
>"Intel can now focus on Xeon, which was rebranded last week to account for new technologies like co-processors and faster interconnects."
I was confused by this, Xeon has been the mainstay in the high-end workstation/server for what feels like forever now. Was the limited Itanium market and development really affecting their focus that much?
I am curious if anyone knows what companies or verticals made big investments in Itanium? I imagining Intel much have some pretty big Itanium customers if it has been around this long. Maybe this answers my first question?
Re: Intel releases the last Itanium chip, the 9700
#25The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be…
> I suppose a similar analogy would be doing everything in x86 with SIMD instructions and not using the scalar set at all. With ever wider SIMD units this is actually happening to some extent. With AVX512 (e.g. on KNL) you can do 64 operations (single precision FLOPs) in vector units in the same amount of time as you can do 1 scalar operation. Combined with the low clock speed of the KNL, you really don't want to be…
With ever wider SIMD units this is actually happening to some extent. With AVX512 (e.g. on KNL) you can do 64 operations (single precision FLOPs) in vector units in the same amount of time as you can do 1 scalar operation
I was talking about code which simply can't be parallelised because it is branchy or has long and unavoidable dependency chains. In those cases using SIMD instructions will only make the code larger (thus more cache-consuming) and arguably more power-consuming too, since 63/64 of those operations aren't contributing anything to the computation.
Re: Intel releases the last Itanium chip, the 9700
#26We would probably all be working with Itanium servers if not for AMD introducing 64 bit x86. I believe that also accelerated Linux adoption and the decline of all the commercial Unix platforms. Good to see AMD on the rise again. I appreciate their role in heading off Itanium.
If I had to bet on the reason of Itanium failure, I would also choose AMD64. But not because it was cheap, but because it had x86 in the name. For some reason whenever Intel tried to abandon x86, they failed, like Itanium, i960, XScale.
Perhaps. At least where I was, though, it was the cost factor. We liked Solaris better than Linux. But big Solaris Sparc servers (and every other RISC server too) were 6 figure purchases, with accompanying big support contracts. A high end 4 way x86-64 box was much lower initial cost, and much lower recurring cost. They did start lowering prices when they saw the shift, but too little, too late.
Re: Intel releases the last Itanium chip, the 9700
#27The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be…
Your sequential CPUs are also exploiting parallelism to go faster, OoO execution, VLIW just wanted to do that in the compiler. There was nothing inherently wrong with the idea, the folly of Itanium was not the focus on parallelism, it was that compiler technology was not sufficiently advanced.
The overhead of padding 2/3 possible instructions with NOPs doesn't happen with "sequential CPUs". They extract parallelism only when and if it occurs.
Even the most "sufficiently advanced" compiler can't parallelise everything.
Re: Intel releases the last Itanium chip, the 9700
#28The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be…
leaves all instruction scheduling to the compiler
In-order processors also leave instruction scheduling to the compiler. They're very common. The workhorse ARM Cortex-A7 is in-order, dual issue and pipelined.
Re: Intel releases the last Itanium chip, the 9700
#29Related: excellent article on IA64/x64 etc:
https://github.com/tpn/pdfs/blob/master/A%20History%20of%20M...
Features quotes from various interviews with folks like David Cutler. Fascinating (and not surprising) to connect the dots between the NT x64 calling conventions + SEH + RIP-relative addressing and Dave Cutler's initial input.
Regarding the Itanium itself, I've always found this excerpt quite interesting:
"Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average systemwide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis."
(Page 6 of cited PDF.)
Re: Intel releases the last Itanium chip, the 9700
#30The Itanium is a noteworthy example of what happens when one designs an architecture exclusively for parallelism to the exclusion of all else, and leaves all instruction scheduling to the compiler. The performance was great when software could take advantage of the parallelism, but horrible otherwise, since the processor would still be fetching bundles of 3 instructions (16 bytes each!) but only 1/3 of them would be…
Your sequential CPUs are also exploiting parallelism to go faster, OoO execution, VLIW just wanted to do that in the compiler. There was nothing inherently wrong with the idea, the folly of Itanium was not the focus on parallelism, it was that compiler technology was not sufficiently advanced.
I think there's a strong argument that it wasn't just that the compiler technology was insufficiently god-like but also that they over-estimated the degree to which instruction-level parallelism mattered to the general market. The quote below really fits my memory of the initial experience — the claims were really ambitious but even if it'd on-time (i.e. 2+ years earlier) and at the originally promised clock rates the results wouldn't have been especially impressive outside of a few fields like scientific computing. Even in HPC it was a question of how much time you were willing to spend hand-tuning every hot section. When it finally did ship, we got access to a dev system and found the Itanium systems generally struggled to surpass the previous generation systems which we were preparing to replace.
“Davidson also pointed out two areas where academic research could create a blind spot for architecture developers. First, most contemporary academic research ignored CISC architectures, in part due to the appeal of RISC as an architecture that could be taught in a semester-long course. Since graduate students feed the research pipeline, their initial areas of learning frequently define the future research agenda, which remained focused on RISC. Second, VLIW research tended to be driven by instruction traces generated from scientific or numerical applications. These traces are different in two key ways from the average system-wide non-scientific trace: the numerical traces often have more consistent sequential memory access patterns, and the numerical traces often reflect a greater degree of instruction-level parallelism (ILP). Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue VLIW was driven by the prejudices of a few researchers, rather than by sound technical analysis.”
The rest of this PDF is well worth reading:
http://courses.cs.washington.edu/courses/csep590/06au/projec...