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

91–100 of 110 posts

Re: Intel: Winning and Losing

#91

Post by jagged-chisel »

bombcar wrote: post #54
jagged-chisel wrote: post #33

Earlier quoted context omitted.

OT from TFA, so high jacking your thread … I don’t recall if there was ever a difference between “abort” and “fail.” I could choose to abort the operation, or tell it … to fail? That this is a failure? ¯\_(ツ)_/¯

Take reading a file from disk. Abort would cancel the entire file read. Retry would attempt that sector again. Fail would fail that sector, but the program might decide to keep trying to read the rest of the file. In practice abort and fail were often the same.

Makes sense. Maybe I ran across a proper use a time or two back then and just don’t remember. But the two being the same was the overwhelming experience.

Re: Intel: Winning and Losing

#92

Post by adgjlsfhk1 »

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…

I don't think Apple's battery life wins are primarily from isa. I think it's largely from better target and process optimization/ecosystem control. Intel (and somewhat AMD) make most of their money in servers where what matters is performance/watt in a 100% loaded system. they also are designing for jdec RAM and pcie connectivity (and lots of other industry standards). most of Apple's efficiency advantage comes at the edges, lowering max clock speed, integrating the ram to save power, using custom SSDs where the controller is on the CPU etc.

Re: Intel: Winning and Losing

#93

Post by phire »

inkyoto wrote: post #77
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…

> In fact, I actually think need to continue supporting the legacy x86 ISA was a massive advantage to Intel . I think this is a myth that Intel (or somebody else) has invented in an attempt to save face. Legacy x86 instructions could have been culled from the silicon and implemented in the software as emulation traps – this has been done elsewhere nearly since the first revised CPU design came out. Since CPU's have b…

We aren't talking about legacy instructions. Those have all been culled and replaced by microcode (in fact, most of them were always microcode from the very first 8086, they just never got non-microcoded versions thought the 286, 386, 486, pentium era).

We are talking about how the whole ISA is legacy. How the basic structure of the encoding is complex and hard to decode. How the newer instructions get longer encodings. Or things which can be done with a single instruction on some RISC ISAs take 3 or 4 instructions.

Re: Intel: Winning and Losing

#94

Post by phire »

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…

> 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 done the following cycle, but the pre-decoder has already moved upto 4 instructions forwards, so the whole pipelined decoder can maintain 4 instructions per cycle on some code.

This pre-decode approach does have limits. Due to propagation delays, 4 instructions over 16 bytes is probably the realistic limit that you can push it (while Apple can easily do 8 instructions over 32 bytes). Intel's Golden Cove did finally push it to 6 instructions over 32 bytes, but I'm not sure that's worth it.

Intel's Skymont shows the way forwards. It only uses 3-wide decoders, but it has three of them running in parallel, leapfrogging over each other. They use the branch predictor to start each decoder running at a future instruction boundaries (inserting dummy branches to break up large branchless blocks). Skymont can maintain 9 instructions per cycle, which is more than the 8-wide that Apple currently is using. And unlike the previous "parallel pre-decode in a single cycle", this approach is scalable. Nothing stopping Intel adding a fourth decoder for 12 instructions per cycle, or a fifth decoder for 15. AMD is showing signs of going down the same path, zen5 has two 4-wide decoders though they can't work on the same thread, yet.

Re: Intel: Winning and Losing

#95

Post by aurizon »

scrubs wrote: post #74
aurizon wrote: post #18

Intel is a failed monopolist, unlike Apple! So is IBM with MCA, micro-channel-architecture

Well not quite... Apple/next spent plenty of years not making money ... their major markets where students and graphics design which don't spent huge. Microsoft world was making piles of $ selling business apps. Yes, they eventually got it right post-Newton after spending a lot of time on the outside of the sp500.

Yes, Blackberry was run by dinosaurs - they had a chance and wasted it = Apple ecosystem absorbed all, save for google/Android who stayed free

Re: Intel: Winning and Losing

#96

Post by arp242 »

rubatuga wrote: post #75
ethan_smith wrote: post #66

Earlier quoted context omitted.

Intel selling XScale to Marvell in 2006 was their pivotal strategic error - they abandoned a viable ARM-based solution right before the smartphone explosion, betting everything on x86 compatibility. Atom's power inefficiency compared to ARM designs then left them completely unprepared for the mobile revolution, costing them the entire smartphone/tablet market.

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.

Re: Intel: Winning and Losing

#97

Post by arp242 »

icedchai wrote: post #85
bsder wrote: post #46

