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

31–40 of 98 posts

Re: Intel releases the last Itanium chip, the 9700

#31

Post by DannyBee »

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

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 actually can do it well dynamically (IE i could make a branch guessing thread and a prefetching thread), but you can't do it fast enough.

In a lot of workloads, most time is spent stalling for memory.

Also note that in VLIW, you have to extract ILP or you are just wasting time (IE are executing NOPs). You end up with a half or 3/4 empty pipeline. So unless you can predict you are going to stall for memory well, you are wasting the pipeline. On the other hand, modern OOO cores can just extract more ILP when possible. IE when stalling for memory, they can figure out what they could be doing otherwise.

Re: Intel releases the last Itanium chip, the 9700

#32

Post by zargon »

bogomipz wrote: post #24

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

Xeon wasn't losing focus to Itanium... that's just the author writing filler material.

The main customer of Itanium that I'm aware of is the VMS operating system. It was ported from Alpha to Itanium in the early days of Itanium and anyone dependent on VMS has been reliant on Itanium since then. HP paid Intel a few years ago not to kill Itanium in the meantime while they were porting VMS to x86.

Re: Intel releases the last Itanium chip, the 9700

#33

Post by chrisseaton »

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…

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.

Re: Intel releases the last Itanium chip, the 9700

#34

Post by CyberDildonics »

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

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 possible. To put all that aside and hope that compilers and programmers become much more sophisticated was never going to happen, especially because so much software is already set and won't change.

Re: Intel releases the last Itanium chip, the 9700

#35

Post by trsohmers »

CalChris wrote: post #18
deepnotderp wrote: post #7

Earlier quoted context omitted.

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.

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 VLIW in spirit (which you cans see me talk in more depth on here: https://youtu.be/ki6jVXZM2XU?t=441). Itanium introduced a ton of indeterminism by having static scheduling unfriendly things like branch prediction, variable latency caches, and still trying to have some level of support for x86. The core problem for Itanium is that it was impossible for the compiler to make good decisions in the vast majority of applications since the compiler could not know exactly where and when things in memory would be. I believe the underlying failure point has been computer architects for failed VLIW architectures not realizing that fancy bells and whistles and "cleverly complex" hardware designs is the exact opposite of what you want when the compiler needs to be able to do purely static allocation. Adding fancy dynamic pieces in hardware to account from this (seen in a lot of places with Itanium) just makes the problem worse.

The main improvement we have made with the Neo architecture is we have hard (exact cycle count) guarantees on all memory movements on and off the chip, which actually gives the compiler the information it needs to make good decisions and very condensed code. I think the jury is out on the applicability for "general purpose" code on VLIWs... it is not something we at REX really care about at the moment, and I think RISC-V is a great solution with improvements over x86 and ARM.

Re: Intel releases the last Itanium chip, the 9700

#36

Post by CyberDildonics »

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.

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.

Re: Intel releases the last Itanium chip, the 9700

#37

Post by CyberDildonics »

KenoFischer wrote: post #5
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…

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

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

Re: Intel releases the last Itanium chip, the 9700

#38

Post by KenoFischer »

userbinator wrote: post #25
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…

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…

Yes, I understand. What I meant was that you don't want to be running those kinds of codes on a KNL, because the performance is absolutely terrible. Nevertheless, Intel is producing the KNL, so there's now a market for this kind of thing, which may not have been there 15 years ago.

Re: Intel releases the last Itanium chip, the 9700

#39

Post by KenoFischer »

CyberDildonics wrote: post #37
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…

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 ;).

Re: Intel releases the last Itanium chip, the 9700

#40

Post by CyberDildonics »

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…

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