Hacker News Reader

Comment by Animats | Hacker News Reader

It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come.

GPUs, though. Those have turned out to be very successful, they can be parallelized as much as you're willing to pay for, and they're good for some non-graphics tasks.

Much of machine learning is a simple repetitive computation running at low precision. Special purpose hardware can do that very well.

So what's the next useful thing in that area?

View on HN

> Remember the Itanium

Well, why not.

> Q: I feel like deja vu - at Hot Chips, Intel introduced VLIW-concept Itanium that pushed complexity onto the compiler. I see traces of that here. What are you doing to avoid the Itanium traps? How will you avoid IP from Intel?

> A: Itanium was in-order VLIW, hope people will build compiler to get perf. We came from opposite direction - we use dynamic scheduling. We are not VLIW, every node defines sub-graphs and dependent instructions. We designed the compiler first. We build hardware around the compiler, Intel approach the opposite.

https://www.anandtech.com/show/13255/hot-chips-2018-tachyum-...

That captures a lot of my take on Itanium at the time: despite being "VLIW" it took on what at the time was a vast amount of CPU controller complexity without an obvious design win or clear high-performance compilation model. As an outsider, it felt like an extremum of Intel's flavor of design hubris.

It's interesting to compare the Itanium's approach to a VLIW contemporary from TI: the C6x VLIW DSP ISA. The C6x ISA took on very little controller complexity. Instead, it exposed a very clear operational and optimization model for the VLIW instruction blocks. An optimizing compiler did a decent first-step job at generating code. That was complemented by clear documentation of the optimization workflow, from compiler-stage iteration down to good guidance on the nuts and bolts of hand-optimizing. By comparison, IA64 was just ... a big head-scratching moment all around. I never got to work with C6x code professionally, but dang it looked like a blast to code and optimize for.

What was the controller complexity of the Itanium you're referring to?

Well, past experiences are not that useful right now. I don't think the Itanium or the Cell were great architectures, but it's clear that their most obvious failure mode (mainstream architectures improving faster than them) isn't a showstopper anymore.

For some guess on the next big thing, I would imagine that stuff that avoid the need of memory coherence have nice odds.

The most obvious failure for the Cell architecture was that it was horrendous to program. That was partly caused by the lack of memory coherence between the PPE (main core that ran the OS) and the SPEs (the faster cores meant for offloading computations to), but also caused by a lack of developer tools.

The main lesson I would take away from Cell is that you want to design an architecture that allows gradual performance refinement. With the Cell, it was more of a step function: good performance came from using the SPEs well, but using the SPEs well was hard. There wasn't much of an in-between.

Developer tools come with time, and time is the one thing non-standard architectures completely lacked until recently.

I still don't think the Cell had much future, but we will never be sure. (Also, the Cell had complete memory coherence.)

Yes, I mispoke by saying the SPEs lacked memory coherence, since you used the same physical addresses to load memory into the SPEs local storage. What I meant is that the SPEs are divorced from the normal memory hierarchy. You needed to explicitly retrieve and send all memory from each SPEs, which was a significant burden on programmers.

Does this mean it was a mistake or just ahead of its time? I think software-managed memory tiers have been a dream for advanced architectures for a very long time. The problem, perhaps is assuming software-managed means programmer-managed.

In a single system there is precedent in virtual memory systems using software-managed page mappings rather than static page table data structures. In HPC there is of course the precedent of distributed parallel systems with message-passing rather than shared memory abstractions. And the separation of GPU memory from system memory is certainly common today. Similar things are happening in software-defined storage (i.e. RAM/SSD/disk/tape tiering).

Computation libraries and frameworks help straddle the gap between application programmer needs and current language/runtime/architecture semantics. I think one problem of current markets is that people tend to want to evaluate hardware independently of software, or in terms of yesterday's software.

There is also a strange history of wanting to discard the software/firmware offered by the hardware vendor (for being insecure/inept/whatever), but blindly accepting the complex hardware design that enables our naive/platform-independent software to run well. The whole Spectre debacle shows how that may have been wishful thinking that we can divorce the software and hardware designs...

Does anyone else have real-world Itanium experience? We've got a couple 5+ year old HP Integrity servers running OpenVMS on Itanium at work that we use to batch process large ASCII vendor files in an ETL process written in C. They certainly don't embarrass themselves. We'll be connecting them to a new Pure Storage SAN in a few months and the IT guys are really excited to see what happens to performance.

I take the same exact C code, compile it with Visual Studio, and then run the same ASCII files locally on my 7th-gen 4c/8t i7 desktop and am not seeing any improvement. That's about the best I can do as far as benchmarking goes.

At my previous job we used itanium servers for the secure64 dns platform[1]. It performed well, the logic behind itanium is security not performance (according to secure64) but performance was never an issue. I do know the hardware support for rsa did give nice performance for dnssec signing.

