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

Ask HN: Why hasn't x86 caught up with Apple M series?

news.ycombinator.com

Post reply on HN
Print view View original

461–470 of 640 posts

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#461

Post by int_19h »

creshal wrote: post #172
pzo wrote: post #142

Earlier quoted context omitted.

> most of which comes down to using the CPU as little as possible. it least on mobile platform apple advocate the other way with race to sleep - do calculation as fast as you can with powerful cores so that whole chip can go back to sleep earlier and more often take naps.

Intel stipulated the same under the name HUGI (Hurry Up and Go Idle) about 15 years ago when ultrabooks were the new hot thing. But when Apple says it, software devs actually listen.

Peer pressure. When everybody else does it and you don't, your app sticks out like a sore thumb and makes users unhappy.

The other aspect of it is that paid software is more prevalent in macOS land, and the prices are generally higher than on Windows. But the flip side of that is that user feedback is taken more seriously.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#462

Post by GuB-42 »

Plenty of reasons, but the big one would be integration, especially RAM. Apple M series processors are exclusively designed for Apple products running the Apple OS, none of them extensible. It means it can be optimized for that use case.

RAM in particular can be a big performance bottleneck, Apple M as way better bandwidth than most x86 CPUs, having well specified RAM chips soldered right next to the CPU instead of having to support DIMM modules certainty helps. AMD AI MAX chips, which also have great memory bandwidth and the most comparable to Apple M also use soldered RAM.

Maybe some details like ARM having a more efficient instruction decoder plays a part, but I don't believe it is that significant.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#463

Post by int_19h »

diggan wrote: post #414
fafhnir wrote: post #201

I have the same experience here with my MacBook Air M1 from 2020 with 16GB RAM and 512GB SSD. After three years, I upgraded to a MacBook Pro with M3 Pro, 36GB of RAM, and 2TB of storage. I use this as my main machine with 2 displays attached via a TB4 dock. I'm working in IT and I get all new machines for our company over my desk to check them, and I observed the exact same points as the OP. The new machines are eith…

> Well, your mileage may vary, but IMHO there is no alternative to a Mac nowadays, even if you want to use Linux or Windows. I guess I'd slightly change that to "MacBook" or similar, as Apple are top-in-class when it comes to laptops, but for desktop they seem to not even be in the fight anymore, unless reducing power consumption is your top concern. But if you're aiming for "performance per money spent", there isn't…

Mac Studio is pretty good on everything except raw GPU speed. Which depending on your use cases may be completely irrelevant.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#464

Post by nartho »

alt227 wrote: post #430
nartho wrote: post #425

Earlier quoted context omitted.

Music production is overwhelmingly Apple. It comes from the fact that Protools was Mac only until the late 2000s and Logic Pro, Apple's DAW and alternative to Protools was also very popular and also Mac only. That left Cubase for windows and a few others like Ableton and less popular DAWs like Reaper, fruity loops etc. Today there are a few more options for Windows like Studio One who is very good though Add to that…

> That left Cubase for windows When I was at music college doing production courses, they exclusively taught Cubase on windows.

Yes, for a while that was the only "serious" option for Windows

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#465

Post by fluoridation »

hajile wrote: post #451
fluoridation wrote: post #334

Earlier quoted context omitted.

>If x86 just officially said “we’re cutting off 32-bit legacy” one day (similar to how Apple did), they could toss out 95% of the crap that makes them power inefficient. Where do you get this from? I could understand that they could get rid of the die area devoted to x86 decoding, but as I understand it x86 and x86-64 instructions get interpreted by the same execution units, which are bitness blind. What makes you th…

Intel has proposed APX to address this. It does away with some of the 32-bit garbage that complicates design for no good payoff. Most importantly, it increases from 16 to 32 registers and allows 3-register instructions (almost all x86 instructions are 1-register or 2-register instructions). This would strip out tons of MOV instructions which was proven with AMD64 to have a decent impact on performance. Reduced I-Cach…

>This would strip out tons of MOV instructions which was proven with AMD64 to have a decent impact on performance.

Sure, but the topic is optimizing power efficiency by removing support for an instruction set. That aside, if an instruction isn't very performant, it isn't much of an issue per se. It just means it won't get used much and so chip design resources will be suboptimally allocated. That's a problem for Intel and AMD, and for nobody else.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#466

Post by hajile »

zipityzi wrote: post #284
BirAdam wrote: post #250

First, Apple did an excellent job optimizing their software stack for their hardware. This is something that few companies have the ability to do as they target a wide array of hardware. This is even more impressive given the scale of Apple's hardware. The same kernel runs on a Watch and a Mac Studio. Second, the x86 platform has a lot of legacy, and each operation on x86 is translated from an x86 instruction into RI…

