4 ms·

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.

by MBCook 2mo ago

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.

oofbey 2mo ago
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.
- geerlingguy 2mo ago
  I run a number of other benchmarks for a better comparison (linked from my blog post: https://github.com/geerlingguy/sbc-reviews/issues/111 https://github.com/geerlingguy/sbc-reviews/issues/111). The Intel chip holds its own for multicore in less bursty workloads, where the fans help.
  - AnthonyMouse 2mo ago
    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.
    - geerlingguy 2mo ago
      It's funny, too — in my testing with Asahi Linux, some benchmarks ran better on Linux than macOS on Apple Silicon!
- Archit3ch 2mo ago
  > consumers basically never use fp64 any more They do in audio processing. ;)
  - bobmcnamara 2mo ago
    I usually use fp32 for the sole reason I can fit twice as many ~24 bit samples per register.
- pclmulqdq 2mo ago
  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.
  - pertymcpert 2mo ago
    Which workloads?
    - pclmulqdq 2mo ago
      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.
      - hajile 2mo ago
        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.
        pclmulqdq 2mo ago
        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.
      - pertymcpert 2mo ago
booi 2mo ago
[dead]
AnthonyMouse 2mo ago
> 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.
- deleted 2mo ago
  [deleted]

by MBCook 2mo ago

oofbey 2mo ago

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.

geerlingguy 2mo ago
I run a number of other benchmarks for a better comparison (linked from my blog post: https://github.com/geerlingguy/sbc-reviews/issues/111 https://github.com/geerlingguy/sbc-reviews/issues/111). The Intel chip holds its own for multicore in less bursty workloads, where the fans help.
- AnthonyMouse 2mo ago
  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.
  - geerlingguy 2mo ago
    It's funny, too — in my testing with Asahi Linux, some benchmarks ran better on Linux than macOS on Apple Silicon!
Archit3ch 2mo ago
> consumers basically never use fp64 any more They do in audio processing. ;)
- bobmcnamara 2mo ago
  I usually use fp32 for the sole reason I can fit twice as many ~24 bit samples per register.
pclmulqdq 2mo ago
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.
- pertymcpert 2mo ago
  Which workloads?
  - pclmulqdq 2mo ago
    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.
    - hajile 2mo ago
      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.
      - pclmulqdq 2mo ago
        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.
    - pertymcpert 2mo ago

booi 2mo ago

[dead]

AnthonyMouse 2mo ago

> 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.

deleted 2mo ago
[deleted]