Comment by nickysielicki | Hacker News Reader

Comment by nickysielicki | Hacker News Reader

Parent Full thread

> The reality is that the reasons these chips are fast are either unknown or boring. I suspect that these will one out as we play around with them more, but we don’t have the details right now.

I disagree, I think we have plenty of information. This is what happens when a huge proportion of your die isn't doing instruction decoding. x86/amd64 are old and crufty. Lessons have been learned, and had been learned for some time, but people (AMD/Intel) were not brave enough to fix them because they didn't have adequate control of their software ecosystem to say, "Your software from your old computer will not run/will not run as well on your new computer." (For emphasis, let me just put it clearly what I'm claiming: x86 was designed in the 1970s. This is what happens when you use an ISA that was not designed in the 1970s.)

Apple, however, does have control of their ecosystem, and they're allowed to be brave, provided they can support their ecosystem.

Here's my hot take: Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time. That's changed. First things first, we're going to see mainstream desktop-class/laptop-class ARM being extended to linux and Windows. But I also believe that sometime in the next ten years, after all this newfangled high-performance ARM stuff is sorted out, we're also going to see someone give VLIW another shot, and they're going to succeed this time.

This is what happens when a huge proportion of your die isn't doing instruction decoding.

That's a misconception. Yes, decoding x86 is somewhat more complicated, as far as I'm aware that's mostly because instruction length differs at a byte granularity. Still, the area dedicated to it simply isn't that large on those huge out of order designs.

I'm sure the instruction encoding plays some role, but I suspect what we're seeing is rather down to consistently good micro-architecture execution over the years and Apple being ahead of everybody else on manufacturing process.

Compared to the x86 processors that exist today, M1 also benefits from having the memory in-package.

Intel tried to be brave with Itanium, but failed because compilers weren't up to the job at the time.

Compilers "failed" because VLIW is fundamentally not a particularly useful idea. The main problem for general purpose single-thread performance is memory latency, and VLIW just doesn't help there.

> Compilers "failed" because VLIW is fundamentally not a particularly useful idea.

I think the problem isn’t just that it’s not particularly useful, but that it’s an actively bad idea. It statically encodes ILP that we get dynamically in chip designs today, which means that ILP can no longer react to changing conditions, like literally any core architecture changes as the underlying hardware evolves (or even on the same die, say finding itself running on an efficiency core rather than a performance core or vice versa) or running in an SMT environment in which it is not the only instruction stream going through the pipeline.

Adapting to advancing hardware isn't impossible. It's been awhile since I've looked so details are a little hazy, but I know the Mill architecture had an answer to this. I believe they were using effectively two-pass compilation. The first compiled against an abstract version of the architecture, and this is what was distributed. Then this could be further specialized on the user's machine as at that point the limits of the hardware would be known.

I don't recall if they had an idea for SMT as well or not. It's possible they wrote it off entirely, particularly after Spectre and all that.

You are correct that with a lot of effort you can get a compiler to emit VLIW instructions that can claw back some of these problems and have some, but not all, of the information you have available to the processor core at runtime which can make things slightly smarter. And with all of that effort which involves changing software distribution models, jettisoning energy efficient flexible heterogenous architectures, and abandoning SMT, you might be able to get something close to performing as well as… what we already have today without VLIW.

Not sure why anyone thinks that’s an argument for doing it.

> Not sure why anyone thinks that’s an argument for doing it.

Because it didn't take very much effort and it doesn't require changing distribution models or abandoning those things.

Not disputing what you're saying on instruction decoding but there is a lot of other stuff on an x86 processor that Apple hasn't needed or chosen to implement: 32bit, AVX, legacy SIMD, legacy modes, Intel Management Engine plus probably a more complex instruction set. Individually these may not make a difference but add them all up ....

> Individually these may not make a difference but add them all up ....

... and it still may not make a difference.

I have AVX512 on my laptop. Is it used by any software I use? No. Does it take up a lot of die area? Definitely.

Doesn't Apple use TSMC manufacturing?

Yes, and they are the only ones on TSMC 5nm currently.

That's because apple bought the entire 5nm production capacity/runs for basically for the entire last quarter of 2020.

I can tell you some companies were not too pleased about that.

Ah yeah, Apple has f-you money and it knows how to use it.

They did this with FedEx planes out of China years back, forget which iPhone version, but they basically did the same thing they booked everything. All FedEx planes only had iPhones and everybody complained. I don't think they have tried that stunt again.

Is there anything preventing those companies from "ganging" up on Apple and buying capacity jointly? Are they too many and too small? Is it possible to share wafer-space with other companies or does having multiple designs add too much complexity/cost?

I think Apple essentially outbid them, which it was able to do because it is has both large volume and large profit margins.

Which companies?

AMD.

Intel failed because AMD exists and has a cross license agreement that allowed them to be clever.

Without AMD in the picture, Itanium issues would have eventually been sorted out.

There would have been no Intel on IBM compatible PCs without x86 cross licensing, so you could make the point that AMD allowed Intel to thrive.

What? I was there on the early days, that just makes no sense.

Cyrix, VIA and friends were ocean drops, hardly available outside US.

Very unlikely that IBM would have used the 8088 without a second source - so literally Intel needed firms like AMD.

Not unlikely, it was a condition.

Nope, it was a condition from government to buy PCs from IBM, most of their computers have always been single source.

So what were the second source from all major IBM computers throughout its history?

Sorry, don't know what point you're making here.

"However, IBM required that Intel find a second-source supplier because production had to be guaranteed and it was too risky to rely on a single company as the sole source of its chips."

https://jolt.law.harvard.edu/digest/intel-and-the-x86-archit...

That was a first for IBM, and althought not mentioned there I seem to recall it had something to do with selling PC to the goverment as well.

I seem to recall that IBM had second source rights to the 8088 too which presumably made the choice easier.

Fair enough, then I am most likely wrong here.

I have to say I'm confused now!

Feeling a bit nostaligic now as my first job was with IBM selling the original PC to small businesses. Not the hardest job!

Well, yes, if Intel had no competition at all they might have been able to force whatever garbage on the market.

I actually liked Itanium and don't see it as garbage, and see as an unfortunate turn of events that I am not running one on this laptop.

Also don't get the point of the cheering for AMD, because apparently many don't get that without Intel licenses, which depend on Intel existence, AMD won't have much to play with anyway.

20 or so years later, it is my impression that there are no compilers that can do enough ILP (on software not specifically written for the Itanium) to justify the Itanium’s VLIW.

Intel licensed some stuff to Cyrix, VIA, AMD, Harris and possibly others at the time. But if AMD didn’t license AMD64 back (by way of cross licensing) things might have been grim for Intel back in 2003-2008 when AMD was killing it previously.

Intel did nothing out of the goodness of their heart, and neither did AMD - so I’m not sure why it is bothering you that people are cheering for AMD for providing (at this point) a technically and economically better product, and hating on Intel for being a fat cat. The pendulum may swing back sooner or later, both technically/economically and public opinion wise.

I don't know much about Itaniumm, but that was a server architecture, right? That target platform would made it difficult to achieve the same performance per watt as the mobile focused ARM chips.

> we're also going to see someone give VLIW another shot

Dunno why people would keep thinking this is a good idea, but if someone wants to try eating it with a new VLIW design yet again, I’m always down for some popcorn.

Dynamically finding ILP at instruction dispatch time is always going to be smarter than a compiler trying to guess at compile time. IMO, it’s worth the area. Even if you assume the compiler gets it right and finds tons of ILP, it’ll get it wrong for the next hardware rev when your core inevitably changes and you have to break apart your VLIW instructions and get ILP back dynamically anyway. To say nothing of shared pipelines in an SMT processor, where VLIW basically runs counter to SMT and the only way to know which units are going to be available on a specific cycle is during runtime.

> and they're going to succeed this time.

I don’t see any reason why VLIW would succeed more in future attempts than in past attempts.

Even if compiler-only ILP is doomed to fail, maybe VLIW optimists are just hoping something useful might come out of everything we've learned?

For example, compilers already model the CPU's pipeline and ILP capacity to inform instruction selection. VLIW designs are an attempt to make that cooperation more explicit, similar in spirit to branch/prefetch hints. Maybe there's still a way to do that well?

And re: microarchitectural changes in the next hardware rev: https://news.ycombinator.com/item?id=25237056

These ideas might ultimately fail, but they seem worth looking in to, at least.

I think you are correct that there is a section of the field enchanted by the idea of VLIW and desperately hoping to justify any possible reason why building these chips was less of a bad notion than they’ve turned out to be each and every time.

I don’t think we’re really learning much by pretending building a new one is a good idea. Or that the last efforts had much value.

No one is saying don’t make progress on compilers. Look around you and you’ll see the things you just referenced already exist in practice in production today. (Among others: compiler/architecture co-design is a well established and fertile area of work. Compiling to intermediate formats which specialize for a device later is in use to some degree in App Store, which keeps programs in an intermediate format and thins binaries down to specific slices on demand for iOS devices, etc.) None of these technologies justify building a new VLIW chip or have frankly much to do with those efforts. The best thing we could learn from the huge amount of effort that’s gone into VLIW architectures is actually learn the lesson that in front of us, demonstrated repeatedly, that unless something substantial changes, VLIW does not produce a better architecture for processor cores and the assumption that it would was wrong.

> Intel tried to be brave with Itanium

Intel tried to be brave with the 432.

And failed.

The 8086 was rushed as a stopgap. It was never intended as a serious design.

Intel tried to be a little brave with the 286.

And failed.

Intel tried to be brave with the i860.

And failed.

Intel tried to be brave with Itanium.

And failed.

In the meantime Intel have made countless of billions with souped up 8086s. And we're stuck with them. Or were.

Reply on news.ycombinator.com