This seems mostly misinformed. 1) Apple Silicon outperforms all laptop CPUs in the same power envelope on 1T on industry-standard tests: it's not predominantly due to "optimizing their software stack". SPECint, SPECfp, Geekbench, Cinebench, etc. all show major improvements. 2) x86 also heavily relies on micro-ops to greatly improve performance. This is not a "penalty" in any sense. 3) x86 is now six-wide, eight-wide,…

2. uops are a cope that costs. That uop cache and cache controller uses tons of power. ARM designs with 32-bit support had a uop cache, but they cut it when going to 64-bit only designs (look at ARM a715 vs a710) which dramatically reduced frontend size and power consumption.

3. The claim was never "stuck on 4-wide", but that going wider would incur significant penalties which is the case. AMD uses two 4-wide encoders and pays a big penalty in complexity trying to keep them coherent and occupied. Intel went 6-wide for Golden Cove which is infamous for being the largest and most power-hungry x86 design in a couple decades. This seems to prove the 4-wide people right.

4. This is only partially true. The ISA impacts which designs make sense which then impacts cache size. uop cache can affect L1 I-cache size. Page size and cache line size also affect L1 cache sizes. Target clockspeeds and cache latency also affect which cache sizes are viable.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#467

Post by int_19h »

noisy_boy wrote: post #456

To those who are using the newer MacBook pros, how easy and seamless it is to run Linux on it via Parallels etc without going all the way to Asahi etc? Like if i'm super comfortable with Linux, can I just get near native Linux desktop experience and forget that all of it is running on top of MacOS?

It's pretty seamless, but you can't really get the macOS UI out of the picture entirely. You can run it fullscreen, sure, but even then there are still some shortcuts that are going to be handled by macOS, and also multiple displays etc.

OTOH if you're fine with macOS GUI but you want something like WSL for CLI and server apps, there's https://lima-vm.io

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#468

Post by int_19h »

mkl wrote: post #138
BlindEyeHalo wrote: post #112

Earlier quoted context omitted.

The macbook air doesn't even have a fan. I don't think you could built a fan-less x86 laptop.

Sure you can. There are a bunch listed in this article: https://www.ultrabookreview.com/6520-fanless-ultrabooks/ Fanless x86 desktops are a thing too, in the form of thin clients and small PCs intended for business use. I have a few HP T630s I use as servers (I have used them as desktop PCs too, but my tab-hoarding habit makes them throttle a bit too much for my use - they'd be fine for a lot of people).

My experience with fanless Intel is that they tend to be rather sluggish for desktop GUI use, though. Which doesn't seem to be an issue with Macbook Air.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#469

Post by fluoridation »

delfinom wrote: post #418
fluoridation wrote: post #334

Earlier quoted context omitted.

>If x86 just officially said “we’re cutting off 32-bit legacy” one day (similar to how Apple did), they could toss out 95% of the crap that makes them power inefficient. Where do you get this from? I could understand that they could get rid of the die area devoted to x86 decoding, but as I understand it x86 and x86-64 instructions get interpreted by the same execution units, which are bitness blind. What makes you th…

From what I understood. It's not "32-bit instructions" that are the problem. It's a load of crap associated with those 32-bit processors. There's more to x86 than just the instruction set. Operating systems need to carry the baggage in x86 if they want to allow users to run on old and new processors.

Before addressing anything else, "software is complicated by having to support legacy stuff" is not a valid argument for removing that support at the hardware level. If a software developer wishes to design their software without that legacy support, that's their prerogative.

>Operating systems need to carry the baggage in x86 if they want to allow users to run on old and new processors.

What do you mean by this exactly? Are you talking about hybrid execution like WOW64, or simple multi-platform support like the Linux kernel?

WOW64 is irrelevant as far as power efficiency is concerned if the user doesn't run any x86 software. If the user is running x86 software, that's a reason not to remove that support.

Multi-platform support shouldn't have an effect on power efficiency, beyond complicating the design of the system. Saying that the Linux kernel should stop supporting x86 so x86-64 can be more power-efficient is like saying that it should stop supporting... whatever, PowerPC, for that same reason. It's a non sequitur.

Re: Ask HN: Why hasn't x86 caught up with Apple M series?

#470

Post by hajile »

bsenftner wrote: post #257

Well, there is a major architectural reason why the entire M-series appears to be "so fast" and that is the unified memory, which completely eliminates the buffer-to-buffer data copying that is probably over half of what a non-unified memory architecture chip is doing at any given time. M-series chips have an architecture that completely eliminates data copying, just reference the data where it is, and you're done.

Apple made a big deal about this, but other iGPUs have done this for years.
Post reply on HN