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

81–90 of 98 posts

Re: Intel releases the last Itanium chip, the 9700

#81

Post by kijiki »

trsohmers wrote: post #78
kijiki wrote: post #74

Earlier quoted context omitted.

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

Interesting. The traditional problem in this space is that the source code is lost or otherwise not available. It is not clear that some encrypted source analog to encrypted verilog would be more available.

Re: Intel releases the last Itanium chip, the 9700

#82

Post by CalChris »

deepnotderp wrote: post #79
CalChris wrote: post #76

Earlier quoted context omitted.

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

No, Skylake is not a RISC internally. Find something from the Intel Optimization Manual or their patents saying that. I been over this already. μops are hundreds of bits wide. Ain't nothing reduced about that.

Read up on horizontal microprogramming. A RISC ISA is an encoding with an opcode. A μop is really just a long set of fields with some bits clocking some FUs on and others off. There is no decoding; there is no opcode.

Re: Intel releases the last Itanium chip, the 9700

#83

Post by deepnotderp »

CalChris wrote: post #82
deepnotderp wrote: post #79

Earlier quoted context omitted.

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

No, Skylake is not a RISC internally. Find something from the Intel Optimization Manual or their patents saying that. I been over this already. μops are hundreds of bits wide. Ain't nothing reduced about that. Read up on horizontal microprogramming. A RISC ISA is an encoding with an opcode. A μop is really just a long set of fields with some bits clocking some FUs on and others off. There is no decoding; there is no…

I'm aware of horizontal microprogramming,and I checked again but I still don't see your point. Maybe link a reference?

Re: Intel releases the last Itanium chip, the 9700

#84

Post by deepnotderp »

atombender wrote: post #72
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…

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?

Branch prediction under latency constraints is a difficult task! I believe perceptrons are the SOTA right now (have recently beat out TAGE predictors to take the crown once again) but are very energy intensive, the alternative is (which is currently used I think) are two level look up tables.

Re: Intel releases the last Itanium chip, the 9700

#85

Post by thesz »

chrisseaton wrote: post #75
thesz wrote: post #58

Earlier quoted context omitted.

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.

For thread-level parallelism to be added you need to perform something akin to Fourier-Motzkin resolution algorithm or Omega test to find out what dependencies program has and has not.

FM is NP-hard. Omega test is imprecise.

And in general you need more complicated checks like aliasing checks. Which are equal to stopping problem, most of the time.

Usually you can't spend that amount of time on EACH INVOCATION of a program.

Re: Intel releases the last Itanium chip, the 9700

#86

Post by chrisseaton »

thesz wrote: post #85
chrisseaton wrote: post #75

Earlier quoted context omitted.

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

For thread-level parallelism to be added you need to perform something akin to Fourier-Motzkin resolution algorithm or Omega test to find out what dependencies program has and has not. FM is NP-hard. Omega test is imprecise. And in general you need more complicated checks like aliasing checks. Which are equal to stopping problem, most of the time. Usually you can't spend that amount of time on EACH INVOCATION of a pr…

The techniques you are talking about are for proving that there is parallelism. The beauty of a JIT is that you can speculate that there is parallelism, go ahead, and then sort out the mess later and recompile to sequential if there wasn't.

https://en.wikipedia.org/wiki/Speculative_multithreading

You can use hardware functionality such as TSX to support this.

Re: Intel releases the last Itanium chip, the 9700

#87

Post by CalChris »

deepnotderp wrote: post #83
CalChris wrote: post #82

Earlier quoted context omitted.

No, Skylake is not a RISC internally. Find something from the Intel Optimization Manual or their patents saying that. I been over this already. μops are hundreds of bits wide. Ain't nothing reduced about that. Read up on horizontal microprogramming. A RISC ISA is an encoding with an opcode. A μop is really just a long set of fields with some bits clocking some FUs on and others off. There is no decoding; there is no…

I'm aware of horizontal microprogramming,and I checked again but I still don't see your point. Maybe link a reference?

Smotherman.

A complete macroinstruction is executed by generating an appropriately timed sequence of groups of control signals (micro-operations).

http://www.frsn.utn.edu.ar/tecnicas3/manuales/Microprogrammi...

Originally, RISC cpus were hardwired but they are general purpose ISAs. RISC-V is fixed 32b ISA but has multiple formats controlled by an opcode.

https://image.slidesharecdn.com/20160130deckyfosdemportinghe...

Original microprogrammed CPUs had a writeable control store (WCS). Modern processors translate CISC instructions into μops and cache this translation. The difference is the μop cache (μstore) vs WCS. FWIW, Skylake also has a WCS for obscure instructions.

Microinstructions, μops, do not have an opcode. They are not decoded. Bits in a horizontal μop gate logic on/off directly.

The RISC-V people do say RISC-like.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-...

And even that's wrong. But then they never even define what a RISC is. So RISC-like could be anything.

Re: Intel releases the last Itanium chip, the 9700

#88

Post by bogomipz »

zargon wrote: post #32
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.

Oh interesting, I did not know that. I have heard that the US government has a lot of VMS systems. If that's true then this alone would make sense for HP to fund Itanium to some extent.

Re: Intel releases the last Itanium chip, the 9700

#89

Post by Nomentatus »

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…

After all the technical details, I'm more and more convinced that Intel very badly wanted to shake off AMD, so they grasped at a too-thin excuse to do so; their eye was really on how much more coin they could shake out of everyone's pockets once they'd established a true monopoly just at the historical moment when monopoly law was being most thoroughly ignored.
Post reply on HN