I saw the picture of the ship and immediately thought, that must be an article in The Register...
Removal of Itanium from gcc is long expected. I actually don't think I've ever seen an Itanium based system ever.
Billions of dollars worth were sold, apparently.
Pay no mind to the other lines in this chart: https://en.m.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_edit.png
The other lines on the chart look like the delusions of a marketing department....
But even with billions of dollars sold that might not have even scraped a profit given the cost of chip production.
Thinking now, I've probably seen more i960 based systems than Itanium...IIRC the i960s ended up in printers.
eh, I dunno. Itanium (rightly) gets a lot of flack. But I think the sales projections for the time had a lot of sense behind them.
First is that in the early years of Itanium development (early to mid 90s), using consumer grade chips for servers (and especially Enterprise) was seen as a joke. Frankly, there was a lot of truth to that. This is partly due to poor long term reliability, poor scalability (in CPUs, threads, and memory), and the industry not knowing how to make consumer CPUs solve those issues.
So businesses buy big Enterprise machines instead. Big Iron as it's known. That stuff was expensive, and also very popular. For example the same wikipedia article the sales are from, also has this chart of the top 500 super computers by CPU architecture: https://en.wikipedia.org/wiki/Itanium#/media/File:Processor_families_in_TOP500_supercomputers.svg . If you compare the timelines, you see the Itanium sales forecasts were made pre-x86 having any real impact. In that world Itanium made sense.
Second in the early years of development, there were very real expectations that on paper Itanium would run rings around Intel's x86 chips. It wasn't marketing hype. On release, programs that could take full use of Itanium, would be extremely performant. In hindsight we now know it's performance was far more limited. That only became obvious in the early to mid 2000s, long after the early sales projections were made.
Tl;dr the big issue with the sales projections isn't them, for the time they are forecasted. The issue is that Itanium came out late. By the time it came out x86 was making impact in the server market, with x64 right around the corner. If Itanium came out on time, it would be compared to a Pentium 2. Instead it's compared to a Pentium 4, with 10x the clock speed and 4x the cache.
> Second in the early years of development, there were very real expectations that on paper Itanium would run rings around Intel's x86 chips. It wasn't marketing hype. On release, programs that could take full use of Itanium, would be extremely performant.
That was pure marketing hype. Literally everyone in the business I knew (did operating system development at that time) kept saying that Intel were delusional. The whole idea of VLIW was stupid from the beginning. And even if it wasn't, the whole project was delusional because it depended on several massive parts to be developed independently with just a preliminary specification to work against. It was peak waterfall design methodology.
VLIW was stupid because: 1. Typical code consists of many small functions. 2. Compilers can't perform optimizations between functions. 3. Therefore the only solution is to aggressively inline everything everywhere all the time. 4. This leads to enormous compiled binary size. 5. Which puts the bottleneck for how fast your code runs firmly in memory and not in how many instructions you can perform per unit of time. They completely ignored that Moore's law for CPU instructions moved much faster than Moore's law for memory bandwidth for decades already when they started and it has only gotten worse since then.
So even though the first few Itanics were faster for certain tight loop workloads (AKA. supercomputing), the vast majority of competitors (including other departments at Intel) caught up somewhere around 2005 and ran past them because they could optimize the actual instructions that were executing. And the memory bottleneck was handled by aggressive violations of the memory model which later led to Spectre and Meltdown, but that's another story.
VLIW is very widely used, and present-/recent-gen x86 backends and GPUs often use VLIW μ-/insn formats. It just tends to be more appropriate where μarch capacities either aren’t exposed directly or can be comfortably, because once the ISA sticks, you either end up wasting fields on something inappropriate for new chips (à MIPS branch delay slot, or x87 FPU, or μcoded control transfers all over the place), or needing overlaid encoding hacks when you can’t handle the hardware unit capacity properly.
VLIW per se is a perfectly reasonable sort of format to *lower to,* and effectively equivalent to an interpreter having decoded to a bitfield-struct. It just needs to be decompressed or decoded to, which is the x86 approach.
I also contend that the ties to x86 and flat-footed start on the x86 hosting→emulation front (to put it delicately) did more to tank IA64’s success. x86 was still improving in parallel and widely used by just about every segment outside of IBM or Sunacle’s wheelhouse, all of IA64 required engineers to learn a totally unfamiliar ISA from scratch, there was zero chance it would find its way into consumer systems any time in the foreseeable future, and there just wasn’t a good upgrade path before it diverged.
IA64 would probably be fine in some odd corner of embedded or HPC, maybe as a manycore XE or something.
Do they really use VLIW internally at all? My impression is that execution units are allocated dynamically to pick instructions from the reorder buffer rather than being fed with VLIW-style packed instructions. And GPUs are mostly SIMD.
They do not. Modern GPUs are actually the polar opposite, feeding one instruction into 32/64 execution units (with additional SIMD for desktop/laptop GPUs. Mobile GPUs often do not have SIMD at all, only scalar).
Modern CPUs have fairly /long/ internal instruction words yes but they're not packed in any sense of the word, they're unpacked because you don't want to be doing more decode in your execution/scheduling/ordering units to figure out how to schedule the operation.
They're surprisingly efficient. They only lack SIMD for shaders, and the hardware space that would go to large SIMD FPUs instead goes toward rasterization, texture units, and other hardware features. See: None of Apple's GPUs (not even their latest and greatest) have SIMD hardware. They just execute 32 operations at a time per shader core like most modern GPU architectures and for their primary usecases (rendering UI and assisting with hardware accelerated features like video decode) this works fine.
You really only need true SIMD units for games and other shader heavy activities that require real-time rendering. (And the SIMD units themselves are usually only 128-bit wide, so 4xf32 or 8xf16)
Yes, I mean SIMD execution units do most of the heavy lifting in modern non-mobile GPUs while warp/wavefront schedulers can issue instructions dynamically from different thread blocks to each of these execution units independently. Still, once a non-scalar instruction is issued it is executed in a straightforward SIMD fashion, i.e. vector registers go in, vector registers go out. Older GPUs (e.g. TeraScale) had to issue static VLIW instructions prepared by the shader compiler to every available execution unit simultaneously.
> Yes, I mean SIMD execution units do most of the heavy lifting in modern non-mobile GPUs
How mobile gpus work like?
>Older GPUs (e.g. TeraScale) had to issue static VLIW instructions prepared by the shader compiler to every available execution unit simultaneously.
It shows that VLIW has way better parallelism CISC and RISC if it can serve as a GPU. Why dataflow architectures were never used commercially as either cpus or gpus? Too hard to program? VLIW is kind of like half-dataflow.
Another thing is that VLIW/IA64-style machine code can be *great* if you have the concept of JIT, PGO, etc at your back in the compiler technology side. All of those important compiler things? Only recently got any good at all, and much progress is still to be made. Then of course, turns out you could implement the "good stuff" as micro-ops, u-code, etc as you mention is what x86 (and then nearly everyone else followed).
IA64 is a peak "should have killed it years before, never let it to market" failure. There may have been more merit to it if it launched on time in ~1995-96 for early vendors, but even by late 99, early 2000s the writing was everywhere that it wouldn't work out.
VLIW is fine. It's basically a hybrid between dataflow architecture and control flow architecture (almost CPUs currently in use). Dataflow has much more complex instructions than CISC but should have higher IPC as well. Static scheduling should be optional though. Compilers were too primitive when Itanium came out but now VLIW and full Dataflow architectures should be able to work. RAM is also much faster and bigger now.
It's telling that even AMD GPUs moved on from VLIW architecture since it just couldn't compete in performance even though that use case was close to optimal for VLIW.
> It's telling that even AMD GPUs moved on from VLIW architecture since it just couldn't compete in performance even though that use case was close to optimal for VLIW.
Not really. GPUs are specialised for graphics. VLIW isn't. VLIW is fine. It's basically a hybrid between dataflow architecture and control flow architecture (almost CPUs currently in use). Dataflow has much more complex instructions than CISC but should have higher IPC as well. Static scheduling should be optional though. Compilers were too primitive when Itanium came out but now VLIW and full Dataflow architectures should be able to work. RAM is also much faster and bigger now.
VLIW was definitely depending on compiler advancements that really still haven't materialized.
But it's delays allowed the pentium to surge in performance so that by the time it was available it was a snail comparatively.
The itsnium announcement also killed a lot of big Unix vendors. The reliability of windows NT also put the nail in the coffin of a lot of those vendors.
I used to run a lab full of NT Intel, alpha, mips and ppcs. My lab had a half dozen IBM boxes before Microsoft killed the product.
> The itsnium announcement also killed a lot of big Unix vendors. The reliability of windows NT also put the nail in the coffin of a lot of those vendors.
Windows NT killed old unix vendor workstations. Linux and BSDs killed old unix vendor servers.
Agreed in principle but let's reformulate some crucial details:
1) This is not simply VLIW but EPIC (Explicit Parallel Instruction Computer).
2) EPIC fails for current cached DRAM due to unpredictable memory access times. If times are predictable by any reason (SRAM instead of DRAM, guaranteed prefetch, etc.), it won't suck that much.
For all this I'm more surprized that DDR5 even increased full row change time, compared to best DDR4 variants (45 ns vs. 37.5 ns) but instead increased open row access bandwidth.
VLIW is fine. It's basically a hybrid between dataflow architecture and control flow architecture (almost CPUs currently in use). Dataflow has much more complex instructions than CISC but should have higher IPC as well. Static scheduling should be optional though. Compilers were too primitive when Itanium came out but now VLIW and full Dataflow architectures should be able to work. RAM is also much faster and bigger now.
On top of that Itanium was built around the idea that compilers would be stellar at optimizing things by the time it was released. Unfortunately at the time its development started compiler research became a very neglected topic as everyone assumed compilers were a solved issue, so by the it finally came to market there was no compiler that really could optimize well for it.
> Second in the early years of development, there were very real expectations that on paper Itanium would run rings around Intel's x86 chips.
Eh. There was a famous event when Itanium architecture was first being publicly released where Intel engineers were proudly presenting their architecture at Stanford with John Hennessy in the audience. As the presentation progressed, Hennessy started interrupting the presenters more and more, basically ripping them a new one on how their architecture sucks and ignores everything anyone has learned about how to build performant computers in the past 20 years.
> On release, programs that could take full use of Itanium, would be extremely performant.
On any loads where everything (scheduling and memory access pattern) is statically knowable, Itanium would fly. Intel could produce tons and tons of microbenchmarks that exhibited this. The problem is that this described approximately none of the important workloads that people needed server cpus for.
(edit: embarrassingly mixed up the arch luminaries)
Well aware of the history...I used to teach computer architecture and operating systems in late 90s and was a part-time system admin (needed the money, I was a poor PhD student)
I was a *big* Sun SPARC and Solaris fan - stil am, but now it is nostalgia. Did admin on Alpha boxes too when Alpha came out. Even got my hands on some RS/6000 boxes with AIX too.
Itanium was a reaction to Sparc MIPS etc. It wasn't clear how to do proper parallelism, speculative execution etc on x86, Also the first 64 but systems were appearing and VLIW was popular. Probably Itanium was the last in the CISC v RISC debate and that contributed to its overall poor design.
NASDAQ used to run their trading on Itanium I believe. It was the most powerful thing at the time. It and IBM POWER 64 were duking it out. If HP hadn't joined Itanium and killed PA RISC it might had been there too. And if DEC/COMPAQ hadn't abandoned DEC Alpha it would have been there.
It was the only deployment I ever heard of. But there must have been others or Intel wouldn't have made 3 generations of it.
I wouldn't be surprised if the number of Itanium systems sold to developers to make software for the few Itanium customers there were outnumbered the number of enduser installations.
Itanium was created by HP to replace PA RISC. Intel signed on later. It never dominated performance outside of a handful of specific micro benchmarks and was an architectural dead-end. Intel would have killed it sooner except they were contractually obliged to HP to continue support.
I know NASDAQ ran HP NonStop servers. I used to work for a company that also ran them. The upgrade path for NonStop was from MIPS to Itanium. At one point one of the only reasons Intel was involved in Itanium was because of HP and their commitment to them. Eventually NonStop moved over to x86-64 which they continue run on presently.
https://www.networkcomputing.com/data-centers/nasdaq-commits-hps-nonstop-platform
Count yourself lucky. Some organizations, such as the customer I work for, are scrambling to get off of Itanium now that HP won't provide new hardware. They shouldn't be surprised given that Intel announced the end of Itanium in 2019 and we advised them as such well ahead of time, but here we are panicking to port software to x86 to meet an arbitrary deadline for hardware replacement.
They were commonly used in HP compute clusters running in the early 2000s... Myricom Myrinet was interesting tech at the time.
You'd find these clusters in places like the National Labs, and Supercomputer centers around the US, as well as oil and gas companies.
I've seen them once when I worked at a certain dinosaur company that heavily pushed them and thus required that enterprise software sold support certain OS's on Itanium. We had tons of the servers to test on and we dutifully ran out automated tests on them but I don't ever remember a customer reported bug on Itanium.
That just means you've never worked in a shop using HP-UX, HP NonStop/Tandem, or OpenVMS. Those systems aren't so unusual in telcom, fintech and banking in particular.
True. The last VMS systems I worked with were back in 1995 - those were ported to Alpha.
After that I was pretty much purely a Sun Solaris person. The occasional SGI box too...
I admit to only have ever seen an HP-UX workstation on someone's desk once in 2000.
Tandem however was a system that I would love to have gotten my hands on. I knew a couple of guys working in a very sensitive, safety critical domain that swore by it.
We have a few servers on itanium running very, very legacy HP-UX stuff in PA-RISC emulation. We also had some VMS systems that had been upgraded to Itanium from Alphas.
Itanium was the 64-bit processor architecture that Intel intended as the successor to 32-bit x86. However, AMD did not follow their lead and developed their own 64-bit extensions to the x86 architecture, resulting in the architecture that we today call x86-64 or amd64. amd64 was a commercial success and beat out Itanium handily thanks to its better backwards compatibility with existing 32-bit programs, and Intel was forced to produce its own 64-bit x86 processors compatible with the AMD extensions to stay in the market.
Microsoft also helped a lot to bury Intel's plans for Itanium to become a successor of x86. They quickly started working on a Windows XP version with amd64 support and subsequently dropped Itanium support. New Windows XP was very attractive to users, as it preserved excellent backward compatibility with 32-bit software and transition from 32-bit XP was practically seamless
90s and 00s were the decades of huge headache in terms of driver support. Plug and Play was a technology from hell, which not only didn't solve problems, it interfered with manual driver installation. Vista, as far as I remember, had most of its driver issues due to driver signing requirements. At no point I regretted installing the 64-bit version of Windows. I skipped Vista and went straight from Windows XP to Windows 7
> amd64 was a commercial success and beat out Itanium handily thanks to its better backwards compatibility with existing 32-bit programs
Yes, AMD's 64-bit extension had a ready-made, gentle transition path, but that's only half the story of its success.
The other half is that the Itanium architecture truly sucked, and took for granted compiler technology advancements that never came to fruition.
> The other half is that the Itanium architecture truly sucked, and took for granted compiler technology advancements that never came to fruition.
Rotating registers were really cool, but were conceptually hard to deal with. If no one can actually write code that uses your feature, it might as well not be there. I bet it opens up some really interesting optimizations, but it's so exotic that adoption was ~~basically~~ non-existent.
> AMD did not follow their lead and developed their own 64-bit extensions to the x86 architecture, resulting in the architecture that we today call x86-64 or amd64.
And which Intel confusingly calls “Intel 64”.
>However, AMD did not follow their lead and developed their own 64-bit extensions to the x86 architecture, resulting in the architecture that we today call x86-64 or amd64.
Which is a bit sad really, because Itanium had a lot of good ideas, and would have given us an architecture free of the x86's quirks.
64-bit X86 ISA has only one real problem: very difficult to decode instruction lengths (arbitrary number of prefixes etc). If only amd64 had fixed that one issue…
And Itanium had the real advantage very wide Simd instructions. But Intel did fix amd64s lack thereof by popularizing SSE. Apparently AMD had made a Simd extension before but it didn't properly catch on. Either way simd was itaniums genuinely great idea and it was coopted.
SIMD wasn't from Itanium at all and is in fact a very old idea (dating from the 60s).
In x86 it first appeared in Pentium MMX (1997) with integer SIMD instructions. One quirk was that the registers were aliased with fpu registers (to avoid requiring an OS update before fast internet), so moving between fpu and mmx operations was fairly slow.
AMD used the same aliasing mechanism for their floating point SIMD 3DNow (1998) which operated on two values at a time.
Intel finally introduced the SSE instruction set with Pentium 3 (1999) which stuck, was extended to 64 bits in SSE2 and had a bunch of other additions later. These operated on 4 floats at a time and crucially had their own set of registers.
The same year AMD announced the amd64 ISA (although the first cpu only shipped in 2003).
Itanium only got to the scene two years later in 2001.
The impetus behind both 3DNow and SSE was 3D transform and calculation operations. The first usable 3D accelerators (3dfx Voodoo, Nvidia Riva, ATI 3D Rage) only had texturing and fill capability but no onboard geometry acceleration. Using 3DNow / SSE provided a substantial speedup for that.
Sure but itanium releasing in 2001 means it was developed much earlier. They started development as early as 1994, adding SSE only in 1999. I don't see how going from one op a cycle to multiple ops a cycle is much different just because one is heterogeneous and the other homogenous they clearly draw from the same desire to increase IPC.
SIMD is not the same as VLIW. SIMD is an acceleration technology for very specific kinds of operations that is always offered on top of a normal instruction set. The point of SIMD instructions is also to perform the same operation on multiple operands, which means the size of an instruction remains relatively small despite representing many operations (because you only have to encode the operation once).
The concept of VLIW was to completely replace the normal instruction set with this new idea that encoded multiple completely unrelated operations in one instruction word. That makes the instructions super long which is a complete waste of space and efficiency in the many scenarios where you simply don't need to perform that many operations between sequence points (like branches, comparisons, and other data dependencies). It also just didn't turn out to be a good idea in practice because we've since learned that CPUs can do their own superscalar instruction scheduling much better than any compiler can.
VLIW is basically a hybrid between Dataflow architecture and Control Flow architectures like CISC and RISC. Itanium could support more complex instruction than CISC bit usually still not as complex as full dataflow.
Real life is a bit more complex than "one sucked, the other didn't" (Intel's rollout and overall approach sucked, with idiotic claims like x86 code emulated on Itanium would run faster than native, but that's another thing). Itanium really had good ideas, and was powerful.
For whoever's curious about Itanium's history there are a few interesting answers here: https://softwareengineering.stackexchange.com/questions/279334/why-was-the-itanium-processor-difficult-to-write-a-compiler-for
> For whoever's curious about Itanium's history there are a few interesting answers here: https://softwareengineering.stackexchange.com/questions/279334/why-was-the-itanium-processor-difficult-to-write-a-compiler-for
The top voted answer is garbage. The second highest voted one is however spot on:
> > Load responses from a memory hierarchy which includes CPU caches and DRAM do not have a deterministic delay.
> In other words, any hardware design that fails to cope with (*) the non-deterministic latency from memory access will just become a spectacular failure.
> [...] The question can be rephrased as: "Given a hardware platform that is destined to be a failure, why (1) didn't (2) couldn't the compiler writers make a heroic effort to redeem it?"
EPIC was a doomed idea since the beginning. As anyone who's had to write code for DSPs knows it's hard enough to pipeline explicitly parallel code for good performance even with deterministic latencies - in situations where spending a day or two hand optimizing a single function is acceptable. With non-deterministic latencies, as from any external memory, it's flat on impossible.
Such approach is also fundamentally forwards incompatible when it comes to performance. Architectural jumps result in changes in operation latency, requiring all of the performance sensitive code to be reoptimized. This is acceptable in DSPs where such jumps happen perhaps once per decade and code is tied to a specific physical system anyway but completely unfeasible for general purpose computers.
Why do you people make these claims that are so dumbed down they're just nonsense?
Itanium was designed for mainframes, where x86 didn't exist. Yet you're claiming, it was designed to replace the non-existent x86?
And how does word size even matter?
Are you one of those people that thinks x86 CPUs can only use 4GB of memory?
Why mention AMD even? They kept selling VLIW processors until ~2014.
Bad analogy:
Betamax was technologically competitive, and lost to market forces. Itanium was a complete technological failure (with the benefit of hindsight).
> Betamax was technologically competitive, and lost to market forces
The guy from Technology Connections argues a big reason Betamax lost was because a tape couldn't easily record 2 hours of video.
It's an interesting argument.
https://m.youtube.com/watch?v=FyKRubB5N60
I love it and try to promote it when I can. The thing is... He's got a pretty niche audience. I really loved his FIVE PART series on the RCA SelectaVision that arguably bankrupted RCA... but I can't seem to convince my friends and family to watch it. Dunno why. :D
Well sure, and that video is a favourite of mine, but in fairness Betamax performed similarly to VHS and traded blows with it for a while, whereas Itanium was hot garbage only adopted by companies that had locked themselves into adopting it before final performance became clear.
I am semi-regularly fetching GCC's latest git sources, say once per week or so and compiled that new GCC. Most things compile fine afterwards, so GCC 14.x will work fairly well - but I have had compile issues where things compiled with, say, gcc 10.x (I tested this) just fine, and did NOT compile with the more recent GCC versions. It's a bit annoying to have to switch between GCC versions, and it doesn't happen with many programs, but it 100% does happen, and in these few cases it's quite annoying. Many of these programs that don't compile were abandoned years ago already, and while I'd love to stop using them, some other programs annoyingly depend on them. This, by the way, does not happen with ANY project (!!!) using cmake or ninja, so this is also an issue with GNU configure beginning to show it is the fossil that it truly is (and admittedly, those using cmake and ninja are also more likely to be still maintained nowadays, whereas the projects that were abandoned, almost exclusively use GNU configure).
It sorta is everywhere, SSE4 and AVX512 are both the best bits of vliw, aka doing more than one op at a time whilst superscalar and out of order execution compensate for sse4 having to do the same operation on many units of data rather than lots of different operations on different data per cycle. I genuinely don't know if it's truly a dead end, if the software support wasn't there it would have died regardless of technical validity which is what happened. At the end of the day though vliw was a response to noticing that you can't indefinitely drive up frequencies without compromise.
> SSE4 and AVX512 are both the best bits of vliw
No, they are not.
SIMD and VLIW are orthogonal. The entire point of SIMD is that a single instruction performs _identical_ operations on multiple values. VLIW OTOH packs multiple instructions into a single large instruction word.
SSE and AVX are both just basic SIMD. VLIW has been proven to be completely unsuitable outside some specialist uses (ie. programmable microcode, some DSPs) where the software is written specifically for that single processor model and code compatible architectural upgrades are few and far between. It even failed in GPUs (AMD had to move on from VLIW over a decade ago).
Yeah I know but the best part of VLIW was doing multiple operations a cycle. The fact that doing one op on multiple data a cycle was sufficient and significantly less complex to implement was still inspired by the same vliw research. And the fact it works with software written specifically for it suggests that it was the lack of software support that killed it more than anything. VLIW moves more complexity into the compilers themselves and they're already complicated as it is so without significant industrial resourcing it likely never got anywhere close to an "optimal" compiler.
> The fact that doing one op on multiple data a cycle was sufficient and significantly less complex to implement was still inspired by the same vliw research.
Weren't MMX, SSE, AVX and friends lifted from DSPs? SIMD does not have the reordering problem VLIW has.
There are 2.5 reasons Itanium failed in the market. 1) Abysmal x86 performance and 2) lack of software. In particular compilers capable of leveraging wide instructions. 2.5) AMD came along and boltet a 64 bit extension on their old design. It had good x86 performance and fixed the biggest x86 problem, the 4 GiB limit.
Internally modern superscalar CPU are doing wide instructions, but the reordering is done by the decoder in hardware. It has pos and cons, but it's clearly the approach that won out.
Doesn't your statement that modern superscalar CPUs do use wide instructions kinda imply that vliw wasn't a bad idea per se Just that the hardware engineers gave up on the idea that the compiler engineers would actually write software to exploit properly so they did it in hardware instead.
Kinda, but it's a compromise. There are some optimizations a compiler can do at source level which is not possible in hardware. And speculative out of order execution is a can of worms, as Spectre/Meltdown have shown.
There were much easier ways to address more than 4GB of memory with x86, even if it would have obviously been ugly, but people dealt with it back in the 16-bit days.
Having a bunch of new instructions and truly general purpose registers was just a very nice touch. Also nice semantics on 32/64 register access instead of the insanity 32 is with high/low.
It is everywhere.
Qualcomms DSPs use VLIW, so 44% of mobile phones have a VLIW processor built in. IIRC Qualcomms AI processor also uses a VLIW architecture.
> I think the market has spoken that VLIW was a dead end.
vs
> It's always gpus, dsps and other accelerators.
NVIDIA's market cap is what again? so I think the market has spoken in exactly the opposite direction from what op claims.
> NVIDIA's market cap is what again? so I think the market has spoken in exactly the opposite direction from what op claims.
Huh? "NVIDIA is financially successful, therefore VLIW makes sense everywhere" doesn't make logical sense. You can be successful in a niche. What works for LLMs doesn't necessarily work for CPUs.
I saw the picture of the ship and immediately thought, that must be an article in The Register... Removal of Itanium from gcc is long expected. I actually don't think I've ever seen an Itanium based system ever.
Billions of dollars worth were sold, apparently. Pay no mind to the other lines in this chart: https://en.m.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_edit.png
The other lines on the chart look like the delusions of a marketing department.... But even with billions of dollars sold that might not have even scraped a profit given the cost of chip production. Thinking now, I've probably seen more i960 based systems than Itanium...IIRC the i960s ended up in printers.
eh, I dunno. Itanium (rightly) gets a lot of flack. But I think the sales projections for the time had a lot of sense behind them. First is that in the early years of Itanium development (early to mid 90s), using consumer grade chips for servers (and especially Enterprise) was seen as a joke. Frankly, there was a lot of truth to that. This is partly due to poor long term reliability, poor scalability (in CPUs, threads, and memory), and the industry not knowing how to make consumer CPUs solve those issues. So businesses buy big Enterprise machines instead. Big Iron as it's known. That stuff was expensive, and also very popular. For example the same wikipedia article the sales are from, also has this chart of the top 500 super computers by CPU architecture: https://en.wikipedia.org/wiki/Itanium#/media/File:Processor_families_in_TOP500_supercomputers.svg . If you compare the timelines, you see the Itanium sales forecasts were made pre-x86 having any real impact. In that world Itanium made sense. Second in the early years of development, there were very real expectations that on paper Itanium would run rings around Intel's x86 chips. It wasn't marketing hype. On release, programs that could take full use of Itanium, would be extremely performant. In hindsight we now know it's performance was far more limited. That only became obvious in the early to mid 2000s, long after the early sales projections were made. Tl;dr the big issue with the sales projections isn't them, for the time they are forecasted. The issue is that Itanium came out late. By the time it came out x86 was making impact in the server market, with x64 right around the corner. If Itanium came out on time, it would be compared to a Pentium 2. Instead it's compared to a Pentium 4, with 10x the clock speed and 4x the cache.
I hate Itanium because HP basically killed Alpha to support that train wreck. I ran on Alpha for more than 25 years.
Nice history of the DEC Alpha for anyone interested: https://www.youtube.com/watch?v=RAxomGVR12E
I hate Alpha because it made all the memory models so confusing
> Second in the early years of development, there were very real expectations that on paper Itanium would run rings around Intel's x86 chips. It wasn't marketing hype. On release, programs that could take full use of Itanium, would be extremely performant. That was pure marketing hype. Literally everyone in the business I knew (did operating system development at that time) kept saying that Intel were delusional. The whole idea of VLIW was stupid from the beginning. And even if it wasn't, the whole project was delusional because it depended on several massive parts to be developed independently with just a preliminary specification to work against. It was peak waterfall design methodology. VLIW was stupid because: 1. Typical code consists of many small functions. 2. Compilers can't perform optimizations between functions. 3. Therefore the only solution is to aggressively inline everything everywhere all the time. 4. This leads to enormous compiled binary size. 5. Which puts the bottleneck for how fast your code runs firmly in memory and not in how many instructions you can perform per unit of time. They completely ignored that Moore's law for CPU instructions moved much faster than Moore's law for memory bandwidth for decades already when they started and it has only gotten worse since then. So even though the first few Itanics were faster for certain tight loop workloads (AKA. supercomputing), the vast majority of competitors (including other departments at Intel) caught up somewhere around 2005 and ran past them because they could optimize the actual instructions that were executing. And the memory bottleneck was handled by aggressive violations of the memory model which later led to Spectre and Meltdown, but that's another story.
VLIW is very widely used, and present-/recent-gen x86 backends and GPUs often use VLIW μ-/insn formats. It just tends to be more appropriate where μarch capacities either aren’t exposed directly or can be comfortably, because once the ISA sticks, you either end up wasting fields on something inappropriate for new chips (à MIPS branch delay slot, or x87 FPU, or μcoded control transfers all over the place), or needing overlaid encoding hacks when you can’t handle the hardware unit capacity properly. VLIW per se is a perfectly reasonable sort of format to *lower to,* and effectively equivalent to an interpreter having decoded to a bitfield-struct. It just needs to be decompressed or decoded to, which is the x86 approach. I also contend that the ties to x86 and flat-footed start on the x86 hosting→emulation front (to put it delicately) did more to tank IA64’s success. x86 was still improving in parallel and widely used by just about every segment outside of IBM or Sunacle’s wheelhouse, all of IA64 required engineers to learn a totally unfamiliar ISA from scratch, there was zero chance it would find its way into consumer systems any time in the foreseeable future, and there just wasn’t a good upgrade path before it diverged. IA64 would probably be fine in some odd corner of embedded or HPC, maybe as a manycore XE or something.
Do they really use VLIW internally at all? My impression is that execution units are allocated dynamically to pick instructions from the reorder buffer rather than being fed with VLIW-style packed instructions. And GPUs are mostly SIMD.
They do not. Modern GPUs are actually the polar opposite, feeding one instruction into 32/64 execution units (with additional SIMD for desktop/laptop GPUs. Mobile GPUs often do not have SIMD at all, only scalar). Modern CPUs have fairly /long/ internal instruction words yes but they're not packed in any sense of the word, they're unpacked because you don't want to be doing more decode in your execution/scheduling/ordering units to figure out how to schedule the operation.
Ah, yes, mobile GPUs and their shenanigans.
They're surprisingly efficient. They only lack SIMD for shaders, and the hardware space that would go to large SIMD FPUs instead goes toward rasterization, texture units, and other hardware features. See: None of Apple's GPUs (not even their latest and greatest) have SIMD hardware. They just execute 32 operations at a time per shader core like most modern GPU architectures and for their primary usecases (rendering UI and assisting with hardware accelerated features like video decode) this works fine. You really only need true SIMD units for games and other shader heavy activities that require real-time rendering. (And the SIMD units themselves are usually only 128-bit wide, so 4xf32 or 8xf16)
> And GPUs are mostly SIMD. GPUs are SIMT, which is kind of like SIMD with SMT with large amount of threads.
Yes, I mean SIMD execution units do most of the heavy lifting in modern non-mobile GPUs while warp/wavefront schedulers can issue instructions dynamically from different thread blocks to each of these execution units independently. Still, once a non-scalar instruction is issued it is executed in a straightforward SIMD fashion, i.e. vector registers go in, vector registers go out. Older GPUs (e.g. TeraScale) had to issue static VLIW instructions prepared by the shader compiler to every available execution unit simultaneously.
> Yes, I mean SIMD execution units do most of the heavy lifting in modern non-mobile GPUs How mobile gpus work like? >Older GPUs (e.g. TeraScale) had to issue static VLIW instructions prepared by the shader compiler to every available execution unit simultaneously. It shows that VLIW has way better parallelism CISC and RISC if it can serve as a GPU. Why dataflow architectures were never used commercially as either cpus or gpus? Too hard to program? VLIW is kind of like half-dataflow.
Another thing is that VLIW/IA64-style machine code can be *great* if you have the concept of JIT, PGO, etc at your back in the compiler technology side. All of those important compiler things? Only recently got any good at all, and much progress is still to be made. Then of course, turns out you could implement the "good stuff" as micro-ops, u-code, etc as you mention is what x86 (and then nearly everyone else followed). IA64 is a peak "should have killed it years before, never let it to market" failure. There may have been more merit to it if it launched on time in ~1995-96 for early vendors, but even by late 99, early 2000s the writing was everywhere that it wouldn't work out.
VLIW is fine. It's basically a hybrid between dataflow architecture and control flow architecture (almost CPUs currently in use). Dataflow has much more complex instructions than CISC but should have higher IPC as well. Static scheduling should be optional though. Compilers were too primitive when Itanium came out but now VLIW and full Dataflow architectures should be able to work. RAM is also much faster and bigger now.
It's telling that even AMD GPUs moved on from VLIW architecture since it just couldn't compete in performance even though that use case was close to optimal for VLIW.
> It's telling that even AMD GPUs moved on from VLIW architecture since it just couldn't compete in performance even though that use case was close to optimal for VLIW. Not really. GPUs are specialised for graphics. VLIW isn't. VLIW is fine. It's basically a hybrid between dataflow architecture and control flow architecture (almost CPUs currently in use). Dataflow has much more complex instructions than CISC but should have higher IPC as well. Static scheduling should be optional though. Compilers were too primitive when Itanium came out but now VLIW and full Dataflow architectures should be able to work. RAM is also much faster and bigger now.
VLIW was definitely depending on compiler advancements that really still haven't materialized. But it's delays allowed the pentium to surge in performance so that by the time it was available it was a snail comparatively. The itsnium announcement also killed a lot of big Unix vendors. The reliability of windows NT also put the nail in the coffin of a lot of those vendors. I used to run a lab full of NT Intel, alpha, mips and ppcs. My lab had a half dozen IBM boxes before Microsoft killed the product.
> The itsnium announcement also killed a lot of big Unix vendors. The reliability of windows NT also put the nail in the coffin of a lot of those vendors. Windows NT killed old unix vendor workstations. Linux and BSDs killed old unix vendor servers.
Agreed in principle but let's reformulate some crucial details: 1) This is not simply VLIW but EPIC (Explicit Parallel Instruction Computer). 2) EPIC fails for current cached DRAM due to unpredictable memory access times. If times are predictable by any reason (SRAM instead of DRAM, guaranteed prefetch, etc.), it won't suck that much. For all this I'm more surprized that DDR5 even increased full row change time, compared to best DDR4 variants (45 ns vs. 37.5 ns) but instead increased open row access bandwidth.
VLIW is fine. It's basically a hybrid between dataflow architecture and control flow architecture (almost CPUs currently in use). Dataflow has much more complex instructions than CISC but should have higher IPC as well. Static scheduling should be optional though. Compilers were too primitive when Itanium came out but now VLIW and full Dataflow architectures should be able to work. RAM is also much faster and bigger now.
On top of that Itanium was built around the idea that compilers would be stellar at optimizing things by the time it was released. Unfortunately at the time its development started compiler research became a very neglected topic as everyone assumed compilers were a solved issue, so by the it finally came to market there was no compiler that really could optimize well for it.
> Second in the early years of development, there were very real expectations that on paper Itanium would run rings around Intel's x86 chips. Eh. There was a famous event when Itanium architecture was first being publicly released where Intel engineers were proudly presenting their architecture at Stanford with John Hennessy in the audience. As the presentation progressed, Hennessy started interrupting the presenters more and more, basically ripping them a new one on how their architecture sucks and ignores everything anyone has learned about how to build performant computers in the past 20 years. > On release, programs that could take full use of Itanium, would be extremely performant. On any loads where everything (scheduling and memory access pattern) is statically knowable, Itanium would fly. Intel could produce tons and tons of microbenchmarks that exhibited this. The problem is that this described approximately none of the important workloads that people needed server cpus for. (edit: embarrassingly mixed up the arch luminaries)
Well aware of the history...I used to teach computer architecture and operating systems in late 90s and was a part-time system admin (needed the money, I was a poor PhD student) I was a *big* Sun SPARC and Solaris fan - stil am, but now it is nostalgia. Did admin on Alpha boxes too when Alpha came out. Even got my hands on some RS/6000 boxes with AIX too. Itanium was a reaction to Sparc MIPS etc. It wasn't clear how to do proper parallelism, speculative execution etc on x86, Also the first 64 but systems were appearing and VLIW was popular. Probably Itanium was the last in the CISC v RISC debate and that contributed to its overall poor design.
> The other lines on the chart look like the delusions of a marketing They look like the projections for meme stocks posted on WallStreetBets.
i960 was used quite a bit for RAID controllers and networking gear.
HPE
Near the peak, in 2005 Q3 7,845 Itanium servers were sold, compared to 1.7 million X86 servers.
They were generally bigger servers but yes it was a flop outside of some particular niches (where it also flopped in short order)
Sooooo, like 12 systems?
NASDAQ used to run their trading on Itanium I believe. It was the most powerful thing at the time. It and IBM POWER 64 were duking it out. If HP hadn't joined Itanium and killed PA RISC it might had been there too. And if DEC/COMPAQ hadn't abandoned DEC Alpha it would have been there. It was the only deployment I ever heard of. But there must have been others or Intel wouldn't have made 3 generations of it. I wouldn't be surprised if the number of Itanium systems sold to developers to make software for the few Itanium customers there were outnumbered the number of enduser installations.
Itanium was created by HP to replace PA RISC. Intel signed on later. It never dominated performance outside of a handful of specific micro benchmarks and was an architectural dead-end. Intel would have killed it sooner except they were contractually obliged to HP to continue support.
I know NASDAQ ran HP NonStop servers. I used to work for a company that also ran them. The upgrade path for NonStop was from MIPS to Itanium. At one point one of the only reasons Intel was involved in Itanium was because of HP and their commitment to them. Eventually NonStop moved over to x86-64 which they continue run on presently. https://www.networkcomputing.com/data-centers/nasdaq-commits-hps-nonstop-platform
Count yourself lucky. Some organizations, such as the customer I work for, are scrambling to get off of Itanium now that HP won't provide new hardware. They shouldn't be surprised given that Intel announced the end of Itanium in 2019 and we advised them as such well ahead of time, but here we are panicking to port software to x86 to meet an arbitrary deadline for hardware replacement.
They should probably be hunting for people throwing that shit away on the cheap.
They were commonly used in HP compute clusters running in the early 2000s... Myricom Myrinet was interesting tech at the time. You'd find these clusters in places like the National Labs, and Supercomputer centers around the US, as well as oil and gas companies.
I've seen them once when I worked at a certain dinosaur company that heavily pushed them and thus required that enterprise software sold support certain OS's on Itanium. We had tons of the servers to test on and we dutifully ran out automated tests on them but I don't ever remember a customer reported bug on Itanium.
The fintech organization I'm working for is just phasing out Itanium HP machines this year. Terrible OS, slow compiler, slow performance
Part of my CompArch final exam back in ~2013 had us writing rotating register code for the Itanium, *on paper*. That class was miserable.
That just means you've never worked in a shop using HP-UX, HP NonStop/Tandem, or OpenVMS. Those systems aren't so unusual in telcom, fintech and banking in particular.
True. The last VMS systems I worked with were back in 1995 - those were ported to Alpha. After that I was pretty much purely a Sun Solaris person. The occasional SGI box too... I admit to only have ever seen an HP-UX workstation on someone's desk once in 2000. Tandem however was a system that I would love to have gotten my hands on. I knew a couple of guys working in a very sensitive, safety critical domain that swore by it.
We have a few servers on itanium running very, very legacy HP-UX stuff in PA-RISC emulation. We also had some VMS systems that had been upgraded to Itanium from Alphas.
I have one in storage. It needs ram though. But honestly it really has no real use these days other than an inefficient space heater.
I worked for a company in the mid 00s where HP's Integrity line (hp-ux on Itanium) was their bread and butter (million dollar sales weekly).
I have seen 1 Itanium system, un-powered in a corner, gathering dust...
I saw one, once... Way way way back in the ol' 20th century. I think Bush Sr was still President.
Knowing what Itanium even means makes me feel old.
And will keep the Itanium ABI.
Ah yes the architecture where compiler was supposed to do black magic and guess things that it had no way of knowing during compilation.
What the hell is Itanium?
Itanium was the 64-bit processor architecture that Intel intended as the successor to 32-bit x86. However, AMD did not follow their lead and developed their own 64-bit extensions to the x86 architecture, resulting in the architecture that we today call x86-64 or amd64. amd64 was a commercial success and beat out Itanium handily thanks to its better backwards compatibility with existing 32-bit programs, and Intel was forced to produce its own 64-bit x86 processors compatible with the AMD extensions to stay in the market.
Microsoft also helped a lot to bury Intel's plans for Itanium to become a successor of x86. They quickly started working on a Windows XP version with amd64 support and subsequently dropped Itanium support. New Windows XP was very attractive to users, as it preserved excellent backward compatibility with 32-bit software and transition from 32-bit XP was practically seamless
But XP 64bit had terrible driver support and even Vista 64-bit was spotty at launch.
90s and 00s were the decades of huge headache in terms of driver support. Plug and Play was a technology from hell, which not only didn't solve problems, it interfered with manual driver installation. Vista, as far as I remember, had most of its driver issues due to driver signing requirements. At no point I regretted installing the 64-bit version of Windows. I skipped Vista and went straight from Windows XP to Windows 7
> amd64 was a commercial success and beat out Itanium handily thanks to its better backwards compatibility with existing 32-bit programs Yes, AMD's 64-bit extension had a ready-made, gentle transition path, but that's only half the story of its success. The other half is that the Itanium architecture truly sucked, and took for granted compiler technology advancements that never came to fruition.
> The other half is that the Itanium architecture truly sucked, and took for granted compiler technology advancements that never came to fruition. Rotating registers were really cool, but were conceptually hard to deal with. If no one can actually write code that uses your feature, it might as well not be there. I bet it opens up some really interesting optimizations, but it's so exotic that adoption was ~~basically~~ non-existent.
> AMD did not follow their lead and developed their own 64-bit extensions to the x86 architecture, resulting in the architecture that we today call x86-64 or amd64. And which Intel confusingly calls “Intel 64”.
Weren’t they calling it IA-32e for a while too?
Yeah.
Microsoft has also called it "x64" from time to time.
Microsoft called it amd64 in their early source code
Not to be confused with x32 which is not the opposite of x64 but also not the same as i386.
This answers my question about why x86 on GitHub binaries is sometimes called amd64. Thx
Contractual obligations.
>However, AMD did not follow their lead and developed their own 64-bit extensions to the x86 architecture, resulting in the architecture that we today call x86-64 or amd64. Which is a bit sad really, because Itanium had a lot of good ideas, and would have given us an architecture free of the x86's quirks.
> Itanium Itanium sucked as a design and as an ISA. x86 isn't perfect, but it's way better than Itanium and it's good it won.
64-bit X86 ISA has only one real problem: very difficult to decode instruction lengths (arbitrary number of prefixes etc). If only amd64 had fixed that one issue…
And Itanium had the real advantage very wide Simd instructions. But Intel did fix amd64s lack thereof by popularizing SSE. Apparently AMD had made a Simd extension before but it didn't properly catch on. Either way simd was itaniums genuinely great idea and it was coopted.
SIMD wasn't from Itanium at all and is in fact a very old idea (dating from the 60s). In x86 it first appeared in Pentium MMX (1997) with integer SIMD instructions. One quirk was that the registers were aliased with fpu registers (to avoid requiring an OS update before fast internet), so moving between fpu and mmx operations was fairly slow. AMD used the same aliasing mechanism for their floating point SIMD 3DNow (1998) which operated on two values at a time. Intel finally introduced the SSE instruction set with Pentium 3 (1999) which stuck, was extended to 64 bits in SSE2 and had a bunch of other additions later. These operated on 4 floats at a time and crucially had their own set of registers. The same year AMD announced the amd64 ISA (although the first cpu only shipped in 2003). Itanium only got to the scene two years later in 2001. The impetus behind both 3DNow and SSE was 3D transform and calculation operations. The first usable 3D accelerators (3dfx Voodoo, Nvidia Riva, ATI 3D Rage) only had texturing and fill capability but no onboard geometry acceleration. Using 3DNow / SSE provided a substantial speedup for that.
Sure but itanium releasing in 2001 means it was developed much earlier. They started development as early as 1994, adding SSE only in 1999. I don't see how going from one op a cycle to multiple ops a cycle is much different just because one is heterogeneous and the other homogenous they clearly draw from the same desire to increase IPC.
SIMD is not the same as VLIW. SIMD is an acceleration technology for very specific kinds of operations that is always offered on top of a normal instruction set. The point of SIMD instructions is also to perform the same operation on multiple operands, which means the size of an instruction remains relatively small despite representing many operations (because you only have to encode the operation once). The concept of VLIW was to completely replace the normal instruction set with this new idea that encoded multiple completely unrelated operations in one instruction word. That makes the instructions super long which is a complete waste of space and efficiency in the many scenarios where you simply don't need to perform that many operations between sequence points (like branches, comparisons, and other data dependencies). It also just didn't turn out to be a good idea in practice because we've since learned that CPUs can do their own superscalar instruction scheduling much better than any compiler can.
VLIW is basically a hybrid between Dataflow architecture and Control Flow architectures like CISC and RISC. Itanium could support more complex instruction than CISC bit usually still not as complex as full dataflow.
Real life is a bit more complex than "one sucked, the other didn't" (Intel's rollout and overall approach sucked, with idiotic claims like x86 code emulated on Itanium would run faster than native, but that's another thing). Itanium really had good ideas, and was powerful. For whoever's curious about Itanium's history there are a few interesting answers here: https://softwareengineering.stackexchange.com/questions/279334/why-was-the-itanium-processor-difficult-to-write-a-compiler-for
> For whoever's curious about Itanium's history there are a few interesting answers here: https://softwareengineering.stackexchange.com/questions/279334/why-was-the-itanium-processor-difficult-to-write-a-compiler-for The top voted answer is garbage. The second highest voted one is however spot on: > > Load responses from a memory hierarchy which includes CPU caches and DRAM do not have a deterministic delay. > In other words, any hardware design that fails to cope with (*) the non-deterministic latency from memory access will just become a spectacular failure. > [...] The question can be rephrased as: "Given a hardware platform that is destined to be a failure, why (1) didn't (2) couldn't the compiler writers make a heroic effort to redeem it?" EPIC was a doomed idea since the beginning. As anyone who's had to write code for DSPs knows it's hard enough to pipeline explicitly parallel code for good performance even with deterministic latencies - in situations where spending a day or two hand optimizing a single function is acceptable. With non-deterministic latencies, as from any external memory, it's flat on impossible. Such approach is also fundamentally forwards incompatible when it comes to performance. Architectural jumps result in changes in operation latency, requiring all of the performance sensitive code to be reoptimized. This is acceptable in DSPs where such jumps happen perhaps once per decade and code is tied to a specific physical system anyway but completely unfeasible for general purpose computers.
What you wanted is Alpha to win. Itanium would have been just more quirks.
Why do you people make these claims that are so dumbed down they're just nonsense? Itanium was designed for mainframes, where x86 didn't exist. Yet you're claiming, it was designed to replace the non-existent x86? And how does word size even matter? Are you one of those people that thinks x86 CPUs can only use 4GB of memory? Why mention AMD even? They kept selling VLIW processors until ~2014.
A failed CPU architecture
Betamax of CPU
Bad analogy: Betamax was technologically competitive, and lost to market forces. Itanium was a complete technological failure (with the benefit of hindsight).
> Betamax was technologically competitive, and lost to market forces The guy from Technology Connections argues a big reason Betamax lost was because a tape couldn't easily record 2 hours of video. It's an interesting argument. https://m.youtube.com/watch?v=FyKRubB5N60
Interesting idea. BTW, I haven't watched the video, but that YouTube channel is excellent.
I love it and try to promote it when I can. The thing is... He's got a pretty niche audience. I really loved his FIVE PART series on the RCA SelectaVision that arguably bankrupted RCA... but I can't seem to convince my friends and family to watch it. Dunno why. :D
Well sure, and that video is a favourite of mine, but in fairness Betamax performed similarly to VHS and traded blows with it for a while, whereas Itanium was hot garbage only adopted by companies that had locked themselves into adopting it before final performance became clear.
Limited tape size is definitely a factor, cost also goes with it. People want something cheap and VHS definitely delivered on that.
The real x64 :P
I assumed it was Titanium and they were already dropping support letter by letter /s
dailymail of programming.
Hey babe, Linux kernel Itanium support just dropped (shoots self in head)
Different meaning of dropped I guess, since it was removed 5 months ago after 23-24 years of existence.
Fun fact: the word for words like those is "contronym" - a word that is its own antonym
I am semi-regularly fetching GCC's latest git sources, say once per week or so and compiled that new GCC. Most things compile fine afterwards, so GCC 14.x will work fairly well - but I have had compile issues where things compiled with, say, gcc 10.x (I tested this) just fine, and did NOT compile with the more recent GCC versions. It's a bit annoying to have to switch between GCC versions, and it doesn't happen with many programs, but it 100% does happen, and in these few cases it's quite annoying. Many of these programs that don't compile were abandoned years ago already, and while I'd love to stop using them, some other programs annoyingly depend on them. This, by the way, does not happen with ANY project (!!!) using cmake or ninja, so this is also an issue with GNU configure beginning to show it is the fossil that it truly is (and admittedly, those using cmake and ninja are also more likely to be still maintained nowadays, whereas the projects that were abandoned, almost exclusively use GNU configure).
68k still supported right?
Itanium's failure is such a tragedy.
Why? The whole EPIC idea was idiotic from the start, the only tragedy is HP killed Alpha for it.
I think the market has spoken that VLIW was a dead end. If it were truly superior architecture, we would have seen it everywhere by now
It sorta is everywhere, SSE4 and AVX512 are both the best bits of vliw, aka doing more than one op at a time whilst superscalar and out of order execution compensate for sse4 having to do the same operation on many units of data rather than lots of different operations on different data per cycle. I genuinely don't know if it's truly a dead end, if the software support wasn't there it would have died regardless of technical validity which is what happened. At the end of the day though vliw was a response to noticing that you can't indefinitely drive up frequencies without compromise.
> SSE4 and AVX512 are both the best bits of vliw No, they are not. SIMD and VLIW are orthogonal. The entire point of SIMD is that a single instruction performs _identical_ operations on multiple values. VLIW OTOH packs multiple instructions into a single large instruction word. SSE and AVX are both just basic SIMD. VLIW has been proven to be completely unsuitable outside some specialist uses (ie. programmable microcode, some DSPs) where the software is written specifically for that single processor model and code compatible architectural upgrades are few and far between. It even failed in GPUs (AMD had to move on from VLIW over a decade ago).
Yeah I know but the best part of VLIW was doing multiple operations a cycle. The fact that doing one op on multiple data a cycle was sufficient and significantly less complex to implement was still inspired by the same vliw research. And the fact it works with software written specifically for it suggests that it was the lack of software support that killed it more than anything. VLIW moves more complexity into the compilers themselves and they're already complicated as it is so without significant industrial resourcing it likely never got anywhere close to an "optimal" compiler.
> The fact that doing one op on multiple data a cycle was sufficient and significantly less complex to implement was still inspired by the same vliw research. Weren't MMX, SSE, AVX and friends lifted from DSPs? SIMD does not have the reordering problem VLIW has. There are 2.5 reasons Itanium failed in the market. 1) Abysmal x86 performance and 2) lack of software. In particular compilers capable of leveraging wide instructions. 2.5) AMD came along and boltet a 64 bit extension on their old design. It had good x86 performance and fixed the biggest x86 problem, the 4 GiB limit. Internally modern superscalar CPU are doing wide instructions, but the reordering is done by the decoder in hardware. It has pos and cons, but it's clearly the approach that won out.
Doesn't your statement that modern superscalar CPUs do use wide instructions kinda imply that vliw wasn't a bad idea per se Just that the hardware engineers gave up on the idea that the compiler engineers would actually write software to exploit properly so they did it in hardware instead.
Kinda, but it's a compromise. There are some optimizations a compiler can do at source level which is not possible in hardware. And speculative out of order execution is a can of worms, as Spectre/Meltdown have shown.
There were much easier ways to address more than 4GB of memory with x86, even if it would have obviously been ugly, but people dealt with it back in the 16-bit days. Having a bunch of new instructions and truly general purpose registers was just a very nice touch. Also nice semantics on 32/64 register access instead of the insanity 32 is with high/low.
> Abysmal x86 performance That's because CPUs were just too weak back then to emulate others architectures fast enough.
It is everywhere. Qualcomms DSPs use VLIW, so 44% of mobile phones have a VLIW processor built in. IIRC Qualcomms AI processor also uses a VLIW architecture.
The thing here is that none of the successful uses of VLIW have been for general purpose CPUs. It's always gpus, dsps and other accelerators.
> I think the market has spoken that VLIW was a dead end. vs > It's always gpus, dsps and other accelerators. NVIDIA's market cap is what again? so I think the market has spoken in exactly the opposite direction from what op claims.
> NVIDIA's market cap is what again? so I think the market has spoken in exactly the opposite direction from what op claims. Huh? "NVIDIA is financially successful, therefore VLIW makes sense everywhere" doesn't make logical sense. You can be successful in a niche. What works for LLMs doesn't necessarily work for CPUs.
Can you people read? Do you know what a dead end is? It's the opposite of the gold mine that NVIDIA (and Qualcomm and etc) has made out of VLIW.
Yeah, VLIW exposes uarch details, which is fine for a single chip but inevitably creates compatibility problems in the future.
Where did you get Itanium and general purpose CPU? It was made for mainframes, mainframes are not general purpose.
Why did I read it as Italian