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

71–80 of 98 posts

Re: Intel releases the last Itanium chip, the 9700

#71

Post by martinpw »

trentnelson wrote: post #29

Related: 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: "Davi…

> Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads.

At the time Itanium was actively being pushed by Intel I was working for a company building content creation software. Intel was very interested in us porting to Itanium and provided considerable help to that effort. One of the big reasons was that they were interested in being able to see the traces, precisely for the reason you state - most of their existing test code was not representative of typical large scale commercial software.

We got it running but never released it - the binaries were huge (3x x86) which was a big issue back then, and the performance just wasn't there.

Re: Intel releases the last Itanium chip, the 9700

#72

Post by atombender »

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…

I always wondered how CPUs could do all of this so fast. Doesn't all the branch prediction etc. have to be done by a kind of program that is "parsing" instructions on the fly and storing state about its execution? How is that implemented, and how is it faster than doing the equivalent in software?

Re: Intel releases the last Itanium chip, the 9700

#73

Post by deepnotderp »

CalChris wrote: post #46
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…

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.

Just a question, why are you against RISC-V?

I quite like RISC-V and think it's elegant and simple, but maybe I'm wrong :)

Re: Intel releases the last Itanium chip, the 9700

#74

Post by kijiki »

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…

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

This is a fascinating idea, but I have a question.

What happens when the next process generation lets you improve cache timings? What about newer, faster DRAM (or whatever) timings?

Do I have to recompile the world in that case, to see any improvement in performance?

Re: Intel releases the last Itanium chip, the 9700

#75

Post by chrisseaton »

thesz wrote: post #58
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.

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

> JITs can't do is to add and/or remove parallelism from the program

Of course they can. A trivial practical example is the JVM JIT using vector instructions to add parallelism to a program that didn't have any before. But a JIT compiler could also profile code and add thread-level parallelism if it wanted.

Re: Intel releases the last Itanium chip, the 9700

#76

Post by CalChris »

deepnotderp wrote: post #73
CalChris wrote: post #46

Earlier quoted context omitted.

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.

Just a question, why are you against RISC-V? I quite like RISC-V and think it's elegant and simple, but maybe I'm wrong :)

My biggest complaint about RISC-V is its lack of condition codes. This is just too puritanical. I think ARMv8 strikes a nice balance here. Leaving something out that both ARM and Intel provide seems pointlessly austere.

As was pointed out in the A History of Modern 64-bit Computing cite, both RISC and Itanium show an academic bias. Yes, RISC-V is elegant and simple and that helps in a one semester upper div architecture class. But that doesn't help you much outside of a one semester upper div architecture class.

So what do you tangibly get with that elegance and simplicity? You aren't going to write RISC-V assembly; compilers are better especially for such a regular and spare ISA. This is 2017 and LLVM has been a thing for quite some time. Compilers are not a big deal.

Lower power? Chip area? How much lower power and chip area are we talking about?

Re: Intel releases the last Itanium chip, the 9700

#77

Post by trsohmers »

flamedoge wrote: post #70
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…

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.

It isn't something we have been looking at, as our current customers and target applications would have our chip as a standalone embedded processor. We are working on a prototype PCIe card with an FPGA to be able to convert our SerDes to something a PC can talk to, but it isn't really a priority unless we have someone come to us directly asking for it.

As for upstreaming, it is something that we want to do, but are not sure if it will be accepted as our chip is not generally available at the moment. It would probably be done around the same time as our next tape out (which would be in larger quantity than our first one) when we would have generally available development kits this coming winter.

I have been working on public documentation in my spare time... originally supposed to go out in March but we have had other priorities. If you watch my Stanford talk I show the basic ISA overview as well as the WIP documentation made using doxygen. I'm hoping to get stuff out on our website before our next media push in ~June.

Re: Intel releases the last Itanium chip, the 9700

#78

Post by trsohmers »

kijiki wrote: post #74
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…

> 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 ... This is a fascinating idea, but I have a question. What happens when the next process generation lets you improve cache timings? What about newer, faster DRAM (or whatever) timings? Do I have to recompile the world in that case, to see any improvement in performa…

The assumption by us is that you would be recompiling from at least the LLVM IR level for each different version of the chip. This isn't a real problem for the markets we care about, as they have the source code for all of their applications. In the case of not wanting to distribute your source code, I am interested in being able to distribute emcrypted LLVM IR as a pseudo-binary, similar to how silicon IP companies deliver encrypted verilog and vhdl for integration into other chips.

Re: Intel releases the last Itanium chip, the 9700

#79

Post by deepnotderp »

CalChris wrote: post #76
deepnotderp wrote: post #73

Earlier quoted context omitted.

Just a question, why are you against RISC-V? I quite like RISC-V and think it's elegant and simple, but maybe I'm wrong :)

My biggest complaint about RISC-V is its lack of condition codes. This is just too puritanical. I think ARMv8 strikes a nice balance here. Leaving something out that both ARM and Intel provide seems pointlessly austere. As was pointed out in the A History of Modern 64-bit Computing cite, both RISC and Itanium show an academic bias. Yes, RISC-V is elegant and simple and that helps in a one semester upper div architect…

I'm not too sure about the "academic bias" point, since modern "CISC" CPUs are essentially "CISC on RISC" and essentially RISC already.

That being said, greater efficiency is the main point, it's not too difficult to get a RISC-V core that beats (albeit marginally) an equivalent ARM core.

Optimizing compilers can often be difficult though, especially if you want to use novel modifications to the backend to make things more efficient.

Re: Intel releases the last Itanium chip, the 9700

#80

Post by deepnotderp »

bonzini wrote: post #59
CyberDildonics wrote: post #36

Earlier quoted context omitted.

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.

It's less of a miracle and more like "larger OoO window, K done"
Post reply on HN