Earlier quoted context omitted.

> i think Itanium is worthy of discussion in this era too Itanium was a massive technical failure but a massiver business success. Intel spent a gigabuck and drove every single non-x86 competitor out of the server business with the exception of IBM.

I remember the plethora of Unix workstations and servers in the 90's: Sun, HP, SGI, DEC, IBM. I'm skeptical Itanium killed them. It was software: plain old x86 and Linux killed them.

In addition, Apple probably took some of the Unix workstation market. In the 90s everyone was using SGI for graphics stuff, but ten years later that had shifted quite a bit to Apple and OS X.

Re: Intel: Winning and Losing

#98

Post by TheAmazingRace »

icedchai wrote: post #90
buescher wrote: post #88

Earlier quoted context omitted.

The Atari ST and similar machines like the Amiga and compact Macintoshes other than the SE/30 were not its competition, any more than the Sega Genesis was. Its immediate competition included Sun and SGI workstations (as well as other workstations) and the Mac II series - and for specific tasks, loaded 386DX and 486DX PCs. Sun was pivoting at that time to the SPARC platform and SGI to the MIPS platform, both away from…

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 seriously enough. I say this as I wistfully eyeball the lonely 68060 CPU I have sitting on my desk for a future project...

Re: Intel: Winning and Losing

#99

Post by inkyoto »

phire wrote: post #93
inkyoto wrote: post #77

Earlier quoted context omitted.

> In fact, I actually think need to continue supporting the legacy x86 ISA was a massive advantage to Intel . I think this is a myth that Intel (or somebody else) has invented in an attempt to save face. Legacy x86 instructions could have been culled from the silicon and implemented in the software as emulation traps – this has been done elsewhere nearly since the first revised CPU design came out. Since CPU's have b…

We aren't talking about legacy instructions. Those have all been culled and replaced by microcode (in fact, most of them were always microcode from the very first 8086, they just never got non-microcoded versions thought the 286, 386, 486, pentium era). We are talking about how the whole ISA is legacy. How the basic structure of the encoding is complex and hard to decode. How the newer instructions get longer encodin…

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 phasing out the x86 ISA and replacing it with i960, but there was a change of plans, and they went all in with the 80486 CPU. i960 remained around in embedded and defence applications.

Intel also had their own hybrid VLIW/RISC design, i860, which preceded Itanium, and which they did not know what to do. Similarly, they faced the same issue with compilers of the day not being to produce fast code.

Re: Intel: Winning and Losing

#100

Post by phire »

inkyoto wrote: post #99
phire wrote: post #93

Earlier quoted context omitted.

We aren't talking about legacy instructions. Those have all been culled and replaced by microcode (in fact, most of them were always microcode from the very first 8086, they just never got non-microcoded versions thought the 286, 386, 486, pentium era). We are talking about how the whole ISA is legacy. How the basic structure of the encoding is complex and hard to decode. How the newer instructions get longer encodin…

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 industry standard. And "replace" is kind of over stating it, there was no plan for any compatibility, not even source compatibility. It's more that they were planning for iAPX 432 to take the "workstation CPU" spot on their product chart that was currently occupied by the 8086.

By the time the i960 was in development, x86 was so entrenched that I really doubt there could have been any serious thoughts of replacing x86 with something that wasn't fully backwards compatible.

And we know that when Intel did try to replace x86 with Itanium, they went with a hardware backwards compatibility mode.

> I was actually commenting on the need to support aspect being a myth.

Yes, you have a point that it should have been possible to replace x86 with a software emulation approach.

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.

But the PC didn't really have an owner. IBM had lost control of it. You could argue that Microsoft had control, but they didn't have enough control (especially with DOS. Most DOS programs were bypassing DOS to some extent or another and directly accessed hardware). Intel certainly didn't have enough control to transition to another arch.

(The PC had such high demands for backwards compatibility that even the Pentium Pro ran into issue. It worked, but it simply wasn't fast enough when executing instructions with 16-bit operands. Attempting to run DOS or win95 apps would be slower than a 486. So the Pentium Pro was limited to the market of Windows NT workstations running Apps with full 32-bit code. Intel had to fix this with the Pentium II before they could sell the P6 arch outside of the workstation market.)

Intel didn't even have control over x86 itself. Other companies were already making competing CPU designs that were faster than Intel's own. If Intel didn't keep releasing faster x86 designs, then someone else would steal all of their market share. Intel were more or less forced to keep releasing faster native x86 designs, or they would lose what little control they did have.

Post reply on HN