M1 threatens no one besides wishful thinking, Apple isn't going to start selling M1, and their laptops/desktops account for about 10% worldwide market share.
Apple's history as a supplier of server hardware isn't so good. (Cough, gag, XServe.) But they could have a few crack chip designers working on bigger brothers to the M1, may have noticed how many $Billions are being spent annually on servers for data centers, and might even act as if they actually want to be successful in that market segment, this time around.
Or - probably more likely - Microsoft, Intel, etc. want to keep that ~90% worldwide market share of theirs from shrinking.
While I can't really know for sure, but based on perceived performance and smoothness, most likely M1 + MacOS already does something similar in terms of thread and process prioritisation. iOS has done this for a long time, making sure that rendering threads are not resource starved.
AFAIK apple runs background tasks on slow cores which is supposed to free fast cores for foreground tasks.
I still don't understand why is it necessary in an OS which can juggle threads hundreds times per second using priority system. At least ignoring power efficiency aspect and concentrating only on performance or perceived performance aspects.
Context switching is a major performance killer on modern CPUs. You can look at the "slow" cores as being optimized for offloading context switches and interrupts across myriad threads so that the "fast" cores can focus on the primary workload with few context switches.
This is the same motivation behind why high-performance software architecture uses a "thread per core" model. There are large throughput gains to be had by minimizing context switching and CPU cache sharing across threads.
Do you know of any resources for learning CPU-bound parallel/concurrent programming? I wish it was easier to user all the cores my devices actually have. Asynchronous IO and network stuff is “easy” because you don’t care to much when then work completes as long as it’s not blocking the main thread, but speeding up CPU bound tasks is much harder. For all its flaws, Unity with their DOTS (and I believe specifically their job system) is the only thing that I am aware of that facilitates programmers multithreading CPU bound work (you can multithread actual gameplay code rather than just the standard rendering thread, game logic thread, IO thread, etc. of many games)rather than just having to roll your own solution.
There does seem to be some of that in the strategy and article. The odd thing is it doesn't seem to address the elephant in the room which is single threaded sustained memory bandwidth. From my usage it seems like that's the only huge upgrade.
And it shouldn't be hard to get into Linux, I wouldn't really say this partnership notably hurts that.