Article says:

>Neither the developer nor user appears to have access to any facility to adjust run-time policy

Which is false, there is an API for this:

https://developer.apple.com/library/archive/documentation/Pe...

There’s another runtime policy in the kernel that overrides the user policy for various reasons. That’s what the author is talking about.

For example you can force a process to run on efficiency cores by using the background QoS, but you have no way of moving that process back to performance cores other than relaunching it.

Possibly outdated now but this article on the same topic was also interesting:

https://justinfrankel.org/?article=854

gamecore sounds like a style of music I’d be really into.

(4am thoughts are sometimes intrusive.)

Also if you’re interested in this kind of thing, “operating systems in three easy pieces” was surprisingly good. https://pages.cs.wisc.edu/~remzi/OSTEP/

It’ll teach you all the history behind the OS decisions we take for granted now. I was delighted to learn that early OS’s used to have only one global lock. Sounds silly, but it’s extremely effective — HN does the same.

It has a bunch of chapters presenting these kinds of “games” user programs can play to get an advantage against the schedulers.

Also it’s $10 for instant access to a pdf. I was amazed. Buying a book is always such a hassle, except this time it was 30 seconds.

The easy part being the "get out of the way" for a full game core. Gamedevs almost always prefer "bare" metal, with free choice of librarys and structures. If there was no OS beyond the bootloop, cheerio..

My understanding is that many OS kernels into the 1980’s didn’t even have a single lock: Because the only thing that could switch the sole—this is assumed to be a uniprocessor—running kernel “thread” was a hardware interrupt, critical sections would be protected by simply disabling interrupts.

Uniprocessor kernels even to today will do that. Linux without CONFIG_SMP and CONFIG_PREEMPT simply disables interrupts when the code asks for a lock. https://www.kernel.org/doc/htmldocs/kernel-locking/uniproces...

If you like the sound of "gamecore", chiptune is probably right up your alley.

Benchmarks like this are pointless without thermal info. Frequency (and possibly core allocation) are decided based on CPU temperature.

Betteridge [0] needs an update. When the headline question is asking whether the authors can do something they can be proud of, the answer is yes.

[0] https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

As usual Apple have really done a lot of marketing now that people keep calling it Apple silicon instead of ARM

If you ask someone what processor is in their desktop, nobody says “Oh I’ve got an x86_64”. They’ll tell you which product line it is: “Ryzen”

If anyone deserving credit for this, it’s Intel after introducing the Pentium line.

In this case I believe they would want specify Apple Silicon because there are multiple manufacturers that produce ARM chips.

I thought the common speculation was that they aren't allowed to call it ARM, because they extend the ISA significantly enough that ARM-the-company was concerned it'd fragment the ecosystem.

Why would you call AMD cpus an Intel because they license x86?