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

41–50 of 98 posts

Re: Intel releases the last Itanium chip, the 9700

#41

Post by poopsicle »

DannyBee wrote: post #31
chrisseaton wrote: post #23

Earlier quoted context omitted.

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?

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…

It sounds like you just proved the point.

Re: Intel releases the last Itanium chip, the 9700

#42

Post by trsohmers »

CyberDildonics wrote: post #34
chrisseaton wrote: post #23

Earlier quoted context omitted.

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?

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 the unique optimization steps. Right now we can take any code that compiles through LLVM and run it on a single one of our cores while finding a good chunk of ILP (we are quad issue, averaging close to 2.5 IPC, sometimes higher), and be beating out the performance of some ARM and DSP cores that are 10x the size. Multi core parallelism requires including our hand tuned libraries, but our true MIMD style of task and data level parallelism is a lot more flexible than SIMD/SIMT/SMP that you are stuck with on existing chips.

Re: Intel releases the last Itanium chip, the 9700

#43

Post by CyberDildonics »

KenoFischer wrote: post #39
CyberDildonics wrote: post #37

Earlier quoted context omitted.

Actually it is 16 floating point operations in one AVX512 instruction and each core has two units, making 32 flops if you are running two or more threads (each core can do 4 way SMT but can also only decode two instructions per cycle).

I was counting FMA as 2 operations ;).

That's Intel marketing and is somewhere between deceptive and wrong. Intel uses that to claim inflated maximum flops, with the huge aside that you would have to be doing nothing but fused multiply add, which is absurd.

Re: Intel releases the last Itanium chip, the 9700

#44

Post by chrisseaton »

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…

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?

Re: Intel releases the last Itanium chip, the 9700

#45

Post by trsohmers »

CyberDildonics wrote: post #40
trsohmers wrote: post #35

Earlier quoted context omitted.

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…

What are some examples of VLIW succeeding? (I haven't watched your video yet)

The two best application cases of instruction level parallelism that we have at the moment are our FFT and DGEMM, where our 64 bit instruction word contains the operations for doing a double precision fused multiply add, two 128 bit load/stores, and an ALU op for address calculation. The inner loops of these programs are able to get up to 4 instructions per cycle (5 if you count the FMA as 2 ops, which is what everyone else does but I think is cheating), and compared to a superscalar architecture, uses very little space in local memory (fitting 4 operations in only 64 bits is awesome!). Compared to the latest 14/16nm offerings from Intel and NVIDIA, we have a 25x energy efficiency advantage for our FFT while our test chip is still on 28nm.

These are the same reasons why DSPs have been VLIW since the 90s, and our initial applications overlap a lot. It has been sad to see the trend of TI and other DSP makers going down the path of adding hardware caching (that reduces determinism and energy efficiency) to try to "make it easier for programmers" when they already have a decent enough architecture, but a lack of good compiler tools to take advantage of it.

Re: Intel releases the last Itanium chip, the 9700

#46

Post by CalChris »

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…

Not a fan of RISC-V although Chisel is pretty cool. Still I was forced to admit that its free as in beer licensing has won some nontrivial design wins (NVidia). I think however that that was more Arm shooting itself in the foot.

Re: Intel releases the last Itanium chip, the 9700

#47

Post by trsohmers »

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?

We have played around with having "hints" in the original source code that will be preserved through the IR, but the vast majority of the optimizations and scheduling decisions we need to do are happening once it has been converted into machine code by the backend. I may be slightly off (I'm the dumb CEO/hardware architect), but I'm fairly sure 85%-90% of our compiler work has been done on the backend... I just remember being told some tweaks were made to clang due to some weird issue.

Re: Intel releases the last Itanium chip, the 9700

#48

Post by drewg123 »

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…

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. And SGI was still a fairly big player with mips64. Both HP and SGI made deals to use Itanium going forward (with HP going so far as to port HP-UX and VMS to Itanium).

I think the server marketplace would probably have been much higher margin without amd64 competition, as itanium was always a high margin player. Its main competitors were the high margin server chips above, plus POWER and SPARC. The low end was x86 controlled by intel, and they could certainly continue to artificially segregate the market and keep margins high. That's what they were good any monopoly does, and what they've been trying to do today with Xeons.

I was a huge fan of Alpha (one of 2 people who ported FreeBSD to the alpha), and I was very sad to see it go. I've always blamed Itanium for its downfall -- I think Alpha had a lot more headroom than PA-RISC, and HP would have kept it going if it were not for Itanium. So I have to admit that I'm quite happy to see Itanium die.

Re: Intel releases the last Itanium chip, the 9700

#50

Post by ChuckMcM »

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 think the events reinforce three good things to know;

1) Adapting the existing system to do new things can trump entirely new systems, even if those new systems are 'better' in some way.

2) You can change hardware "overnight for free" compared to how difficult it is to migrate large software systems.

3) "Eat your young" - Keep innovating in your own products, even if that means it makes previous versions obsolete, because if you don't your competitors will.

So long Itanium.

Post reply on HN