Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel releases the last Itanium chip, the 9700

pcworld.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Intel releases the last Itanium chip, the 9700

#61

Post by bonzini »

trsohmers wrote: post #42
CyberDildonics wrote: post #34

Earlier quoted context omitted.

One reason is that the idea behind 'just need a smart compiler' was doomed from the start. If you build something that won't shine unless everyone that builds a compiler for it makes sure to extract plenty of instruction level parallelism, it is doomed to fail. Maybe these days with LLVM it could have been a little more practical, but Intel has dominated largely by making sure poorly written programs run as fast as p…

LLVM is the godsend that any new architecture (especially a VLIW) to compete with Intel needed. I'm the founder of a startup that has made a new VLIW processor with our toolchain built on top of LLVM... We get the front end and all of the languages it supports virtually for free (we've only had to make small tweaks to clang), and get to focus our effort on just the parts important to us, our actual target backend and…

I'm not sure why GCC would have been anything different.

No, porting GCC to a new architecture is not a big deal. The really complex part is the ABI, and what I have heard from former GCC developers is that it's as much of a mess in LLVM, because it's simply a messy domain.

Re: Intel releases the last Itanium chip, the 9700

#62

Post by thesz »

deepnotderp wrote: post #7
KenoFischer wrote: post #5

Earlier quoted context omitted.

> 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…

This, recent compiler advances in the past two decades have actually made VLIW somewhat tractable, but since the memory hierarchy and data movement wall consumes most of the power nowadays, the benefits of VLIW are mitigated.

Make VLIW running at 0MHz.

First, your silicon will be smaller - no need for pipelines, even double precision floating point multiply can be done in one clock cycle. Less registers, less silicon area. You can internally do that operation at higher frequencies than main core, timesharing die area for SIMD operations - saving silicon in other way.

Second, your compiler will be simpler - no need for NP-hard algorithms to schedule operations in the basic block, no need for fancy software pipelining for loop code to be warmed up and/or cooled down.

Third, your CPU won't be faster than memory. Your code won't get big hit from missed cache access. And cache will be used to save energy, not the time.

That's exactly the reasons behind one of exascale CPU architectures. It was long ago - circa 2012. I remember they managed to get FLOP/W ratios much higher than Intel's offering at the time.

Re: Intel releases the last Itanium chip, the 9700

#63

Post by gsg »

thesz wrote: post #57
DannyBee wrote: post #16

Earlier quoted context omitted.

"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…

As a developer of out-of-order CPU (model, but studied the effects on real code and did my best to make it synthesable) I can assure you there's a lot of ILP to extract even from ordinary programs. The problem with Itanium is that it wasn't OoO and can't be made such. Just to give you a hint - just computing various kinds of addresses in advance can make huge difference. Compute branch address, issue a fetch, compute…

Itanium did have features for various kinds of speculation, though. You could load from an address even if it were potentially aliased with a subsequent store, with the processor doing a dynamic check to make sure the right value was observed (eg, performing a late load and blocking if it turned out there was an overlapping store).

It wasn't as effective as OoO in the end, but not for lack of attention to the problem.

Re: Intel releases the last Itanium chip, the 9700

#64

Post by trsohmers »

bonzini wrote: post #61
trsohmers wrote: post #42

Earlier quoted context omitted.

LLVM is the godsend that any new architecture (especially a VLIW) to compete with Intel needed. I'm the founder of a startup that has made a new VLIW processor with our toolchain built on top of LLVM... We get the front end and all of the languages it supports virtually for free (we've only had to make small tweaks to clang), and get to focus our effort on just the parts important to us, our actual target backend and…

I'm not sure why GCC would have been anything different. No, porting GCC to a new architecture is not a big deal. The really complex part is the ABI, and what I have heard from former GCC developers is that it's as much of a mess in LLVM, because it's simply a messy domain.

LLVM is much more compartimentalized, so we can make changes to the backend without touching/breaking other parts. The GCC loader was miles ahead of the LLVM loader up until the past few releases, and we were originally using a modified version of the GCC loader before switching.

LLVM also has a bunch of awesome projects like Poly for polyhedral compilation that we are able to use that don't exist at all for GCC, or are very difficult to integrate. LLVMs lego block like architecture (it was originally designed as a tool to help build toolchains) plus things like Tablegen enabled our single "real" software engineer/CTO to do initial bring up of a backend in under a month.

