Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel: Winning and Losing

abortretry.fail

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Intel: Winning and Losing

#101

Post by ahartmetz »

vlovich123 wrote: post #82
phire wrote: post #67

Earlier quoted context omitted.

> is they promoted the myth that ISA has no impact on performance IMO, Intel (and AMD) did prove the impact of a legacy ISA was low enough to not be a competitive disadvantage. Not zero, but close enough for high-performance designs. In fact, I actually think the need to continue supporting the legacy x86 ISA was a massive advantage to Intel. It forced them to go down the path of massively out-of-order μarches at a p…

> IMO, Intel (and AMD) did prove the impact of a legacy ISA was low enough to not be a competitive disadvantage. Not zero, but close enough for high-performance designs. And Apple proved that in fact it was a significant problem once you factored into account performance per watt allowing them to completely spank AMD and Intel once those hit a thermal limit. There’s a benefit from being able to decode and dispatch mu…

Reportedly, the decoder is like 10-20% of the power budget of Ryzen CPUs, so that rather contradicts that the ISA is the main issue that makes Ryzen's efficiency worse than Apple's A and M cores.

Re: Intel: Winning and Losing

#102

Post by inkyoto »

phire wrote: post #100
inkyoto wrote: post #99

Earlier quoted context omitted.

I was actually commenting on the need to support aspect being a myth. x86 is not a legacy, it is a legacy of legacies as the x86 ISA ascends all the way to 8008 via 8080 at least as a spiritual predecessor even if it can't directly execute the 8008 binary code. Intel also had their own, indigeneous, RISC design – i960, which was a very good RISC design. At some point – if I am not mistaken – Intel contemplated phasin…

> if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans, I don't think there was ever any serious thought about replacing x86 with i960 (at least nothing publicly). There was a serious plan to replace x86 with the iAPX 432, which is the predecessor to the i960, but those plans all predated x86 becoming a run-away success when the IBM PC became an…

I can't readily find the original reference where I read it, but one source[0] does allude that it was a real possibility:

«At the time, the 386 team felt that they were treated as the "stepchild" while the P7 [80960] project was the focus of Intel's attention. This would change as the sales of x86-based personal computers climbed and money poured into Intel. The 386 team would soon transform from stepchild to king».

And, yes, the histories of iAPX 432 and 80960 are so closely intertwined, that in many ways the 960 can be considered a design successor of the 432.

> But the only person who can really do that is the platform owner. Apple were quite successful with their 68k to PowerPC transition. And the PowerPC to x86 transition. And the x86 to Aarch64 transition. But that transition really needs to be done by the platform owner.

I wholeheartedly and vehemently agree with you on this – full platform ownership and the control of the entire vertical is key to being able to successfully execute an ISA transition. Another success story is, of course, IBM with iSeries (nèe AS/400) and zSeries (nèe 360/370/390), albeit their approach is rather different.

[0] https://www.righto.com/2023/07/the-complex-history-of-intel-...

Re: Intel: Winning and Losing

#103

Post by t312227 »

high_na_euv wrote: post #30
fidotron wrote: post #29

The core problem at Intel is they promoted the myth that ISA has no impact on performance to such a degree they started fully believing it while also somehow believing their process advantage was unassailable. By that time they'd accumulated so many worthless departments that turning it around at any time after 2010 was an impossibility. You could be the greatest business leader in history but you cannot save Intel w…

https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter

hello,

ah ... thank you!!

i was searching for exactly the interview with jim keller, which is referenced in the chips&cheese article.

again: thanks for posting the article ... i didn't remember, it was anandtech ;))

"[Arguing about instruction sets] is a very sad story."

* https://www.anandtech.com/show/16762/an-anandtech-interview-...

cheers a..z

Re: Intel: Winning and Losing

#104

Post by icedchai »

TheAmazingRace wrote: post #98
icedchai wrote: post #90

Earlier quoted context omitted.

There were some high end Ataris and Amigas (Atart TT 030, Amiga 3000, etc.) but they came out a bit later. There was even the A3000UX that ran a Unix port! Still, I agree. The 68K workstation was essentially obsolete by the time NeXT shipped. Sun was shipping early Sparc systems around the same time. The writing was on the wall. No wonder they didn't stick with their own hardware for very long.

Jon Rubenstein was said to have been cooking up a NeXT computer prototype based on Motorola 88k chips and would have been a serious contender in the workstation market, had it been realized sooner. Sadly, it ended up getting canceled right around the time NeXT became a software-only shop. Honestly, Motorola is entirely to blame for losing out on the workstation market. They iterated too slowly and never took Intel se…

That would've been cool! The NeXT hardware was interesting. I have a Turbo slab in my retro collection.

Yeah, it seems Motorola lost their lead with the 68040. Intel was getting huge clock speed gains with the later 486/DX2, DX4, etc. From what I recall, a similarly clocked 040 was faster than a 486 on most benchmarks, but there was simply no way to compete with Intel's high clocks.