[1] https://secure64.com/dns-products/secure64-platforms/secure-...

The logic behind Itanium was mostly to have a 64-bit architecture that was specific to Intel without any cross-licensing to other vendors like AMD. And which would also replace proprietary RISC flavors like PA-RISC.

It did also have a fair bit of security acceleration built-in. As I recall, one of the principals behind Secure64 was one of the HP leads associated with the original IA64 announcement. Secure64 pushed Itanium for security applications when it was becoming clear that it was never going to be a mainstream 64-bit architecture.

I used Itanium from 2003-2006 for scientific computing on a big cluster. For that purpose it was much faster than Intel's Xeons of similar vintage. It was also significantly faster than the MIPS and POWER systems we had. Caveats:

- The simulation suite that I used most heavily was developed in-house at the same lab that bought the hardware. It was profiled and tuned specifically for our hardware. The development team was a real software development team with experience writing parallel simulation code since the early 1990s. It wasn't just a bunch of PhD students trying to shove new features into the software to finish their theses.

- There was also close cooperation between the lab, the system vendor (HP), and Intel.

- Other software (like all the packages shipped with RHEL for Itanium) didn't seem particularly fast.

- God help you if you needed to run software that was available only as binary for x86. The x86 emulation was not fast at all.

It was great for numerical code that had been specifically tuned for it. It was pretty good for numerical code that had been tuned for other contemporary machines. Otherwise I didn't see particularly good performance from it. I don't know if it really was a design that was only good for HPC or if (e.g.) it also would have been good for Java/databases, given sufficient software investments.

Maybe it would have been competitive against AMD64, even considering the difficulty of architecture-switching, if it had not been so expensive. But I'm not sure Intel had wiggle room to price Itanium to pressure AMD64 even if they had wanted to; Itaniums were quite big, complicated chips.

Numerical code is usually the best case for VLIW machines. It is not surprising that Itanium did well there.

Even SIMD, a feature of processors for over 20 years, is not handled well by compilers for automatic optimization. It seems like all code taking advantage of SIMD either drops into ASM, or uses a library from ARM/Intel to give descriptive C functions names for the underlying ASM.

I wonder why high level languages themselves don't add syntax support for wide-math instructions? I understand why loop unpacking is a little tricky, so why not let the programmer take care of it?

.NET and Julia do offer such support.

Java is in the process of doing it as part of Arrays 2.0 roadmap.

There is ispc: https://ispc.github.io/

It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come.

GPUs, though. Those have turned out to be very successful, they can be parallelized as much as you're willing to pay for, and they're good for some non-graphics tasks.

Not all CPU architectures are equally successful. Likewise, not all highly parallel architectures will be equally successful. If progress in hardware is going to be characterized by more parallelization, things like Erlang Actors are going to become more important.

I vaguely remember my computer arch course in college describing how everything we have today essentially suffers from the von neumann bottleneck, that even if we implemented a lambda calculus machine, it would still suffer from this bottleneck. Has this been revisited in academia lately? I am a bit out of touch, but this always interested me.

You can interpret my comment thus: I propose having lots and lots of Von Neumann bottlenecks!

You're very clever, young man, very clever. But it's bottlenecks all the way down!

The Cell was way ahead of its time. Its security architecture capabilities was almost perfect, but they've screwed up the implementation and they failed to provide good programming tools. And, it was very very expensive.

>It's really hard. Remember the Itanium and the Cell. You can build it, but they may not come.

I think the problem with those is that they failed to build anything compelling -- not that people didn't come.

I think that the sitch is different these days. Ideally, you’d have an end-to-end solution (hw, os, compiler). These days you can build an architecture, fork llvm and add a new backend and get Linux running. At that point you can start selling.

Itanium only failed because Intel had agreements in place that allowed AMD to build x86 compatible CPUs, and they were clever to come up with AMD64.

If it wasn't for that AMD stunt we would all be using Itaniums by now.

In other words, Itanium only failed because there was competition.

No, Itanium failed because Intel made the error to allow other companies to compete on the x86 space with their patents cross licensing deal.

Competition from other architectures was always there.

In other words, Itanium only failed because there was competition in the x86 space.

Of course having the option to run existing binaries made it a no brainer for companies to avoid spending money.

Hence Intel's mistake.

Dynamic x86 imterpretation could have made competition as well. There were companies that did that and had Intel moved to EPIC others might have done what AMD did.

Just "clean" what we already have is more than enough, IMHO.

Things can already target X64/Arm but with a minimal kernel and a foundation without C at the base.

---

Even with a complete new CPU/Arch (that weirdly, I dream about that!) you can solve compatibility with VM/Containers. And provide a better user-land.

Reply on news.ycombinator.com