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

Never Bet Against x86

osnews.com

Post reply on HN
Print view View original

21–30 of 124 posts

Re: Never Bet Against x86

#21

Post by beagle3 »

gaigalas wrote: post #13
trvz wrote: post #2

Seems like a silly thing to say right when x86 is getting pummelled to death by Apple and Valve, maybe slowly, but steadily, while the rest of the gang also watches on.

That is actually addressed in the article. Several architectures "pummelled" x86 before. PowerPC, for example. They did not stood the test of time though.

What they did not win was the popularity contest, mostly thanks to Windows - the Wintel market was just too massive to compete with.

But that’s changed somewhat - Apple has managed a larger mind and market share (while switching into ARM). The vast majority of uses are now available on the web, which is CPU agnostic, and there is a huge amount of open source software available.

The only things for which x86 still shines a little brighter are games, and native office. But office is mostly available on web, on Mac, and on Winarm. So games. Which aren’t big enough market mass to sustain the x86’s popularity — and is a segment (soon) under attack by Valve.

Re: Never Bet Against x86

#22

Post by mifydev »

I'm quite concerned about x86 future, but the article has a point if you read it past the title.

It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM?

I personally know that adding support for ARM devices on Linux is a huge and manual task - e.g. look at devicetree, it's a mess. There is no standard like ACPI for ARM devices, so even powering off the computer is a problem, everything is proprietary and custom.

I don't agree with the article though, x86 is dying and my worry is that ARM devices will bring an end to such an open platform like modern PCs are.

Re: Never Bet Against x86

#23

Post by beagle3 »

phendrenad2 wrote: post #8

I don't think my gaming PC will ever use an ARM core. When you want true "big iron" you want x86. Intel and AMD have a duopoly on high-performance, no-TDP-spared chips, and they aren't sharing that market with anyone. The reason ARM is making inroads in the server market is we've reached the point where cooling is a significant cost factor in server farms, so lowering TDP is starting to become a relevant factor in to…

Hardcore gamers are not a big enough market segment to sustain x86. If everyone else switches to ARM/RISC-V, games will too, eventually.

Re: Never Bet Against x86

#24

Post by bryanlarsen »

Pannoniae wrote: post #6

The future of x86 is worrying but it's nowhere dead yet. I saw the C&C article yesterday and did some research, TL;DR: - Apple took over the single-threaded crown a while ago. - ARM also caught up in integer workloads. - ARM Cortex is still behind in floating-point. - Both are behind in multithreaded performance. (mostly because there are more high-end x86 systems...) - Both are way behind in SIMD/HPC workloads. (ARM…

The performance/watt delta for M1 over contemporary x86 is massively larger than M5 vs Panther Lake. M5 and Panther Lake are roughly comparable.

So by that measure the future of x86 seems to be less troubling today than it was 5 years ago.

Re: Never Bet Against x86

#25

Post by future10se »

p_ing wrote: post #16
Pannoniae wrote: post #6

The future of x86 is worrying but it's nowhere dead yet. I saw the C&C article yesterday and did some research, TL;DR: - Apple took over the single-threaded crown a while ago. - ARM also caught up in integer workloads. - ARM Cortex is still behind in floating-point. - Both are behind in multithreaded performance. (mostly because there are more high-end x86 systems...) - Both are way behind in SIMD/HPC workloads. (ARM…

https://browser.geekbench.com/v6/cpu/15805010 I see x86 on top (the first valid result is 6841, which is x86), if that is the sole benchmark we're going to look at. You can further break that down into the individual tasks it performs, but I'm not going to :-) > - ARM generally have way bigger L1 caches, mostly due to the larger pagesize, which is a significant architectural advantage. Larger pages mean more potentia…

> https://browser.geekbench.com/v6/cpu/15805010

Not to bash on x86 or anything, but that's an outlier. Very overclocked with a compressor chiller or similar. Also the single-threaded and multi-threaded scores are the same; it's probably not stable at full load across all cores.

I don't think that's really representative of the architecture at scale, unless you're making the case for how overclockable (at great power/heat cost) x86 is.

Re: Never Bet Against x86

#26

Post by i_am_a_peasant »

beagle3 wrote: post #18
creatonez wrote: post #9

Earlier quoted context omitted.

> Valve This is a funny thing to say when Valve hasn't actually released any ARM device yet, and the Steam Deck is still fully reliant on x86. The ARM hardware they do plan to release relies on x86 emulation, which is something that historically usually doesn't pan out.

Worked very well for Apple in their transition to Apple Silicon.

for real, rosetta is crazy good

Re: Never Bet Against x86

#27

Post by davidkwast »

mifydev wrote: post #22

I'm quite concerned about x86 future, but the article has a point if you read it past the title. It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM? I personally know that adding support for ARM devices on Linux is a huge and manual…

RISC-V can be essential for this open future

Re: Never Bet Against x86

#28

Post by craftkiller »

mifydev wrote: post #22

I'm quite concerned about x86 future, but the article has a point if you read it past the title. It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM? I personally know that adding support for ARM devices on Linux is a huge and manual…

> can you even have something similar to IBM PC with ARM

Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.

Re: Never Bet Against x86

#29

Post by cardanome »

davidkwast wrote: post #27
mifydev wrote: post #22

I'm quite concerned about x86 future, but the article has a point if you read it past the title. It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM? I personally know that adding support for ARM devices on Linux is a huge and manual…

RISC-V can be essential for this open future

As far as I understand RISC-V has the same lack of standardization that ARM has, no?

Re: Never Bet Against x86

#30

Post by jmalicki »

creatonez wrote: post #9
trvz wrote: post #2

Seems like a silly thing to say right when x86 is getting pummelled to death by Apple and Valve, maybe slowly, but steadily, while the rest of the gang also watches on.

> Valve This is a funny thing to say when Valve hasn't actually released any ARM device yet, and the Steam Deck is still fully reliant on x86. The ARM hardware they do plan to release relies on x86 emulation, which is something that historically usually doesn't pan out.

The Mac silicon is nice in that it has partial x86 emulation in that it can work in x86 memory store mode.

Since they had control over the hardware, they could punt on one of the hard parts of Rosetta and bake it into Silicon.

Understanding the memory ordering requirements from binary without source and without killing performance by being overly conservative (and hell, the source itself probably has memory ordering bugs if it was only tested on x86) sounds next to impossible.

Post reply on HN