Re: Intel: Winning and Losing

#105

Post by reginald78 »

arp242 wrote: post #96
rubatuga wrote: post #75

Earlier quoted context omitted.

Actually atom was very efficient, but they tended to pair it with a horribly inefficient southbridge that would idle at many times the full CPU power draw (2-3W or more)

I had an Atom 330 server, worked really well. It came with came with one little very noisy fan ... on the chipset. The CPU just had a small heatsink. It was okay for my server use case, but the entire situation was pretty silly.

It seems clear Intel was either intentionally trying to hamstring this market or at least trying to make up margin by bundling it with an obsolete process chipset.

Re: Intel: Winning and Losing

#106

Post by BeFlatXIII »

bsder wrote: post #47
Demiurge wrote: post #8

Earlier quoted context omitted.

I've always wondered, how do some smart companies, or smart film directors, or smart musicians can fail so hard? I understand that, sometimes, it's a matter of someone abusing a project for personal gain. Some CEOs, workers just want to pitch, pocket the money, and move on, but the level of absurdity of some of the decisions made are counter-productive the 'get rich quick' scheme too. I think there are self perpetuat…

> This is probably why having some churn with the outside world, and also understanding what is the periphery of the outside, unbiased opinion is, is very important. Maximally efficient is minimally robust. Squeezing every penny out of something means optimizing perfectly for present conditions --no more, no less. As long as those conditions shift slowly, slight adjustments work. If those conditions shift suddenly th…

The same is true for biological evolution. During times of rapid catastrophe, the biggest, baddest, and most intelligent are the first to die out because their caloric needs are unsustainable in the new environment. It’s the mediocre and adaptable who survive to restart the specialization process.

Re: Intel: Winning and Losing

#107

Post by phire »

ahartmetz wrote: post #101
vlovich123 wrote: post #82

Earlier quoted context omitted.

> IMO, Intel (and AMD) did prove the impact of a legacy ISA was low enough to not be a competitive disadvantage. Not zero, but close enough for high-performance designs. And Apple proved that in fact it was a significant problem once you factored into account performance per watt allowing them to completely spank AMD and Intel once those hit a thermal limit. There’s a benefit from being able to decode and dispatch mu…

Reportedly, the decoder is like 10-20% of the power budget of Ryzen CPUs, so that rather contradicts that the ISA is the main issue that makes Ryzen's efficiency worse than Apple's A and M cores.

I looked around and couldn't find anything about Ryzen decoding power conniption. I'm only aware of one report for x86 decode power consumption, [1] and there are quite a few problems with trying to use it to justify that conclusion.

First, it's covers Intel Haswell, which is "not ryzen", it's not even AMD. Plus, Haswell is 12 years old at this point, how much relevance does it even have to modern Intel CPUs?

Second, the "instruction decoders" power zone was only 10%, not 20%. And still reported 3% on workloads that used very few instructions and always hit the uop cache. So really we are talking about 7% overhead for decoding instructions. They do speculate that other workloads use more power (they only tested two workloads), as the theoretical instruction throughput might be double. (which is where I suspect you got the 20% from), but they provide no evidence for that, and double the throughput doesn't mean double the power consumption. And double 7% + 3% base would be 17% at most.

Third. Intel doesn't publish any details about what this "instruction decoder" zone actually covers. It's almost certainly more just the "decoding x86" part. Given there are only four zones, I'm almost certain this zone covers the entire frontend, which includes branch prediction, instruction fetch, the stack engine. It might include register renaming too. Maybe instruction TLB lookups? I am reasonably sure it includes the (dynamic) power cost of accessing the L1i cache too.

So this 7% power usage is way more than just the decoding of decoding 86%. It's the entire frontend.

Finally. I haven't seen any power numbers for the front end of an equivalent ARM processor (like Apple's M1). For all we know, they are also using 7% of their power budget to fetch ARM instructions from the L1 cache, decode them, do branch prediction, do all the fancy front-end stuff. The 7% number isn't x86 overhead as many people imply, it's just the cost of running Haswell's frontend.

Without anything else to compare to, this 7% number is worthless. It's certainly an interesting paper, I don't have any major criticisms, but it simply cannot be used to support (or disprove) any arguments about the overhead of x86 decoding.

[1] https://www.usenix.org/system/files/conference/cooldc16/cool...

Re: Intel: Winning and Losing

#108

Post by phire »

inkyoto wrote: post #102
phire wrote: post #100

Earlier quoted context omitted.

> if I am not mistaken – Intel contemplated phasing out the x86 ISA and replacing it with i960, but there was a change of plans, I don't think there was ever any serious thought about replacing x86 with i960 (at least nothing publicly). There was a serious plan to replace x86 with the iAPX 432, which is the predecessor to the i960, but those plans all predated x86 becoming a run-away success when the IBM PC became an…

