It's funny thinking back to the hype cycle of Itanium back in the heady days where performance was doubling every year, desktop was king and this was the future.
Turns out it was more like IBM's MCA / PS2 rather than the future.
Compatibility and ubiquity wins. As nearly always.
> The failure of this chip to do anything more than exist as a niche processor sealed the fate of Intel—and perhaps the entire industry, since from 1997 to 2001 everyone waited for the messiah of chips to take us all to the next level.
> It did that all right. It took us to the next level. But we didn't know that the next level was below us, not above. The next level was the basement, in fact. Hopefully Intel won't come up with any more bright ideas like the Itanium. We can't afford to excavate another level down.
In the end it was market forces that did it in. Making new chips was (still is!) exponentially more expensive for each generation, and at the same time mass market chips were getting better and better while they could amortize the NRE costs over zillions of chips sold, eating the market from below. And other RISC competitors (and IA-64) were attacking from the sides. DEC just didn't have the customer base or depth of pockets to fund Alpha development. That it was Itanium that ultimately delivered the coup de grace was but the final insult.
In my limited understanding two factors contributed significantly to Alpha failing. Business-wise, DEC and Ken Olesen were stuck in an old minicomputer mentality and wasn't sufficiently able or willing to "let it loose" and let it take over the market with DEC as the CPU supplier. Technically, Alpha development was taking longer and longer and the schedule slips got worse and worse.
It wasn't the technical side that caused the schedule slips. It was constant competition with other aspects of the business, especially the VAX lineup. The VAX 9000 in particular was a $3 billion money pit that didn't make back even 25% of it's development costs and was repeatedly chosen over development of prism and later alpha. Even when it came down to the embarrassingly fast NVAX chip vs the even faster Alhpa, DEC still couldn't get the story straight and lost valuable VAX customers when they could have offered a faster VAX and an upgrade path to Alpha.
The Prism/Alpha project was one long series of disasters. Prism was delayed because the spec kept changing and the architecture had to run on VLSI and ECL - which was already a huge mistake. There was also resistance from the VAX partisans.
So when samples arrived they were 2-3 years later than they should have been and MIPs had made some headway in the same space.
DEC - actually Bob Supnik - decided that even though Prism was the better arch, MIPS products would bring in revenue more quickly.
Which was true. But... then Prism was killed, which led to a mass walkout. The remains were resurrected a year later with some updates as Alpha. But by then it was too late for that particular market.
Prism was a solid arch - some quirks, but nothing unworkable. And very, very fast.
But it was a workstation-grade processor, not a mainstream PC-grade processor.
DEC completely failed to understand the PC market, and it's not obvious what would have happened if Prism had survived. IMO it would have gone the way of MIPS anyway, because the workstation market was already being squeezed hard, and the PC and Mac markets had already made their choices.
It might have had a good run against SPARC for a decade or so, but that would have been it.
It wasn't the cost of alpha. It was the bleeding all through the rest of the company.
DEC's terminals? killed by PCs. The VAX lineup? killed by RISC chips, and the VAX 9000 consumed a huge chunk of their cash reserves before embarrassingly being rendered obsolete by their own NVAX.
This was a time of change from minicomputers to microcomputers and DEC made costly decision after costly decision. They kept selling off profitable "non-core" portions of the business that in the process incurred a loss.
It is a great representation of the average article written about Itanium. I think the register made most of its revenue from articles about Itanium, where the authors had no clue about what they were talking about.
Not defending Itanium. But the average article on computer architecture has been garbage for decades now, it's fascinating.
As someone working in that space at that time, IA64 was still losing to Sparc64 the entire time. We would do big boxes on Solaris and replace older Sun boxes with ia32 Pentium Pros. There wasn't really ever a point at which we thought "hm, RISC isn't working for us, we need VLIW" ...and we were an HP shop!!!
Sun was one of the few processor makers who were sceptical and decided to wait and see before cancelling plans for their architecture, and it's nice to hear that worked out for them for a bit before 64-bit x86 ate their lunch.
Of course, it's also possible that by that point Sun was already paralysed by infighting between various splinter groups, with no big bad DEC to fight against.
The irony being that Itanium is basically a SPARC64 on steroids; both wide, both used huge register windows, and both were in order. the only difference being that Itanium exposed a lot of the superscalar bits to the programmer. I still have no clue why an HP shop would be using Solaris boxes, alas...
Compatibility and ubiquity wins. As nearly always.
I’m not particularly confused about Intel’s perspective on compatibility: Even at the time, there were several examples of successful platform CPU transitions across architectural “full breaks”. Apple going from 68k to PowerPC is the closest analogy for Intel, and if the Itanium performance and software (compiler) story had played out as Intel envisioned they likely would have been fine.
But as for ubiquity, I’m befuddled. As far as I’ve been able to determine—having lived through it and followed many retrospective threads like this looking for new evidence—Intel had no plans on any useful timeline to turn Itanium into a (non-workstation) desktop or laptop chip. Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
> Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
I think it's the case that they wanted to believe that, because the other story, that all the major "big iron" companies would be absolutely and totally forever wrecked by stupid free Linux running on stupid cheap whiteboxes was simply too horrible to envision.
Data center computing being dominated by commodity Linux running on commodity x86 PC architecture—for which the best CPUs were not commodities, but rather made exclusively by Intel—was likely the best of all possible worlds for them!
Going back to at least the i432, Intel seems to have had a deep vein of “mainframe envy” in their culture and strategic thinking. It seems that somehow the market (and a bit of trailblazing into x86-64 by AMD) saved them from themselves.
"""
Intel's iAPX432 was intended to be Intel's major design for the 1980s. Unlike the 8086, which was designed the following year as a successor to the 8080, the iAPX 432 was a radical departure from Intel's previous designs meant for a different market niche...
Referred to as a "micromainframe", the iAPX 432 was designed to be programmed entirely in high-level languages.
"""
Folklore describes the 8086 as a stop-gap design, an extension of the popular (but tiny) 8080 CPU. The "real" design project at Intel was the i432, which supported object-oriented programming and was THE FUTURE OF ALL COMPUTING.
A cut-down version of the object oriented support was carried over into the x86 architecture, in its segmented memory model and page-description registers. You're welcome.
It was great for Intel - but it wasn't great for certain big manufacturers (dinosaurs) that they were courting.
I think they knew they could fall back on x86 if everything went wrong - but what they did NOT expect was x86-64 to just smash everything. That caught them on backfoot.
I remember the public roadmaps in tech magazines at the time, and Intel planned on keeping "consumer" market 32bit for longer time - then AMD dropped the Hammer ;>
Same company that completely missed the boat on mobile not that many years later. Intel have consistently made serious mistakes in their strategic direction. Fumbling 64bit, turning Apple down on mobile, missing GPU/AI.
They are basically just building a better version of the same product they were selling 20 years ago… so much opportunity missed here.
I think they're referring to the Core/Penryn series (the "direct" ancestor to modern Intel x86s).
But even that goes back to the P6->P5->486->386->286->8086->8088->8080->8008->CTC lineage of 50+yrs. It literally just cuts out the few years of the abandoned NetBurst architecture.
> Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
I can. The x86 hegemony was overpowering in the PC space but the moment you left that corner of the market we had a lot more ISA diversity then than in the following years. In a world that seemed to have no problem with Macs on PowerPC, PCs on x86, and workstations/servers on SPARC/MIPS/PA-RISC, just consolidating workstations and servers probably seemed reasonable. You can even see an analog in the way we've kept x86 on "real computers" while ARM has dominated mobile. IMHO the only reason it didn't work out is because workstations and servers merged with PCs.
Itanic was hype from the word go. Intel tried and failed twice to make "VLIW CPUs that rely on 'sufficiently smart' HLL compilers doing the right instruction packings" a thing before Itanium came along (iAPX 432 and i860). I think someone very high up at Intel was in love with the idea despite its repeated failures.
Alpha was clearly the future -- and Itanic ruined Alpha. We didn't even get to see it live on inside some other corporate sarlacc.
I do recall some discussion about combination of really bad code generation combined with some ridiculously bad design decisions (I think it might have been total lack of cache?)
The blog entry Revisiting the Intel 432[0] and the cited paper Performance Effects of Architectural
Complexity in the Intel 432[1] discuss the compiler issues.
> Compatibility and ubiquity wins. As nearly always.
In this case, that means AMD showing up with the first x86-compatible 64-bit CPUs killed Itanium dead. For big software projects already running on x86, there were 2 options:
- Port everything to a new architecture that only looked good in specific benchmarks, cross your fingers, and hope for the best.
- Keep running your code on new 64-bit CPUs that were backward compatible with your existing code, then recompile for 64-bit as you got around to it.
As a bonus, amd64/x86-64 CPUs were faster than the P4 chips that practically needed 3 phase power to boot up.
> Turns out it was more like IBM's MCA / PS2 rather than the future.
It was quite a bit worse than that. If you ignore the horror of IBM vendor lock-in, which in retrospect made the whole thing untenable, and the overpriced nature of the systems, MCA was a fine thing for its time. The PS/2s had some nice features. They were compatible with everyone's DOS and Windows stuff, even if IBM would have preferred you use OS/2, and so on.
Itanium was a piece of crap, even if you could somehow ignore the cost and lock-in.
> Compatibility and ubiquity wins. As nearly always.
I'm not sure that was Itanium's only problem. Intel's Itanium launch focused on a market that was not captured by the so-called "Wintel" monopoly: high performance servers. The software support needed in this market was relatively narrow. Nevertheless, it failed there too.
The biggest issue with Itanium is that the juice was never worth the squeeze. It was expensive. The cost to migrate your existing 64bit systems never made sense. So, you might ask, what about 32-bit shops that needed to make the leap to 64 bits? Well, by the time intel and its vendors started getting costs under control, the AMD Opteron hit the scene with commodity 64bit hardware that had the added benefit of full backwards compatibility. And that pretty much killed it.
On the one hand, I am not surprised -- at my workplace, we only ever had one Itanium system, an SGI Altix 3000-series computer. It was kind of niche even when we bought it, and core-for-core, the Itanium CPUs were slower than their competitors. What the SGI was really good at was MPI parallelism. I don't know how much of that was the CPU and how much was the overall system design of the Altix, which featured a pretty amazing interconnection fabric (CrayLink, I think?), and cache-coherency and a sophisticated memory model. But not all problems parallelized well, so the system ended up kind of being this weird outlier that was a good answer to some classes of problems, but you had to remember it existed.
On the other hand, it's a bit of a shame to formally, officially lose another option out of the computing ecosystem.
I've always wanted an Indy or an O2,but other than running the demos, I don't know what I'd do with them. Also, high-end kit is also interesting, but again, I kind of want an Altix (or Origin 2000/3000), or .AS/400 or a Tandem Cyclone.. just because it's neat.
Do you have anything specific you'd do with an Altix 3000?
>Do you have anything specific you'd do with an Altix 3000?
nope, I just like weird computers and distributed systems, itanium is possibly the weirdest CPU architecture that modern linux can run on, and SGI is an interesting part of computer history.
I've never used a Tandem (or as/400 or sgi) myself. Just find all of them interesting.
I assume Porting Linux to the pre-MIPS Tandem line would be a challenge.
The Proprietary CPU was 'stack based' and very different from x86. Also, I don't know if Tandem ever sold compilers to do the sort of 'low level' system stuff to port another OS..
I have various SGI machines and while they are cool, they are pretty much useless except for toying around on. And extremely noisy. The O2 is the only one that's usable like a normal PC, except the plastics tend to break during shipping.
The rackmount Tezros and Origin 350s sound like they belong at the airport.
I've had an Iris and an O2, and the sad fact is that your telephone is a faster computer than 100 O2's.
They're fun if you want to run the demos or load fsn and tell everyone in earshot "this is a Unix system! I know this!" But they're not even useful as X consoles to a Linux box these days, because of the compilation nightmare of getting recent network tools installed.
It's not a shame. IA64 did more harm than good for the humanity and the computing industry. It was a dead-end architecture that should have died sooner than it did. Hubris and inertia kept it going much longer than it should have, and delayed so much of other progress. I would say good riddance.
I am surprised that there was still a new processor in 2017. I would have guessed it died nearly 20 years earlier. (I have used computers since more than 10 years before the Itaniun came out, or if you count the year of their release, 30 years older ones. But I never came even close to any Itanium.)
Statistics and modeling are complicated, granted. But when your model diverges from reality 5 years in a row, perhaps you should just extrapolate the current line next time around.
(In the case of the Itanic, that would have been the line at 0. Still a better forecast than what they did!)
This makes their modeling errors even more egregious and embarrassing. If you know governments are subsidizing it, and there are no foreseeable plans to cut said subsidies, you would be a fool to not forecast growth.
The governments have to subsidize solar, so it can compete with government subsidized fossil fuels. You may be surprised to learn that global fossil fuel subsidies rose from $4.5 trillion in 2015 to $7 trillion in 2022.
In this situation I would assume that the political/internal pressures from the member companies and advisory board were dominating factors as opposed to the forecasters being total dummies. There must have been some reasons why it was not appealing to assume the growth could keep ramping like that. Because it’s an obviously insane forecast after the first few data points are in.
I'd love to hear someone chip in with what it takes to make a solar panel and the rate limiting factors.
E.g. if a solar panel factory (simplifying into a single entity) already exists, is there any reason not to run it at 100% production capacity? What consumables are used?
Silicon for solar panels has to be 99.999999 percent pure—six 9s after the decimal. Computer chips are even more demanding. Their silicon needs to be 99.99999999999 percent pure—eleven 9s.
How consumable-intensive is doped silicone production?
Afaik, it's more strict metallurgy (materialurgy?): temperature, time, some physical process.
Point being, I'd be curious on the actual cost of material inputs, if the price of solar panels crashes. How low can they go... and still be worth making?
> if the price of solar panels crashes. How low can they go... and still be worth making?
Boules are very storable, so it’s the financials of pausing production and storing materials until the price (or new tech) makes it profitable. Not the most socially responsible thing to do in decarbonisation times, but done with aluminium and other energy intensive storables all the time.
They are running at full capacity. Chinese factories will produce more panels this year than what was the total world solar install 5 years ago. The problem today is not supply of solar but demand it faces similar problems as chip manufacturing as once new capacity is brought up the world needs time to train more workers as well produce equipment to use that capacity
Looked into getting solar panels last year and the problem wasn't getting the actual panels, but the hardware that let you integrate the panels to the electrical system. Spoke to several people who had had panels on their roof for months, but couldn't get the hardware that would let them connect them.
Depending on what you want, it might be very simple hardware, using panel provided DC for lighting and a 12V DC system and switching to utility provided AC when the sun isn’t providing enough power, all the way to house batteries and selling power back into the grid.
The rate limiting is basically factory capacity, yes. Simplified process:
- Czochralski purification of silicon to produce a "boule"
- saw boule into "wafers" (surprisingly important, see "reduced kerf diamond wire saw")
- wafers can be used for microchips, or doped into solar cells
- apply contacts to top face
- package into a panel with glass and aluminium frames
The "wafer" market is somewhat independent. Purification depends on the price of energy (it's very energy intensive). Better sawing reduces waste and increases wafers per boule.
More factories come online all the time. Panels themselves are now extremely cheap, and it's worth looking at "balance of system" (labour, permitting, frames and racks, inverters).
I believe market data firms track all the relevant info, although they don't necessarily give the resulting info away on the internet.
It seems like the World Energy Outlook report the fossil fuel industry gets a lot of airtime. In the 2018 report[1] most of the sections are dedicated to oil and gas topic and the section on renewables is very skeptical on the viability of renewables.
Based on the recent history of the Texas power grid, the skepticism is more than warranted. The cost per megawatt of capacity for renewables is lower than other sources, but the power only gets generated when the sun is shining or the wind is blowing, which means more reliable energy sources are priced out of being added to the grid.
Our most recent near-miss at a statewide outage happened because of unexpectedly low wind. It’s happening in Texas first because we have a smaller grid and it’s deregulated to the point where cheap but unreliable renewables can crowd out other sources of generation. The eastern and western grids will face the same problems in the long run the more and more renewables come to replace other sources of power.
That’s how the fossil fuel industry describes it, yes, but that’s just them trying to avoid competition. For example, the 2021 winter outages were caused by power plant operators not wanting to spend money making their plants more robust. During this summer’s heat dome, solar was reliable on days when gas, coal and nuclear power plants were offline due to the heat.
> That’s how the fossil fuel industry describes it, yes, but that’s just them trying to avoid competition.
Renewables, especially construction of new renewables, is a big, lucrative, growing business of its own. That’s actually a direct implication of the triumphant statistics people keep sharing about how much renewable power generation gets built out every year. So the “fossil fuel industry” is not unique in its vested interest to propagandize against its competition. And this incentive is only increased by the movement towards ESG in finance. But if we’re done accusing each other of being shills, let’s get to the substance of the matter at hand here.
> For example, the 2021 winter outages were caused by power plant operators not wanting to spend money making their plants more robust.
This included the renewables too, of course, along with the entire rest of the state’s infrastructure. But the near outage this summer was directly caused by low wind. There are probably issues with solar as well—heat, and cooling demand along with it, peak in the early evening just as sunlight starts to diminish—but usually wind manages to cover that gap. That doesn’t always happen though.
The near outage this summer was more accurately described as wind being low enough that it almost wasn't able to fill the gap caused by the gas, coal, and nuclear plants going offline. Unlike wind and solar those are quite heat sensitive so you can get nasty correlated failures at peak summer demand, especially if the same weather system causes any kind of interruption to the cooling water supply.
And, yes, renewables are becoming a big industry but it’s nowhere near as big as the fossil fuel industry and orders of magnitude less lavishly subsidized. Texas Republicans tried to ban wind and solar expansion because that party has been owned by the oil industry for decades and the renewable industry has nowhere near the same level of lobbying clout.
> The near outage this summer was more accurately described as wind being low enough that it almost wasn't able to fill the gap caused by the gas, coal, and nuclear plants going offline.
I can’t find any good source about your claim of thermal plants going offline in the September incident. ERCOT’s statements consistently blame the combination of high demand and low wind. The federal Department of Energy even issued an order authorizing Texas power plants to exceed normal emissions limits in such an emergency, which is inconsistent with your claim that they “go offline” in these conditions: https://www.ercot.com/about/legal/doe202c
> And, yes, renewables are becoming a big industry but it’s nowhere near as big as the fossil fuel industry and orders of magnitude less lavishly subsidized.
I thought we were done accusing each other of being shills. I’ll just point out that there’s significantly more propaganda in favor of renewable energy than in favor of natural gas or nuclear. But this is Hacker News and I am assuming good faith of you rather than accusing you of parroting talking points that were fed to you by Chinese photovoltaic manufacturers or annoying Swedish teenagers. And I am simply asking the same courtesy from you.
> Texas Republicans tried to ban wind and solar expansion because that party has been owned by the oil industry for decades
I think there is a good faith reason for such a policy. And while I do live in Texas and usually vote for Republicans, I am asking you to engage with me in good faith instead of calling me a shill. Are you capable of that or is the idea that someone can disagree with you about energy policy in good faith beyond your comprehension? Because you seem to be using this idea as a thought-terminating cliche.
Similarly, anyone get the feeling the forecast for Hydrogen uptake (as an alternative fuel) has more to do with a self-serving politically and commercially motivated hype train than an honest assessment of its effectiveness that then drives organic uptake?
There's a lesson here. Intel basically wanted to get away from x86 because it was licensed to AMD (and Cyrix) due to an earlier (and essentially unlimited) licensing agreement. In the late 90s, the likes of DEC, HP and Sun ruled the server and workstation space.
Intel wanted in on this space and didn't want AMD to be able to produce compatible parts so... enter EPIC [1]. The projections (as you point to) were wildly optimistic. Of course the whole thing was heavily delayed, produced in small volume, offered limited to no performance gain, required a ground up write of pretty much everything and was super expensive. What could go wrong?
What did AMD do? It just invented 64 bit extensions to x86 (ie x86-64). Was it ideal? No. You probably wouldn't design an instruction set and architecture this way if you were starting from nothing but you aren't starting from nothing. AMD released the wildly successful Opteron (and Athlon 64) and for 5-10 years completley ate Intel's lunch. Cheap parts, good performance, easy migration part, etc. Intel got to use these extensions by the same licensing agreement.
This coincided with the Gigahertz wars on the desktop front. From the Pentium for almost a decade Intel focused on Gigahertz and once thought they could run this up all the way to 10GHz+. We know how that went. Clock speed was a key marketing bullet point. AMD processors had higher IPC but that (at that time) was a harder sell.
About the time Opteron came out the Gigahertz wars were hitting the 3GHz barrier and Intel was stuck. At the same time their mobile parts used a completely different architecture. Thsi was Centrino with the Core Duo processors. These had much higher IPC (than Pentium lines) and more power efficiency. Some early enthusiasts constructed desktops from these mobile chips and the results were great.
Losing out to Opteron/Athlon and hitting the 3GHz barrier ultimately forced Intel to abandon their desktop architecture in favor of Centrino. Intel hung on as long as they could to milk some extra profit but eventually Core Duo was the future and this ultimately because the foundation for the Core processors we have today (but by now there have been many revisions). It might be more accurate to describe the Pentium years as the Netburst architecture years (IIRC).
But the lesson here is that a complete rewrite was an almost fatal mistake for Intel. It's almost always a mistake. You can't ignore what's there now and your desire to lock out competition doesn't necessarily translate to something customers actually want or need.
Is it? FAFAIK, the only places where ARM servers run is inside Amazon AWS and Microsoft Azure, and they design their own processors for that. The reason they chose ARM has to do with licensing, it has little to do with the characteristics of the processor architecture nor with processor performance.
This isn't my area of expertise, I'm sure others on here can rattle off more names, but at the very least Oracle has ARM servers available (the free ones are decent for hobby stuff) and Hetzner has ARM servers available
AWS and other cloud providers are major, major, major buyers. They have a lot of influence in the CPU market.
ARM is cheaper and the performance hit is smaller than the savings. For scalable workloads you can easily just run more ARM and save money. Also, a lot (lot) of workloads are memory or I/O bound so the performance hit is negligible. ARM has gotten pretty optimized in both the CPU architecture and the tooling thanks to mobile uses.
On AWS it’s like a 20-30% discount - effectively free money for services like RDS, ElastiCache, and often Lambda or even ECS where the effort is either minimal or extremely low.
I am not nearly as knowledgeable as many of the commenters here on the hardware, but I do have first hand experiences running ARM on production at scale.
What AWS offers and what Google offers are not even close: on AWS, our workloads actually perform better (as in, higher QPS/core, resulting in fewer pods/instances), in addition to being more cost effective (both in terms of per-instance price to begging with, and less instances in total, due to aforementioned higher QPS/core serving same amount of total requests). For the limited ARM offer from Google we tested, the performance is worse than equivalent x86 instances, in addition to no price incentives.
Exactly. The year of the ARM server has been predicted for more than 10 years. (Only topped by the year of the Linux desktop, but the latter has probably just been a joke most of the time anyway.)
The year of the linux desktop has been such a long prevailing joke that when the Linux desktop took over the education market nobody paid attention and people keep making YOTLD jokes.
I think about this from time to time. The Linux desktop is actually here in huge sectors of the market and no one cares. They displaced Apple in education due to expense and Apple finally hitting escape velocity (and thus can price their goods at whatever they want), so you see a ton of Ubuntu/Mint/etc desktop cheap machines in schools that run web browsers and OpenOffice (but mostly the former).
ARM server has a niche. If Gravitron/Ampere is good enough for your use case and you care about cost they seem like a good deal. AMD/Intel are trying to directly compete with them now with Genoa and Sapphire Rapids.
Microsoft is using Ampere chips and Ampere has some other clients like Oracle, Hetzner etc. you can use their servers inhouse too.
> with the characteristics of the processor architecture nor with processor performance.
Why did AMD introduce Genoa and Intel is developing equivalent products too? There is market for CPUs with a very high number of low-powers cores and it seems ARM had an advantage there. Even now the price per core (which are good enough for many applications) for Ampere/Gravitron cores is significantly lower.
My two cents: Open source displaced a lot of propriatery stacks.
When you're running commercial software at $$$$ per license, the customers basically have to stick to whatever hardware is explicitly supported. And the vendors are going to be narrow there. Fewer platforms keep support costs down, and prevent exposure to uncompetitive corners of the market. As long as $expensive_product is only officially supported for x86, nobody needs to know it's riotously unperformant on ARM in ways that will require wholesale rewrites to fix.
When it's all open stuff, nothing stops people from compiling it for ARM, RISC-V, and hell 65C816, letting the market choose which platform fits their needs best. For many audiences it might not be "maximum performance under cost-no-object hardware"; it might be "what's the cheapest way to serve a fixed N workload units per month, when you include the purchase cost, electricity cost, rack-space rental cost, etc."
As a second-order effect, I expect removing license cost from the equation also impacts the metrics people care about. When the software price is the dominant aspect of the bill, nobody's going to make much of a case of "we can save 55 of the annual cost up front by using cheaper good-enough hardware" or "we'll save 1% per month on the energy bill".
I’d also add automation becoming pervasive, especially after containers showed up. In the 90s, people bought relatively few expensive servers and ran a ton of stuff on them, almost always hand-rolled (yes, there wren a few crazies running BCFG, cfengine, etc. but that was uncommon outside of a few niches). That meant you couldn’t migrate easily since mapping out dependencies was non-trivial and your admins didn’t want / have time to deal with portability issues. As you mentioned, open source took a lot of that away (no more dealing with bizarre vendor compiler bugs or broken tool chains) and repeatable more isolated builds and deployments made it a lot more realistic to use a different server class where it saved money.
ARM servers can be made relatively cheaply (especially if you own an ARM server company like AWS), and they use less power (and cooling, I believe). So in a data center they're cheaper for the same functionality, kinda.
Not OP. And frankly speaking what he said should be common knowledge for those who lived through that period.
AArch64 and AMD64 has more in common than Itanium which is a bag of hurt from hardware to compiler.
ARM on Server actually saves money at the scale being deployed, while Itanium has zero cost advantage, and that is before adding the cost of software which was order of magnitude worst than any estimate had made at the time.
Most Server software operate on Open Source software. From Linux to Nginx, MySQL, Postgres, Memcache or Redis and tons and tons OSS. Which makes changes far easier than waiting for vendor to support AArch64.
AArach64 has a much bigger market to fine tune its software stack and toolchain from Smartphones. There are currently 4.5+Billion of Smartphone in uses, that is larger than all the x86 usage in the world. Compare that to IA64 /Itanium.
To add to this, the IA64 required specialist knowledge to get to run efficiently, given that you've just spent a huge amount on new hardware, you also had to port your stuff to take advantage of the new arch. From what I recall, x86 emulation was there, but just really slow.
So for a few HPC type things, it was an a leap forward, for everything else, it sucked.
It was like the arm based windows surface laptops a few years ago. Lots of promise, none of the software that you actually wanted.
When you looked at the opteron which was 64 bit, run faster, cheaper than the intel and could run vanilla 32bit apps without any changes faster than before, it was a no brainer.
None of this is my area of expertise. I’m just old enough to have lived through this era and remember what happened.
Many people don’t realize ARM can trace its origins back to the BBC Micro. For a variety of reasons it found a niche in low power applications, even 30+ years ago. ARM, the company, simply sells licenses without producing its own silicon. There’s concern now with it going public that it will seek revenue by jacking up licensing costs.
It’s mobile devices where ARM flourished and entered public consciousness. There used to be other platforms but they died off. Intel sold XScale years ago because of a lack of vision.
ARM processors got sufficiently powerful to be in servers and power efficiency became a big deal. Google really transformed this space with sub-1.1 PUEs when no one outside even believed that was possible. Performance per Watt became a really big deal.
Also, I’m not sure if this is entirely fair but I credit Apple with a lot of ARM’s success. They bought a company called PA Semi and pushed the envelope with what ARM can do. I think that may have been the best $400 million (IIRC) ever spent.
ARM allows anyone to license their cores and make their own CPUs. x86 has been limited to Intel and AMD. (before x86 took over there WAS a huge variety of CPU architectures in servers - Alpha, SPARC, HP-PA, POWER etc)
Starting a CPU company and selling CPUs to customers has always been difficult since you need to compete with other CPU packagers and Intel had the largest scale so could always put you out of business if you became a threat.
With the rise of big cloud server giants (AWS, Azure, Google), they can license the cores from ARM, build their own CPUs and cut out the middle-man. They are their own CPU customers so don't have to worry about building a market.
It's the rise of vertical integration from tech giants.
Architecture doesn’t matter as much in the cloud. If the backend servers are running storage, kv store, load balancers, etc it doesn’t matter if it is arm or x86. Arm is lower power so you can cram more compute into the same 480V chassis. If architecture doesn’t matter and density improves at lower cost , there’s an opportunity for arm to swoop in. If ampere executes to plan they will succeed where cavium failed.
Also “notoriously weak” memory model even as multithreading was taking off, and
> The processor may lose track of your LDx_L if you perform any memory access other than a matching STx_C, or if you perform a branch instruction, or if you trigger a trap (such as executing an emulated instruction), or if you execute more than 20 instructions after the LDx_L.
(LDxL and STxC are locked load and conditional store)
That is pretty standard for LL/SC instructions -- you'll find similar constraints on the Arm equivalent insns. In practice this doesn't matter because you only use them in a limited set of handcoded sequences to implement the atomic primitives you actually wanted, so you can always be sure that your LL/SC loop obeys the rules and makes forward progress.
1. Windows NT, which is the ancestor of modern Windows, was originally released on multiple platforms including Alpha and, I believe, MIPS; and
2. DEC, for awhile at least, had one of the most popular Web search engines: AltaVista. It wasn’t a commercial enterprise. It was mostly a technology demonstration for Alpha. For the time it was pretty good. No one at this time (the 1990s) thought there was a future in search engines. Many (including Yahoo) seemed to think curated directories were the future. Search engines were viewed as a solved problem, except by Larry Page and Sergei Brin who founded Google.
The highly underrated show “Halt and Catch Fire” covers this early era of computing really well and is worth watching.
Itanium was being defined around the same time the 1st Alphas came to market. By the time Itanium2 came out, it matched/surpassed the contemporary AXP parts.
FWIW the alpha design teams ended up cannibalized between AMD and Intel. The original Opteron and the first generations of Core i have a ton of AXP DNA in them, from a uarch standpoint. So in a sense, Intel and AMD did continue Alpha... sort of.
However. I feel that Alpha gets over fetishized on the internet sometimes. It was a clean arch, mainly because it was a clean 64bit design from the get go. But as far as uArch, it was pretty generic. Most of the uArch themes the AXP design teams used, which a lot of people think were native inventions to Alpha, came straight from industry/academia research, and plenty of other processors implemented them as well.
I worked on a large scale project that was itanium based and let me tell you, the compilers / software toolchains were an absolute dumpster fire. We were planning on being between 500 and 2000 processors in our cluster.
We used HP boxes and I want to say it was around 2002/2003 when this was going on. We were supposed to be a huge public showpiece client for both intel and HP. It… did not go very well. I remember the absolute defeated looks of the HP / Intel people when we pulled the plug and told them the discounts / free hardware still couldn’t justify the engineering efforts we had gone through for the last 18-24 months. This was right as opterons were coming out and that project jumped ship to them.
There were plenty of people sceptical of Itanium at the time, including many within Intel as well. I guess we all gave Intel some benefits of the doubt. But the great thing is that the whole industry learned a lot from it. Intel did too. It is just sad a lot of this learning experience within Engineering never got promoted to C-Level Management at Intel.
> There were plenty of people sceptical of Itanium at the time, including many within Intel as well
Credit especially goes to the people who stayed on the various x86 processor teams. Itanium’s single greatest source of failure was that successive Penguin generations undercut the advantage of x86 compatibility by adding the option of not migrating at all and still getting better performance. They probably saved the company but I doubt that got much praise at the time since it required acknowledging how badly the Itanium project had failed.
That's the tragedy behind it, since the whole premise on how Itanium was done was that compilers will be able to, eventually, any day now, optimize for it and then you'll see, just wait and then you'll see.. any day now!
The compilers worked just fine. Itanium was not even that particularly VLIWish, as the instruction carrier wasn't that particularly wide (up to 4 instructions)
All that Itanium was, at the end of the day, was an in-order PA-RISC/SPARC hybrid that exposed a lot of the superscalar innards to the programmer (compiler)
VLIW scheduling even back then wasn't as much of a mystery as the usenet and register flamewars implied. It really is pretty straightforward for a compiler to behave like an in-order superscalar scheduler. And since the compiler has a much global information about the instruction stream it can do much more optimizations and static ordering than a normal in-order HW superscalar scheduler alone.
Plus itanium had plenty of dynamic microarchitectural components to complement the static ordering done by the compiler and increase FU utilization.
If anything, things like predication and its adverse effect in power consumption had a much worse impact on itanium than the compilers.
What killed the itanium was just simple economics; its performance was fine (for the time, at least for itanium2). It's performance/price ratio, however, was not.
I believe you’re correct: the Pentium M in the original Centrino platform that became Core Duo was a Pentium 3 derivative (for laptops). I’d forgotten that.
Pentium 4 was heavily marketing driven, to win the Gigahertz war.
The fab side of Intel had a huge priority in setting early architectural themes. And some of the CMOs flows in lab, in mid 90s, were showing huge speed scaling, but they had very restrictive design rules and cell libraries. But with the payout of extreme GHz scaling.
From that point of view, the P4 made sense; a narrow architecture with very deep pipelines. Where each stage used the tiny datapaths between latches/registers those libraries supported. Netburst makes sense in terms of dealing with extremely deep out of order pipelines.
However, those processes never met the scaling roadmaps. While the power consumption scaled horribly, and things like thermal, leakage and variability started to become first order limiters.
Intel invested heavily in P4 and made the P4 pipeline really long which allowed for higher clocks.
So for Banias started with the P3 pipeline which was already short and added the microop fusion that I believe was introduced in P4. As well a cribbing a lot of other enhancements from Netburst.
It's been several years since I read up on it so I'm rust on all the details.
> your desire to lock out competition doesn't necessarily translate to something customers actually want or need
For the sake of humanity, we need to crowdfund a blimp with this quote that just flies back and forth between Cupertino/Mountain View and San Mateo for the next 5 or 10 years.
The lesson here is that AMD should not have been allowed access to Intel's IP, that is what allowed them in first place to undermine Intel's Itanium plans.
When I read about Itanium and iAPX 432, I can't help but think that Intel _isn't good at what they do_ and just lucked into he PC market by being cheap, and then riding to coattails of the Windows monopoly.
I can't wait for ARM to eat their lunch. And dinner.
When you read now or when you read at the time? I'm curious because context matters. Back in the 1990s when all this kicked off there was still a strong believe that RISC (vs CISC) was the future. There was a lot of circumstantial evidence to support this, most notably that the workstation and server spaces were dominated by RISC chips like Sparc, Alpha and MIPS.
I do believe that whoever drove the Centrino movement (from mobile originally to desktop) saved the company. They laid the foundation for Intel's next 15 years of success.
The original licensing agreement with AMD is an interesting part of Intel history too. Were that to happen today, it would probably be viewed as a disaster. In our modern era of short term corporate decision-making, it would probably be viewed negatively too.
But it led to Intel's complete dominance thanks to x86 for decades. It killed pretty much every other architecture (other than ARM). It's only in the last 5-10 years that dominance has really wavered.
Intel's big strength had always been their ability to fab chips at scale with low failure rate so the parts were hugely profitable. For decades the likes of AMD just didn't have that manufacturing capacity at the same scale and price. Intel led die-shrinking that was a huge driver to profits. It's only when they tried to move to 10nm that it all fell apart. Now TSMC has eaten their lunch. Intel is at risk of moving from being a first-party designer and fab of chips to producing third-party chips.
If someone woke up from a 20 year coma and you told them about Intel's market position and fate they would be shocked. That's how big of a fall from grace it's been. But that's largely on the fab side, not the design side. Only recently has the Core architecture really hit its limit where Intel CPUs consume too much power and run too hot to eke out the last ounce of power.
Itanium was a joint venture betwen HP and Intel. We can certainly look back now and say it was bad. I'm not convinced that determination was as easy at the time although it did have its critics.
LOL I am always fascinated by the soap opera scripts some people come up when it comes to stuff like this. Y'all be so let down if you knew how boring and much more pragmatic/economics driven the real stories, behind how these sausages are made, really are.
I had a manager that loved these things. He would shoe horn eBay one’s into any gambling backend he did. It was terrible, impossible to support and made accomplishing anything a chore.
Rust in peace.
With the possible exception of darwin, all the major operating systems are fairly careful about maintaining backwards compatibility. They've certainly been making noises about cutting support for a long time, but it's not surprising that they were very deliberate about doing it for real.
There is a difference between ongoing support and security fixes support. Oracle database dropped support itanium on Linux since version 11. I suggest others did this as well. Of course companies wanted to extend their HW lifetime as much as possible and switch from everyday production use to some secondary functions. But having this power hungry monsters online is a waste of money on my mind.
It took extra long because for various reasons it was the officially blessed architecture (specifically, HP-UX on Itanium) for running Oracle databases, leading to HP suing Oracle when the latter bought Sun and essentially declared HP-UX is to soon be EOL'd
As necessity is the mother of invention, Itanium did lead to UEFI, though
The Chicken and the Egg
The very first effort that is considered a direct ancestor of UEFI technology had a very specific tactical goal. In the course of 1997 people at Intel were working on how to boot computers based on the prospective Itanium® Processor
family...."
If I remember correctly, intel published a spec for the C++ ABI for uranium and GCC decided to use that on all architectures and OS to simplify the implementation. (This was at a time were GCC was still breaking frequently the ABI from version to version)
When llvm came out, it tried to be compatible with GCC.
As a result, given the prevalence of GCC, the Itanium ABI is now used almost everywhere. The notable exception is the Microsoft Visual compiler (MSVC) who still has its own API.
It's kind of funny. There are lots of architectures it killed (Alpha, PA-RISC, basically everything except SPARC because Sun was sceptical) but basically all of them have outlived it in the linux kernel.
It killed their manufacturing based on hype, where as they all established a firm install base before itanium ever got rolling, which has ensured they continue to be (halfheartedly) maintained.
Itanium was killed because unlike all the other architectures it puts a rather big burden on upstream developers due its complicated design (dual stack with growth into two directions, complicated compiler optimizations etc).
I keep wondering if it perhaps simply appeared too early. These days it feels as if almost everything is either open source or runs in some form of JIT compile VM, or both. Back then it was a huge problem to require code to be compiled not just to the general architecture but to the specific model to be fast.
But today? Moving some of the adaptions from the hardware scheduler to process lifetime persistence (as in JIT VM) or even into the software distribution infrastructure could be delightfully transparent.
It would probably be even worse today. Dynamically discovering ILP “just works” even as memory gets slower and slower and slower. A CPU today can execute hundreds of instructions and many predicted branches ahead of a slow load. It would be impossible to statically schedule this (you don’t know what will/won’t be in cache), and difficult to try and hoist all loads 100 instructions in advance especially when you take branching behavior into account.
GPUs have taken over much of the niche where these processors excel, number crunching where you have entirely pre-determined memory / compute access patterns.
For GPUs it only really works because the code is translated to the relevant instruction steam close to the time of executing, where you can afford to optimize in a highly uarch specific way. Whereas VLIW at the time of itanium never was in that position... It just doesn't compute for me how Intel thought this was a good plan. It's not like they didn't know that existing compiled binaries are going to continue being used on newer uarchs
The critical part was less VLIW, and more EPIC - the Explicit Parallel part. There were previous VLIW arches that didn't have issues with compilers, one of them afaik even formed backbone of many advanced optimizing compilers in 1990s because the vendor licensed the compiler tech to others.
While it might sound contrarian, Alpha actually deserved to die.
It guzzled power. This was the biggest problem, not solvable in its lifetime with its resources.
"According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible."
A lot of the Alpha engineers (including Keller) went to AMD and made the Athlon. The Athlon (K7/K8, specifically) was/is considered the spiritual successor to the 21264, by many. But yeah, many ended up looping around to PA Semi (again, including Keller).
In contributing to the death of the Alpha it also ensured the decline of Tru64 Unix and thereby stalled the development of AdvFS, which I definitely mourn.
Jim Keller has stated in at least one talk that DEC went bankrupt after Windows NT on Alpha kept crashing because they'd designed the Alpha with weak memory ordering and MS wouldn't implement the necessary memory barriers.
Itanic played part after Compaq buyout, where Compaq decided to bank all on Itanium sight unseen of actual usable parts, IIRC.
The end result was that they had to restart development of EV7 then restart its production again, because many, many ex-DEC customers didn't want to move to Itanium (customers running Tru64 mostly moved to Linux on amd64 or occasionally to other RISC vendors instead of dealing with HP-UX, whereas OpenVMS customers kept to Alphas which outperformed Itanium usually or moved off the platform completely, with stragglers now moving to amd64)
Alpha was on life support by the time Compaq bought DEC. AXP was literally one of the things that basically killed DEC.
By the time HP bought Compaq, AXP was on legacy mode. Plus Itanium was as much of an HP architecture as it was intel's, so it made no sense for HP to develop AXP further.
What killed Alpha and high performance MIPS (And eventually SPARC) was simple economics; their design costs grew faster than the revenue they generated.
I don't think many of the arm chair CPU experts really understand how expensive it is to design a high performance CPU core.
It would have helped a lot but they just needed to deliver. Back in the 90s I tried a couple of things using Intel’s compilers, and they helped but not enough to catch up even before you factored pricing in. I still am amazed that they were so set on licensing revenue that they let Itanium really suffer in benchmarks but it was always going to be ugly as long as they couldn’t ship hardware on time or with the promised numbers.
I think they way they do this is they post a message to lkml with a “speak now or forever hold your peace” message. I think they won’t remove functionality if anyone has a credible use.
If you’re ever on funky hardware and want to ensure continuing Linux compatibility, I guess it pays to subscribe.
That thing was such an abomination, good riddance. Not sure what the heck HP and intel were thinking, yeah, have the compiler do the work of ordering instructions particularly crafty so it wouldn't stall. HP had PA-RISC at the time, maybe it was an effort to kill Intel?
yeah, have the compiler do the work of ordering
instructions particularly crafty so it wouldn't stall
Obviously it was a disaster, but it didn't/doesn't sound like it is necessarily a bad idea.
A ridiculous percentage of a modern CPU's transistor count (and design complexity) is devoted to speculative execution and other "smarts" that intel proposed shifting to the compiler. Which theoretically lets you ditch all that speculative execution hardware in the CPU and spend it on more badass cool performance stuff. Theoretically.
Pour one out for blind faith in Transmeta (which Linus also was involved with) Crusoe-like VLIW, complicated compilers, and Rolls-Royce grand designs with almost 500 registers. Enterprise will buy anything if it's expensive enough, right?
Perhaps VLIW should've been proven workable and advantageous with realistic modeling first before betting billions in development.
I really like the idea of VLIW CPUs, it's a shame none of them have worked out. Does anyone know of any other cool more modern CPU designs? Stuff like RISCV is fine but doesn't feel particularly innovative
The mill architecture has interesting ideas but as far as I know it’s never made it past simulation and there hasn’t been much progress lately. https://millcomputing.com/
They had a bunch of really interesting ideas but trying to innovate in more ways at once brings exponentially more risk. And there weren't only trying to reconceptialize how computers worked, they also were doing a weird innovative corporate structure too.
Once the patents expire I hope someone makes a RISC-V design that just tries to get their, e.g., virtual and backless memory working with Linux. That seems like it would be worthwhile in and of itself.
There have been successful VLIWs in eg GPUs and mobile basebands. Ie in apps that don't have the software inertia of needing to run existing CPU code. Parallel unfriendly C/C++ semantics is the killer.
VLIW architecture is far from uncommon in DSPs (digital signal processors). TI, NXP, Fujitsu, and plenty of other companies with names less likely to be know by most people focused on general purpose computing currently manufacture massive quantities of VLIW based DSPs.
The Hexagon DSPs in Qualcomm's Snapdragon SoC line are VLIWs. Also, NVidia used some cores from the Transmeta lineage in some of its mobile SoCs for application cores. There was a program that ran on them that automatically rewrote ARM instructions to their own ISA that not only was VLIW but was a skewed pipeline VLIW! That's what the Mill guys call phasing, see here: https://millcomputing.com/wiki/Phasing
The chip designers back then were focussed (micro-)instructions per clock (IPC), and everyone knew that RISC and CISC were going to hit a wall due to the ALU bypass network. A this is pretty true, they did, to this day, with some incremental improvements. Folks hoped that VLIW and advanced compilers would take us to the next level of IPC. What they didn't realize was that Itanium wasn't a true VLIW, and had that same ALU bypass network, hence couldn't scale up width and frequency as promised. But a true VLIW would have been very hard to work with. Perhaps Transmeta's approach could have worked if that technology was pushed by a a larger, more resourced company.
I wonder how ARM, so relatively late with AArch64, was able to compel Fujitsu to take the instruction set to the heights of the top-performing supercomputer.
I understand that there are exotic addressing modes involved. I'm not versed enough to understand.
Fujitsu was using their own in-house SPARC designs with custom vector instructions, but they could see that SPARC is dead and has no future. In fact, not that long ago they announced that they will stop sales in 2029 and support 5 years later: https://www.fujitsu.com/global/products/computing/servers/un...
So if they wanted to keep pushing their own designs they needed a new architecture, and ARM64 was their best option. The modern SVE extensions were co-designed by ARM and Fujitsu based on their HPC experience.
Yep, the conventional (current) wisdom is that they hit compilers. Itanic was predicated (pun intended) on compilers being able to deliver the parallelism from existing C/C++ apps.
It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.
Aside the commercial fail, Itanic EPIC design is an interesting architecture especially when revisited from the lens of GPU computing world we live in today.
Itanic also contributed EFI and popular 64-bit ABI conventions.
In the mid 2000s I had to test a product I was working on with all architectures supported by Windows, which of course included ia64. We had one engineering sample HP ia64 machine in the test lab (I think it was a zx2000 but I could be mistaken). It was this giant, noisy, hulking boat anchor full tower that weighed some over 50 lbs and had a 650W power supply.
I had to find a Server 2003 ia64 CD to install the OS (and work through the awful UEFI CLI incantations required to get the damn thing to boot). Once installed I was always struck by just how incredibly slow the machine was. It was just such a drag to use. Once we no longer needed to support ia64 I was thrilled that I’d never need to use that thing again.
219 comments
[ 3.0 ms ] story [ 228 ms ] threadTurns out it was more like IBM's MCA / PS2 rather than the future.
Compatibility and ubiquity wins. As nearly always.
> The failure of this chip to do anything more than exist as a niche processor sealed the fate of Intel—and perhaps the entire industry, since from 1997 to 2001 everyone waited for the messiah of chips to take us all to the next level.
> It did that all right. It took us to the next level. But we didn't know that the next level was below us, not above. The next level was the basement, in fact. Hopefully Intel won't come up with any more bright ideas like the Itanium. We can't afford to excavate another level down.
The DEC Alpha architecture was planned for 25 years and it certainly was not technical barriers that killed the Alpha 21464.
DEC should have bought MIPS, and ported VMS to it.
Had they made that decision, they might still exist.
So when samples arrived they were 2-3 years later than they should have been and MIPs had made some headway in the same space.
DEC - actually Bob Supnik - decided that even though Prism was the better arch, MIPS products would bring in revenue more quickly.
Which was true. But... then Prism was killed, which led to a mass walkout. The remains were resurrected a year later with some updates as Alpha. But by then it was too late for that particular market.
Prism was a solid arch - some quirks, but nothing unworkable. And very, very fast.
But it was a workstation-grade processor, not a mainstream PC-grade processor.
DEC completely failed to understand the PC market, and it's not obvious what would have happened if Prism had survived. IMO it would have gone the way of MIPS anyway, because the workstation market was already being squeezed hard, and the PC and Mac markets had already made their choices.
It might have had a good run against SPARC for a decade or so, but that would have been it.
DEC's terminals? killed by PCs. The VAX lineup? killed by RISC chips, and the VAX 9000 consumed a huge chunk of their cash reserves before embarrassingly being rendered obsolete by their own NVAX.
This was a time of change from minicomputers to microcomputers and DEC made costly decision after costly decision. They kept selling off profitable "non-core" portions of the business that in the process incurred a loss.
Not defending Itanium. But the average article on computer architecture has been garbage for decades now, it's fascinating.
Of course, it's also possible that by that point Sun was already paralysed by infighting between various splinter groups, with no big bad DEC to fight against.
Linus Torvalds in 2003: https://yarchive.net/comp/linux/x86.html
>Itanium 2 doesn't hold a candle to a P4 on any real-world benchmarks.
I’m not particularly confused about Intel’s perspective on compatibility: Even at the time, there were several examples of successful platform CPU transitions across architectural “full breaks”. Apple going from 68k to PowerPC is the closest analogy for Intel, and if the Itanium performance and software (compiler) story had played out as Intel envisioned they likely would have been fine.
But as for ubiquity, I’m befuddled. As far as I’ve been able to determine—having lived through it and followed many retrospective threads like this looking for new evidence—Intel had no plans on any useful timeline to turn Itanium into a (non-workstation) desktop or laptop chip. Did they really think the market would stay bifurcated between “big iron” architectures and x86 personal machines for another decade? I can’t imagine they would have believed that.
Oh but they did :)
Going back to at least the i432, Intel seems to have had a deep vein of “mainframe envy” in their culture and strategic thinking. It seems that somehow the market (and a bit of trailblazing into x86-64 by AMD) saved them from themselves.
Direct quote from Wikipedia https://en.m.wikipedia.org/wiki/Intel_iAPX_432
""" Intel's iAPX432 was intended to be Intel's major design for the 1980s. Unlike the 8086, which was designed the following year as a successor to the 8080, the iAPX 432 was a radical departure from Intel's previous designs meant for a different market niche...
Referred to as a "micromainframe", the iAPX 432 was designed to be programmed entirely in high-level languages. """
Folklore describes the 8086 as a stop-gap design, an extension of the popular (but tiny) 8080 CPU. The "real" design project at Intel was the i432, which supported object-oriented programming and was THE FUTURE OF ALL COMPUTING.
A cut-down version of the object oriented support was carried over into the x86 architecture, in its segmented memory model and page-description registers. You're welcome.
I think they knew they could fall back on x86 if everything went wrong - but what they did NOT expect was x86-64 to just smash everything. That caught them on backfoot.
They are basically just building a better version of the same product they were selling 20 years ago… so much opportunity missed here.
https://en.m.wikipedia.org/wiki/Datapoint_2200
But even that goes back to the P6->P5->486->386->286->8086->8088->8080->8008->CTC lineage of 50+yrs. It literally just cuts out the few years of the abandoned NetBurst architecture.
I can. The x86 hegemony was overpowering in the PC space but the moment you left that corner of the market we had a lot more ISA diversity then than in the following years. In a world that seemed to have no problem with Macs on PowerPC, PCs on x86, and workstations/servers on SPARC/MIPS/PA-RISC, just consolidating workstations and servers probably seemed reasonable. You can even see an analog in the way we've kept x86 on "real computers" while ARM has dominated mobile. IMHO the only reason it didn't work out is because workstations and servers merged with PCs.
Alpha was clearly the future -- and Itanic ruined Alpha. We didn't even get to see it live on inside some other corporate sarlacc.
[0] https://bcantrill.dtrace.org/2008/07/18/revisiting-the-intel...
[1] https://dl.acm.org/doi/pdf/10.1145/45059.214411
https://en.wikipedia.org/wiki/Intel_iAPX_432
In this case, that means AMD showing up with the first x86-compatible 64-bit CPUs killed Itanium dead. For big software projects already running on x86, there were 2 options:
- Port everything to a new architecture that only looked good in specific benchmarks, cross your fingers, and hope for the best.
- Keep running your code on new 64-bit CPUs that were backward compatible with your existing code, then recompile for 64-bit as you got around to it.
As a bonus, amd64/x86-64 CPUs were faster than the P4 chips that practically needed 3 phase power to boot up.
It was kind of a no brainer.
It was quite a bit worse than that. If you ignore the horror of IBM vendor lock-in, which in retrospect made the whole thing untenable, and the overpriced nature of the systems, MCA was a fine thing for its time. The PS/2s had some nice features. They were compatible with everyone's DOS and Windows stuff, even if IBM would have preferred you use OS/2, and so on.
Itanium was a piece of crap, even if you could somehow ignore the cost and lock-in.
Counterexample: GPU compute.
I'm not sure that was Itanium's only problem. Intel's Itanium launch focused on a market that was not captured by the so-called "Wintel" monopoly: high performance servers. The software support needed in this market was relatively narrow. Nevertheless, it failed there too.
The biggest issue with Itanium is that the juice was never worth the squeeze. It was expensive. The cost to migrate your existing 64bit systems never made sense. So, you might ask, what about 32-bit shops that needed to make the leap to 64 bits? Well, by the time intel and its vendors started getting costs under control, the AMD Opteron hit the scene with commodity 64bit hardware that had the added benefit of full backwards compatibility. And that pretty much killed it.
On the other hand, it's a bit of a shame to formally, officially lose another option out of the computing ecosystem.
there's an altix 3000 on ebay that I'm kinda tempted by https://www.ebay.com/itm/174917876903
it only runs like one specific version of suse or red hat
Do you have anything specific you'd do with an Altix 3000?
(I don't mean to sound snooty)
nope, I just like weird computers and distributed systems, itanium is possibly the weirdest CPU architecture that modern linux can run on, and SGI is an interesting part of computer history.
I assume Porting Linux to the pre-MIPS Tandem line would be a challenge. The Proprietary CPU was 'stack based' and very different from x86. Also, I don't know if Tandem ever sold compilers to do the sort of 'low level' system stuff to port another OS..
The rackmount Tezros and Origin 350s sound like they belong at the airport.
They're fun if you want to run the demos or load fsn and tell everyone in earshot "this is a Unix system! I know this!" But they're not even useful as X consoles to a Linux box these days, because of the compilation nightmare of getting recent network tools installed.
https://news.ycombinator.com/item?id=38115989
https://upload.wikimedia.org/wikipedia/commons/8/88/Itanium_...
Statistics and modeling are complicated, granted. But when your model diverges from reality 5 years in a row, perhaps you should just extrapolate the current line next time around.
(In the case of the Itanic, that would have been the line at 0. Still a better forecast than what they did!)
"There's no way this level of growth can be sustainable."
"Surely we've hit a stable level by now."
"Maybe that last year was a fluke."
Love to see it. :)
Those are GW of added capacity per year, their prediction flatlining is predicting sustaining the same level of growth.
https://www.statista.com/chart/31016/volume-of-global-fossil...
E.g. if a solar panel factory (simplifying into a single entity) already exists, is there any reason not to run it at 100% production capacity? What consumables are used?
Afaik, it's more strict metallurgy (materialurgy?): temperature, time, some physical process.
Point being, I'd be curious on the actual cost of material inputs, if the price of solar panels crashes. How low can they go... and still be worth making?
From https://news.ycombinator.com/item?id=38150735, it’s very energy intensive.
> if the price of solar panels crashes. How low can they go... and still be worth making?
Boules are very storable, so it’s the financials of pausing production and storing materials until the price (or new tech) makes it profitable. Not the most socially responsible thing to do in decarbonisation times, but done with aluminium and other energy intensive storables all the time.
- Czochralski purification of silicon to produce a "boule"
- saw boule into "wafers" (surprisingly important, see "reduced kerf diamond wire saw")
- wafers can be used for microchips, or doped into solar cells
- apply contacts to top face
- package into a panel with glass and aluminium frames
The "wafer" market is somewhat independent. Purification depends on the price of energy (it's very energy intensive). Better sawing reduces waste and increases wafers per boule.
More factories come online all the time. Panels themselves are now extremely cheap, and it's worth looking at "balance of system" (labour, permitting, frames and racks, inverters).
I believe market data firms track all the relevant info, although they don't necessarily give the resulting info away on the internet.
[1] https://www.iea.org/reports/world-energy-outlook-2018/
Our most recent near-miss at a statewide outage happened because of unexpectedly low wind. It’s happening in Texas first because we have a smaller grid and it’s deregulated to the point where cheap but unreliable renewables can crowd out other sources of generation. The eastern and western grids will face the same problems in the long run the more and more renewables come to replace other sources of power.
Renewables, especially construction of new renewables, is a big, lucrative, growing business of its own. That’s actually a direct implication of the triumphant statistics people keep sharing about how much renewable power generation gets built out every year. So the “fossil fuel industry” is not unique in its vested interest to propagandize against its competition. And this incentive is only increased by the movement towards ESG in finance. But if we’re done accusing each other of being shills, let’s get to the substance of the matter at hand here.
> For example, the 2021 winter outages were caused by power plant operators not wanting to spend money making their plants more robust.
This included the renewables too, of course, along with the entire rest of the state’s infrastructure. But the near outage this summer was directly caused by low wind. There are probably issues with solar as well—heat, and cooling demand along with it, peak in the early evening just as sunlight starts to diminish—but usually wind manages to cover that gap. That doesn’t always happen though.
And, yes, renewables are becoming a big industry but it’s nowhere near as big as the fossil fuel industry and orders of magnitude less lavishly subsidized. Texas Republicans tried to ban wind and solar expansion because that party has been owned by the oil industry for decades and the renewable industry has nowhere near the same level of lobbying clout.
I can’t find any good source about your claim of thermal plants going offline in the September incident. ERCOT’s statements consistently blame the combination of high demand and low wind. The federal Department of Energy even issued an order authorizing Texas power plants to exceed normal emissions limits in such an emergency, which is inconsistent with your claim that they “go offline” in these conditions: https://www.ercot.com/about/legal/doe202c
> And, yes, renewables are becoming a big industry but it’s nowhere near as big as the fossil fuel industry and orders of magnitude less lavishly subsidized.
I thought we were done accusing each other of being shills. I’ll just point out that there’s significantly more propaganda in favor of renewable energy than in favor of natural gas or nuclear. But this is Hacker News and I am assuming good faith of you rather than accusing you of parroting talking points that were fed to you by Chinese photovoltaic manufacturers or annoying Swedish teenagers. And I am simply asking the same courtesy from you.
> Texas Republicans tried to ban wind and solar expansion because that party has been owned by the oil industry for decades
I think there is a good faith reason for such a policy. And while I do live in Texas and usually vote for Republicans, I am asking you to engage with me in good faith instead of calling me a shill. Are you capable of that or is the idea that someone can disagree with you about energy policy in good faith beyond your comprehension? Because you seem to be using this idea as a thought-terminating cliche.
https://www.bloomberg.com/news/articles/2023-08-29/texas-ask...
https://www.iea.org/reports/renewable-energy-market-update-j...
Intel wanted in on this space and didn't want AMD to be able to produce compatible parts so... enter EPIC [1]. The projections (as you point to) were wildly optimistic. Of course the whole thing was heavily delayed, produced in small volume, offered limited to no performance gain, required a ground up write of pretty much everything and was super expensive. What could go wrong?
What did AMD do? It just invented 64 bit extensions to x86 (ie x86-64). Was it ideal? No. You probably wouldn't design an instruction set and architecture this way if you were starting from nothing but you aren't starting from nothing. AMD released the wildly successful Opteron (and Athlon 64) and for 5-10 years completley ate Intel's lunch. Cheap parts, good performance, easy migration part, etc. Intel got to use these extensions by the same licensing agreement.
This coincided with the Gigahertz wars on the desktop front. From the Pentium for almost a decade Intel focused on Gigahertz and once thought they could run this up all the way to 10GHz+. We know how that went. Clock speed was a key marketing bullet point. AMD processors had higher IPC but that (at that time) was a harder sell.
About the time Opteron came out the Gigahertz wars were hitting the 3GHz barrier and Intel was stuck. At the same time their mobile parts used a completely different architecture. Thsi was Centrino with the Core Duo processors. These had much higher IPC (than Pentium lines) and more power efficiency. Some early enthusiasts constructed desktops from these mobile chips and the results were great.
Losing out to Opteron/Athlon and hitting the 3GHz barrier ultimately forced Intel to abandon their desktop architecture in favor of Centrino. Intel hung on as long as they could to milk some extra profit but eventually Core Duo was the future and this ultimately because the foundation for the Core processors we have today (but by now there have been many revisions). It might be more accurate to describe the Pentium years as the Netburst architecture years (IIRC).
But the lesson here is that a complete rewrite was an almost fatal mistake for Intel. It's almost always a mistake. You can't ignore what's there now and your desire to lock out competition doesn't necessarily translate to something customers actually want or need.
[1]: https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...
ARM is cheaper and the performance hit is smaller than the savings. For scalable workloads you can easily just run more ARM and save money. Also, a lot (lot) of workloads are memory or I/O bound so the performance hit is negligible. ARM has gotten pretty optimized in both the CPU architecture and the tooling thanks to mobile uses.
What AWS offers and what Google offers are not even close: on AWS, our workloads actually perform better (as in, higher QPS/core, resulting in fewer pods/instances), in addition to being more cost effective (both in terms of per-instance price to begging with, and less instances in total, due to aforementioned higher QPS/core serving same amount of total requests). For the limited ARM offer from Google we tested, the performance is worse than equivalent x86 instances, in addition to no price incentives.
It's pretty funny.
> with the characteristics of the processor architecture nor with processor performance.
Why did AMD introduce Genoa and Intel is developing equivalent products too? There is market for CPUs with a very high number of low-powers cores and it seems ARM had an advantage there. Even now the price per core (which are good enough for many applications) for Ampere/Gravitron cores is significantly lower.
When you're running commercial software at $$$$ per license, the customers basically have to stick to whatever hardware is explicitly supported. And the vendors are going to be narrow there. Fewer platforms keep support costs down, and prevent exposure to uncompetitive corners of the market. As long as $expensive_product is only officially supported for x86, nobody needs to know it's riotously unperformant on ARM in ways that will require wholesale rewrites to fix.
When it's all open stuff, nothing stops people from compiling it for ARM, RISC-V, and hell 65C816, letting the market choose which platform fits their needs best. For many audiences it might not be "maximum performance under cost-no-object hardware"; it might be "what's the cheapest way to serve a fixed N workload units per month, when you include the purchase cost, electricity cost, rack-space rental cost, etc."
As a second-order effect, I expect removing license cost from the equation also impacts the metrics people care about. When the software price is the dominant aspect of the bill, nobody's going to make much of a case of "we can save 55 of the annual cost up front by using cheaper good-enough hardware" or "we'll save 1% per month on the energy bill".
AArch64 and AMD64 has more in common than Itanium which is a bag of hurt from hardware to compiler.
ARM on Server actually saves money at the scale being deployed, while Itanium has zero cost advantage, and that is before adding the cost of software which was order of magnitude worst than any estimate had made at the time.
Most Server software operate on Open Source software. From Linux to Nginx, MySQL, Postgres, Memcache or Redis and tons and tons OSS. Which makes changes far easier than waiting for vendor to support AArch64.
AArach64 has a much bigger market to fine tune its software stack and toolchain from Smartphones. There are currently 4.5+Billion of Smartphone in uses, that is larger than all the x86 usage in the world. Compare that to IA64 /Itanium.
So for a few HPC type things, it was an a leap forward, for everything else, it sucked.
It was like the arm based windows surface laptops a few years ago. Lots of promise, none of the software that you actually wanted.
When you looked at the opteron which was 64 bit, run faster, cheaper than the intel and could run vanilla 32bit apps without any changes faster than before, it was a no brainer.
Many people don’t realize ARM can trace its origins back to the BBC Micro. For a variety of reasons it found a niche in low power applications, even 30+ years ago. ARM, the company, simply sells licenses without producing its own silicon. There’s concern now with it going public that it will seek revenue by jacking up licensing costs.
It’s mobile devices where ARM flourished and entered public consciousness. There used to be other platforms but they died off. Intel sold XScale years ago because of a lack of vision.
ARM processors got sufficiently powerful to be in servers and power efficiency became a big deal. Google really transformed this space with sub-1.1 PUEs when no one outside even believed that was possible. Performance per Watt became a really big deal.
Also, I’m not sure if this is entirely fair but I credit Apple with a lot of ARM’s success. They bought a company called PA Semi and pushed the envelope with what ARM can do. I think that may have been the best $400 million (IIRC) ever spent.
This makes it sound as if xscale was an alternative platform to ARM. Intel xscale cores implemented the ARMv5 isa.
Starting a CPU company and selling CPUs to customers has always been difficult since you need to compete with other CPU packagers and Intel had the largest scale so could always put you out of business if you became a threat.
With the rise of big cloud server giants (AWS, Azure, Google), they can license the cores from ARM, build their own CPUs and cut out the middle-man. They are their own CPU customers so don't have to worry about building a market.
It's the rise of vertical integration from tech giants.
The machine it originally ran in is humming away too, albeit with a replacement Pentium M using a socket 478 adapter.
I keep it as a reminder that even billions of dollars can't see around the future corner.
The NetBurst microarchitecture of Pentium 4 was killed off and a 64-bit version of the P6 Variant Enhanced Pentium M microarchitecture took the baton.
* no byte operations
* no flags, thus no reasonable way to check for overflow (similar to one of the problems RISC-V is having, though at least they pretend to care).
> The processor may lose track of your LDx_L if you perform any memory access other than a matching STx_C, or if you perform a branch instruction, or if you trigger a trap (such as executing an emulated instruction), or if you execute more than 20 instructions after the LDx_L.
(LDxL and STxC are locked load and conditional store)
The answer is to be careful as a dev, and hopefully let the compiler and your libraries take care of the finer details.
The memory consistency model was pretty crazy, though.
1. Windows NT, which is the ancestor of modern Windows, was originally released on multiple platforms including Alpha and, I believe, MIPS; and
2. DEC, for awhile at least, had one of the most popular Web search engines: AltaVista. It wasn’t a commercial enterprise. It was mostly a technology demonstration for Alpha. For the time it was pretty good. No one at this time (the 1990s) thought there was a future in search engines. Many (including Yahoo) seemed to think curated directories were the future. Search engines were viewed as a solved problem, except by Larry Page and Sergei Brin who founded Google.
The highly underrated show “Halt and Catch Fire” covers this early era of computing really well and is worth watching.
FWIW the alpha design teams ended up cannibalized between AMD and Intel. The original Opteron and the first generations of Core i have a ton of AXP DNA in them, from a uarch standpoint. So in a sense, Intel and AMD did continue Alpha... sort of.
However. I feel that Alpha gets over fetishized on the internet sometimes. It was a clean arch, mainly because it was a clean 64bit design from the get go. But as far as uArch, it was pretty generic. Most of the uArch themes the AXP design teams used, which a lot of people think were native inventions to Alpha, came straight from industry/academia research, and plenty of other processors implemented them as well.
We used HP boxes and I want to say it was around 2002/2003 when this was going on. We were supposed to be a huge public showpiece client for both intel and HP. It… did not go very well. I remember the absolute defeated looks of the HP / Intel people when we pulled the plug and told them the discounts / free hardware still couldn’t justify the engineering efforts we had gone through for the last 18-24 months. This was right as opterons were coming out and that project jumped ship to them.
Credit especially goes to the people who stayed on the various x86 processor teams. Itanium’s single greatest source of failure was that successive Penguin generations undercut the advantage of x86 compatibility by adding the option of not migrating at all and still getting better performance. They probably saved the company but I doubt that got much praise at the time since it required acknowledging how badly the Itanium project had failed.
All that Itanium was, at the end of the day, was an in-order PA-RISC/SPARC hybrid that exposed a lot of the superscalar innards to the programmer (compiler)
VLIW scheduling even back then wasn't as much of a mystery as the usenet and register flamewars implied. It really is pretty straightforward for a compiler to behave like an in-order superscalar scheduler. And since the compiler has a much global information about the instruction stream it can do much more optimizations and static ordering than a normal in-order HW superscalar scheduler alone.
Plus itanium had plenty of dynamic microarchitectural components to complement the static ordering done by the compiler and increase FU utilization.
If anything, things like predication and its adverse effect in power consumption had a much worse impact on itanium than the compilers.
What killed the itanium was just simple economics; its performance was fine (for the time, at least for itanium2). It's performance/price ratio, however, was not.
Banias was the Israeli team asking how do we make an incredibly efficient mobile CPU and the answer was finish your work quickly and go to sleep.
In order to finish quickly, you had to be fast and efficient. Someone said well what if we don't actually go to sleep?
IIRCC, Core was a combination of the Banias CPU architecture, an evolution of P3, combined with the Netburst bus architecture from P4.
Pentium 4 was heavily marketing driven, to win the Gigahertz war.
The fab side of Intel had a huge priority in setting early architectural themes. And some of the CMOs flows in lab, in mid 90s, were showing huge speed scaling, but they had very restrictive design rules and cell libraries. But with the payout of extreme GHz scaling.
From that point of view, the P4 made sense; a narrow architecture with very deep pipelines. Where each stage used the tiny datapaths between latches/registers those libraries supported. Netburst makes sense in terms of dealing with extremely deep out of order pipelines.
However, those processes never met the scaling roadmaps. While the power consumption scaled horribly, and things like thermal, leakage and variability started to become first order limiters.
How did they get to the point of finish-your-work-quickly? Short pipelines?
So for Banias started with the P3 pipeline which was already short and added the microop fusion that I believe was introduced in P4. As well a cribbing a lot of other enhancements from Netburst.
It's been several years since I read up on it so I'm rust on all the details.
For the sake of humanity, we need to crowdfund a blimp with this quote that just flies back and forth between Cupertino/Mountain View and San Mateo for the next 5 or 10 years.
I can't wait for ARM to eat their lunch. And dinner.
I do believe that whoever drove the Centrino movement (from mobile originally to desktop) saved the company. They laid the foundation for Intel's next 15 years of success.
The original licensing agreement with AMD is an interesting part of Intel history too. Were that to happen today, it would probably be viewed as a disaster. In our modern era of short term corporate decision-making, it would probably be viewed negatively too.
But it led to Intel's complete dominance thanks to x86 for decades. It killed pretty much every other architecture (other than ARM). It's only in the last 5-10 years that dominance has really wavered.
Intel's big strength had always been their ability to fab chips at scale with low failure rate so the parts were hugely profitable. For decades the likes of AMD just didn't have that manufacturing capacity at the same scale and price. Intel led die-shrinking that was a huge driver to profits. It's only when they tried to move to 10nm that it all fell apart. Now TSMC has eaten their lunch. Intel is at risk of moving from being a first-party designer and fab of chips to producing third-party chips.
If someone woke up from a 20 year coma and you told them about Intel's market position and fate they would be shocked. That's how big of a fall from grace it's been. But that's largely on the fab side, not the design side. Only recently has the Core architecture really hit its limit where Intel CPUs consume too much power and run too hot to eke out the last ounce of power.
Itanium was a joint venture betwen HP and Intel. We can certainly look back now and say it was bad. I'm not convinced that determination was as easy at the time although it did have its critics.
They have had failed products, no doubt.
But I don't think you understand also how insanely good at execution Intel was during the 80s and 90s.
That part didnt happen because Intel bribed OEMs. Just DELL alone was receiving ~$1B a year to exclusively sell Intel.
Drake pointing: Runs IA-32
The Chicken and the Egg The very first effort that is considered a direct ancestor of UEFI technology had a very specific tactical goal. In the course of 1997 people at Intel were working on how to boot computers based on the prospective Itanium® Processor family...."
from https://www.intel.com/content/dam/www/public/us/en/documents...
https://itanium-cxx-abi.github.io/cxx-abi/abi.html
My understanding is this was first created for Itanium but is now used for other architectures.
Sort of a half joke, I can see no way OFW could have made the jump to the pc world.
For a time, you could easily download a devkit for EFI on x86 which included tools and source code for EFI 1.1.
It killed their manufacturing based on hype, where as they all established a firm install base before itanium ever got rolling, which has ensured they continue to be (halfheartedly) maintained.
But today? Moving some of the adaptions from the hardware scheduler to process lifetime persistence (as in JIT VM) or even into the software distribution infrastructure could be delightfully transparent.
GPUs have taken over much of the niche where these processors excel, number crunching where you have entirely pre-determined memory / compute access patterns.
It guzzled power. This was the biggest problem, not solvable in its lifetime with its resources.
"According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible."
https://en.m.wikipedia.org/wiki/StrongARM
Huge box with a huge PSU. And we had some cheapo desktop HPs with dual Pentium2(3? (the card edge ones)) at like 450 or 533.
Which basically ran circles and sipped power by comparison. Don't remember the exact numbers but only 2 per 15A circuit; with 4 of the x86 per.
Didn't sound like Itanic played a part at all.
The end result was that they had to restart development of EV7 then restart its production again, because many, many ex-DEC customers didn't want to move to Itanium (customers running Tru64 mostly moved to Linux on amd64 or occasionally to other RISC vendors instead of dealing with HP-UX, whereas OpenVMS customers kept to Alphas which outperformed Itanium usually or moved off the platform completely, with stragglers now moving to amd64)
By the time HP bought Compaq, AXP was on legacy mode. Plus Itanium was as much of an HP architecture as it was intel's, so it made no sense for HP to develop AXP further.
I don't think many of the arm chair CPU experts really understand how expensive it is to design a high performance CPU core.
If you’re ever on funky hardware and want to ensure continuing Linux compatibility, I guess it pays to subscribe.
A ridiculous percentage of a modern CPU's transistor count (and design complexity) is devoted to speculative execution and other "smarts" that intel proposed shifting to the compiler. Which theoretically lets you ditch all that speculative execution hardware in the CPU and spend it on more badass cool performance stuff. Theoretically.
Perhaps VLIW should've been proven workable and advantageous with realistic modeling first before betting billions in development.
Once the patents expire I hope someone makes a RISC-V design that just tries to get their, e.g., virtual and backless memory working with Linux. That seems like it would be worthwhile in and of itself.
I understand that there are exotic addressing modes involved. I'm not versed enough to understand.
https://en.m.wikipedia.org/wiki/Fugaku_(supercomputer)
So if they wanted to keep pushing their own designs they needed a new architecture, and ARM64 was their best option. The modern SVE extensions were co-designed by ARM and Fujitsu based on their HPC experience.
It's pretty tragic how this has turned out. Still no mainstream CPU languages that are good for parallelism and all the action is happening in the GPU side with the tragic fragmented mutually incompatible buggy properietary dev stacks (and C++ baggage to top it off), going on for 15+ years.
Itanic also contributed EFI and popular 64-bit ABI conventions.
I had to find a Server 2003 ia64 CD to install the OS (and work through the awful UEFI CLI incantations required to get the damn thing to boot). Once installed I was always struck by just how incredibly slow the machine was. It was just such a drag to use. Once we no longer needed to support ia64 I was thrilled that I’d never need to use that thing again.
Good riddance.
Good riddance.