The Itanium sales forecasts never fail to make me laugh. Aged like the finest wine:
https://upload.wikimedia.org/wikipedia/commons/8/88/Itanium_...
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!)
https://www.iea.org/reports/renewable-energy-market-update-j...
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...
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?
- 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.
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.
"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.
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...
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
> 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.
It's pretty funny.
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.
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.
Drake pointing: Runs IA-32