I can't readily find the original reference where I read it, but one source[0] does allude that it was a real possibility: « At the time, the 386 team felt that they were treated as the "stepchild" while the P7 [80960] project was the focus of Intel's attention. This would change as the sales of x86-based personal computers climbed and money poured into Intel. The 386 team would soon transform from stepchild to king…

> but one source[0] does allude that it was a real possibility

That doesn't really suggest an intention to replace. To me that seems more of a hope that x86 would fade into irrelevance on its own, beaten down by superior RISC ISAs.

--------------

It is interesting to consider what a transition away from x86 would have looked like.

I think the best chance would have been something lead by Microsoft in the early 90s. The 386 version of Windows 3.0 was already virtualising both DOS and Win16 code into their own isolated VMs. If you added a translation layer for 16-bit x86 code to those VMs, then you could probably port windows to any host CPU arch.

I think we are talking about a world where 486 class CPUs never arrived, or they preformed horribly and the pentium was canceled.

But it's a small window. In 1990, it was very rare to see 32bit x86 code. 32-bit DOS extenders were only just starting to be a thing. Windows didn't support 32-bit userspace until 1993. The main 32-bit code anyone was running in 1990 was the windows 3.0 kernel itself. By 1992, it was common for DOS games to use DOS Extenders, and the transition would have required a 32-bit x86 translation layer too.

These RISC PC compatibles would lost the ability to boot directly into real-mode DOS, but would have run DOS just fine inside a windows DOS VM.

It should have been possible to get good hardware compatibility too. Windows 3.0 can already run DOS drivers inside a DOS VM, adding cpu translation shouldn't have caused issues. With motherboard support, it should have been possible to support most existing ISA/EISA/VLB cards.

Re: Intel: Winning and Losing

#109

Post by vlovich123 »

phire wrote: post #94
vlovich123 wrote: post #82

Earlier quoted context omitted.

> IMO, Intel (and AMD) did prove the impact of a legacy ISA was low enough to not be a competitive disadvantage. Not zero, but close enough for high-performance designs. And Apple proved that in fact it was a significant problem once you factored into account performance per watt allowing them to completely spank AMD and Intel once those hit a thermal limit. There’s a benefit from being able to decode and dispatch mu…

> having to emulate that through heuristically guessing at instruction boundaries and backtrack when you make a mistake Intel/AMD don't use heuristics-based decoding, or backtracking. They can decode 4 instructions in a single cycle. They implement this by starting a pre-decode at every single byte offset (within 16 bytes) and then resolving it to actual instructions at the end of the cycle. The actual decode is then…

You're arguing semantics IMHO. In my mind speculatively decoding every single byte offset & then resolving at the end of the cycle which to take is a form of heuristic execution because the heuristic is "decode all possible executions". And 4 vs 8 is a pretty sizeable difference. Moreover, the pre-decoder requiring knowing the op-codes at the end means all instruction decodes are serialized on decoding 16 instructions whereas Apple can just decode each op independently & only decodes 8.

Re: Intel: Winning and Losing

#110

Post by phire »

vlovich123 wrote: post #109
phire wrote: post #94

Earlier quoted context omitted.

> having to emulate that through heuristically guessing at instruction boundaries and backtrack when you make a mistake Intel/AMD don't use heuristics-based decoding, or backtracking. They can decode 4 instructions in a single cycle. They implement this by starting a pre-decode at every single byte offset (within 16 bytes) and then resolving it to actual instructions at the end of the cycle. The actual decode is then…

You're arguing semantics IMHO. In my mind speculatively decoding every single byte offset & then resolving at the end of the cycle which to take is a form of heuristic execution because the heuristic is "decode all possible executions". And 4 vs 8 is a pretty sizeable difference. Moreover, the pre-decoder requiring knowing the op-codes at the end means all instruction decodes are serialized on decoding 16 instruction…

Oh, I see what you are saying. I don't consider it to be a heuristic because it's simply bruteforcing it. IMO a heuristic needs improve over brute force.

> And 4 vs 8 is a pretty sizeable difference.

True, but x86 was doing four instruction 20 years ago. As I mentioned the current state of the art (in a shipping product) is 9, and 9 is larger than 8. Importantly, this Skymont of leapfrogging decoders approach is scalable.

> whereas Apple can just decode each op independently & only decodes 8.

Apple isn't as free from serialisation as you suggest. Like X86, many instructions decode to multiple uops. According to research [1] instructions which decode to two uops are common and a few decode to as many as 12 uops.

It also does instruction fusion, two neighbouring instructions can sometimes decode into a single uop. This all means that there is plenty of serialisation within Apple's decoder. And branching also creates serialisation.

It's just not as simple as independently decoding eight instructions into eight uops every cycle. Simpler than what x86 implementations need to do, but not as brain-dead simple as you suggest.

Actually, Skymont's approach has an advantage over Apple here, because it only needs to serialise within each 3-wide decoder.

[1] https://dougallj.github.io/applecpu/firestorm.html

Post reply on HN