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

51–60 of 98 posts

Re: Intel releases the last Itanium chip, the 9700

#51

Post by acdha »

bluejekyll wrote: post #10
tyingq wrote: post #4

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

It's also interesting to think about what would have happened if Rick Belluzzo hadn't been in the right place to convince both HP (as a VP) and then SGI (as CEO) to make large bets on Itanium and Windows. I don't think the market would have supported that many more expensive CPUs – fab economics are brutal – but two of the major players giving control over key parts of their design to Intel & Microsoft significantly accelerated that trend.

SGI is interesting because they _owned_ the 3D space and shortly before he went to Microsoft, SGI gave nVidia and Microsoft very cheap licenses to their extensive collection of patents and other IP. It's interesting to imagine what might have happened if, say, SGI had switched to Intel but with fewer gambles on unproven technology: x86 and Linux or the internal IRIX x86 port instead of Itanium and the heavily modified Windows NT derivative which was very expensive to support and forced all of their developers to make massive code changes. Similarly, they were focused on the high-end 3-D market (engineering, science, animation, etc.) and dismissed the PC gaming business as insignificant and basically gave it to nVidia along with a bunch of their staff; had someone a little short-sighted been involved that would have made a big difference in their bottom line.

Re: Intel releases the last Itanium chip, the 9700

#52

Post by CalChris »

chrisseaton wrote: post #44
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…

Is it the case that you can implement just a new backend and produce good machine code for your processor, or really do you need to modify the frontend to get it to generate code IR from which you can generate good machine code, because otherwise useful information has been lost by time you get the IR from the frontend?

It's really three stages, not frontend and backend.

The first stage is the LLVM front end, Clang and other language parsers. They generate IR.

The middle stage is the LLVM optimizer, opt, which takes IR and runs a variety of optimization passes. Opt takes and gives IR.

http://llvm.org/docs/Passes.html

The third is the backend code generator. It lowers IR to the target ISA. There's a tablegen description, there's are MI scheduler models which abstract architectural information as well.

http://llvm.org/docs/WritingAnLLVMBackend.html

I think you really meant can you write an optimizing pass specifically for your target? Yes. But I don't think that modifying the real front end Clang is going to get you much of anything. Intrinsics are different; that's the programmer inserting ISA specific instructions rather than Clang extracting ISA specific information. Really, modifying Clang isn't going to get you anything.

Thomas, what were the 'small' Clang specific tweaks?

Re: Intel releases the last Itanium chip, the 9700

#54

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…

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.

Re: Intel releases the last Itanium chip, the 9700

#56

Post by CalChris »

deepnotderp wrote: post #54
acdha wrote: post #30

Earlier quoted context omitted.

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…

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…

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.

Re: Intel releases the last Itanium chip, the 9700

#57

Post by thesz »

DannyBee wrote: post #16
userbinator wrote: post #2

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

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 load address, issue a fetch (even when destination register is blocked). Voila! Your program is sped up significantly.

Re: Intel releases the last Itanium chip, the 9700

#58

Post by thesz »

chrisseaton wrote: post #33
DannyBee wrote: post #31

Earlier quoted context omitted.

They can extract some ILP, but most of that is because it has no limitations but the semantics of the instruction set. It also cheats and can speculate just about everything legally, because it can always undo it. A large amount of the ILP is, AFAIK, from being able to prefetch accurately (IE guess what memory will be accessed) and guess branch directions correctly. This is not possible to do as well statically. You…

Maybe it's like JITs vs static compilers - we're better off with JIT even if your language is static, because you can adapt to real runtime conditions.

JITs do not and cannot have a complete program view.

Whole program compiler can insert JIT-calling code (specializing for common pattern), JIT compiler cannot view whole program.

One of the things JITs can't do is to add and/or remove parallelism from the program (i.e., add/remove OpenMP pragmas).

Re: Intel releases the last Itanium chip, the 9700

#59

Post by bonzini »

CyberDildonics wrote: post #36
chrisseaton wrote: post #33

Earlier quoted context omitted.

Maybe it's like JITs vs static compilers - we're better off with JIT even if your language is static, because you can adapt to real runtime conditions.

But we aren't better off with JIT in software. x64 processors work because they are doing things dynamically in separate hardware. It is part of how they use ever increasing transistor budgets to speed up serial processing.

Really, at this point the transistor budget is mostly going to bigger caches and more cores.

It's really little short of a miracle that Intel still managed to extract double digit percent improvements in serial code for all of Sandy Bridge, Haswell and Skylake.

Re: Intel releases the last Itanium chip, the 9700

#60

Post by acdha »

deepnotderp wrote: post #54
acdha wrote: post #30

Earlier quoted context omitted.

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…

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 optimization and tooling, and they don't need to run arbitrary legacy business apps.

Post reply on HN