Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Neither macOS nor Windows use a hardware-based accelerator for memory compression. It's all done in software. Linux zram uses Intel QAT but that's only available on a limited number of processors.

You seem to be under the mistaken impression that Microsoft cannot gear Windows to act differently based on the installed hardware (or processor). That's quite untrue.



It was software on Intel but they presumably added instructions with the intention of using them:

https://asahilinux.org/docs/hw/cpu/apple-instructions/

> You seem to be under the mistaken impression that Microsoft cannot gear Windows to act differently based on the installed hardware (or processor).

Definitely not - my point is simply that all of these things are harder and take longer if they have to support multiple implementations and get other companies to ship quality implementations.


> Definitely not - my point is simply that all of these things are harder and take longer if they have to support multiple implementations and get other companies to ship quality implementations.

What's your source for it is "harder" or "takes longer"? #ifdef is a quite well known processor directive to developers and easy to use.


> What's your source for it is "harder" or "takes longer"?

Windows devices’ power management and battery life has been behind Apple since the previous century? If you think hardware support is a simple #ifdef, ask yourself how a compile-time flag can detect firmware updates, driver versions, or flakey hardware. It’s not that Apple’s hardware is perfect but that those are made by the same company so you don’t get Dell telling you to call Broadcom who are telling you to call Microsoft.


> Neither macOS nor Windows use a hardware-based accelerator for memory compression.

Not true.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: