Hacker News Reader

Comment by MBCook | Hacker News Reader

Apple has been working ruthlessly on battery efficiency for a long time because of the phones and their tendency to minimize battery sizes on Macs for thinness.

The exact design of the cores, how they’re scheduled, the way background stuff is handled on MacOS. All of it. The chips are made on a fantastic process too, but that alone isn’t it. For example they’ve been putting the ability to drop refresh rate really low when nothing changes to more and more of their machines.

It could be that the Intel chip is close, IDK.

But add in other motherboard components, the screen, the OS, the software and system libraries, all are optimized together to hit those numbers. And any of those alone or in combination could be part of the differences.

View on HN

I think the Top500 benchmark is biased here. It’s a supercomputing benchmark which means it’s going to heavily weight SIMD and float64 performance, which are things that rarely matter for everyday computing. SIMD has uses in the real world - image or video editing, data crunching, graphics. But consumers basically never use fp64 any more, and so many modern chips have next to zero performance on them. That could easily skew the numbers in intel’s favor.

I run a number of other benchmarks for a better comparison (linked from my blog post: https://github.com/geerlingguy/sbc-reviews/issues/111).

The Intel chip holds its own for multicore in less bursty workloads, where the fans help.

An interesting thing there is how much better the Geekbench scores are on Linux than Windows. Makes you think how the Intel/AMD chips would compare to Apple when both running the same OS. Or even just when both not being held back by Windows.

It's funny, too — in my testing with Asahi Linux, some benchmarks ran better on Linux than macOS on Apple Silicon!

> consumers basically never use fp64 any more

They do in audio processing. ;)

I usually use fp32 for the sole reason I can fit twice as many ~24 bit samples per register.

What? Pretty much every general-purpose calculation on your computer that isn’t an integer is done with FP64. AI may not use it and games may prefer FP32 for many things, but your CPU certainly does a ton of FP64 work.

Which workloads?

Literally every workload not named above. It’s the default for a non-integer number.

* Web rendering and almost all web apps (see the JS number type)

* Most things in a game not done on the GPU

* Audio processing

* Most GUI processing/rendering

* Every miscellaneous/scalar calculation these days

Believe it or not, on a CPU this adds up to a lot more than the work you get doing AI processing.

JS converts most number into 31-bit ints internally (which is why it’s so fast). GUI work often prefers int or f32.

You have a point about games, but the CPU is seldom the limiting factor.

Very few people are handling raw audio. For the rest, codec hardware beats everything else by a massive margin.

Being good at floats matters, but even float-heavy code generally has way more integers than floats making integer performance king.

Quite a lot of web rendering is done with non-integer JS Number types, aka FP64. You are right that there’s a 31-bit integer optimization, but once you have a non-integer in the mix, it’s FP64. Many GUIs some time ago would use FP32, but in 2026 there’s a lot more FP64 out there than you give credit for.

Right but I've never seen these fp64 computations show up hot in a profile. I'm not saying they're not used but most of the work in a general computer usage in terms of profiles is in scalar integer code.

> their tendency to minimize battery sizes on Macs for thinness.

Is this actually a thing? Macbook Pro goes up to 100 Wh and almost nobody goes above that because it's the highest capacity battery you don't need special permission to have in a carry on at the airport.

> But add in other motherboard components, the screen, the OS, the software and system libraries, all are optimized together to hit those numbers.

I always find this argument weird because there is so little actual "together" having anything to do with it. Are TSMC's current process nodes efficient? Yes. Can you save power by dropping the refresh rate? Yes. Do the teams doing these things need to coordinate with each other somehow rather than each doing their part independently? Not really.

Reply on news.ycombinator.com