Re: Intel releases the last Itanium chip, the 9700

#65

Post by deepnotderp »

acdha wrote: post #60
deepnotderp wrote: post #54

Earlier quoted context omitted.

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…

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 opti…

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.

Re: Intel releases the last Itanium chip, the 9700

#66

Post by deepnotderp »

acdha wrote: post #30
deepnotderp wrote: post #11

Earlier quoted context omitted.

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 th…

Modern "CISC" architectures are actually RISC with a conversion layer stapled in front of it, that's not very convincing...

Also, many VLIW purists will claim (with some veracity also) that Itanium's EPIC != VLIW

Re: Intel releases the last Itanium chip, the 9700

#67

Post by RcouF1uZ4gsC »

ChuckMcM wrote: post #50

As an interesting data point, (and the article doesn't do it justice), when I saw the presentation on AMD's "Sledgehammer" architecture (the AMD64) at Microprocessor Forum I wrote to the CTO of NetApp at the time "If you're wondering, Itanium just died." And then more than 16 years later it actually is going to cease development. It also started a multi-year effort to convince NetApp to use an AMD chip in their filer…

I agree with your assessment. It seemed Intel tried to use the 32-bit limit of x86 to drive the high end computing to Itanium. AMD did x86-64 and removed that limit, and Intel was forced to play along and x86 escaped from its artificial limits and removed much of the justification for Itanium.

Re: Intel releases the last Itanium chip, the 9700

#68

Post by ehvatum »

drewg123 wrote: post #48
bluejekyll wrote: post #10

Earlier quoted context omitted.

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…

If amd64 had not been released, I think itanium would probably own the server market. But it would be a very different server market .. much more like the late 90s market than today's market. Remember that Intel was twisting arms and making deals to kill the weaker RISC chips in the marketplace. In the leadup to the first Itanium, HP had acquired Compaq (which had acquired DEC), so they held both Alpha and PA-RISC. A…

Hey, thanks for your work on the FreeBSD alpha port! We got a lot of mileage out of it, while pointing and laughing at Itanium the whole time :)

Re: Intel releases the last Itanium chip, the 9700

#69

Post by gumby »

trsohmers wrote: post #42
CyberDildonics wrote: post #34

Earlier quoted context omitted.

One reason is that the idea behind 'just need a smart compiler' was doomed from the start. If you build something that won't shine unless everyone that builds a compiler for it makes sure to extract plenty of instruction level parallelism, it is doomed to fail. Maybe these days with LLVM it could have been a little more practical, but Intel has dominated largely by making sure poorly written programs run as fast as p…

LLVM is the godsend that any new architecture (especially a VLIW) to compete with Intel needed. I'm the founder of a startup that has made a new VLIW processor with our toolchain built on top of LLVM... We get the front end and all of the languages it supports virtually for free (we've only had to make small tweaks to clang), and get to focus our effort on just the parts important to us, our actual target backend and…

Was this not true of GCC as well?

Re: Intel releases the last Itanium chip, the 9700

#70

Post by flamedoge »

trsohmers wrote: post #35
CalChris wrote: post #18

Earlier quoted context omitted.

Trace scheduling started with Fisher 81 [1] and Ellis 85 [2]. Trace scheduling is what made VLIW even possible if not exactly tractable. That was 30+ years ago. What recent advances have made VLIW any more tractable than trace scheduling already did? BTW, trace scheduling works for scheduling superscalar processors as well. VLIW never went away. It's used in embedded, the TriMedia processors. It's used in the REX Com…

Designer of the Neo here, and owner of the California "VLIW" license plate. As you can guess, I am a die hard VLIW advocate, and a strong believer that the original promises of VLIW (Drastically simpler decode logic, implicit instruction level parallelism, virtually no control/data hazards on chip). VLIW has gotten an extremely bad rap outside of the embedded space due to Itanium, which I strongly contend was not a V…

How far away are you from getting to the point where you can accelerate workloads such as blender? Also I see that your backend isn't in the trunk -- is there plan to push to upstream and share the details? I'd love to learn about your isa.
Post reply on HN