My hunch is that in just a few years time single core computers will be almost extinct. Removing the GIL now feels to me like good strategic preparation for the near future.
I can't think of any actual computer outside of embedded that has been single core for at least a decade. The Core Duo and Athlon X2 were released almost 20 years ago now and within a few years basically everything was multicore.
(When did we get old?)
If you mean that single core workloads will be extinct, well, that's a harder sell.
* Most of the programs I write are not (trivially) parallelizable, and a the bottleneck is still a single core performance
* There is more than one process at any time, especially on servers. Other cores are also busy and have their own work to do.
1. Other people with different needs exist.
2. That's why we have schedulers.
(Huh, people like hard OS design problems for marginal behavior? OSes had trouble adopting SMP but we also got to jettison a lot of deadlock discussions as soon as there was CPU 2. It only takes a few people not prioritizing 1 CPU testing at any layer to make your 1 CPU container much worse than a 2 VCPU container limited to a 1 CPU average.)
When you set "request: 1" in Kubernetes or another container manager, you're saying "give me 1 CPU worth of CPU time" but if the underlying Linux host has 16 logical cores your container will still see them.
Your container is free to use 1/16th of each of them, 100% of one of them, or anything in-between.
You might think this doesn't matter in the end but it can if you have a lot of workloads on that node and those cores are busy. Your single threaded throughout can become quite compromised as a result.
While yes this can cause a slowdown, wouldn't it still happen if each container thought it had a single core?
Also you said "a lot of workloads" so yes probably more containers than cores.
I don't think the scheduler picking a different core matters much unless your workload is super cache sensitive. My point is more about access to single threaded performance. If you have a single threaded workload (ex: an ffmpeg audio encode) and you want it to be able to access as many cycles from a single core as possible, it isn't always as simple as request: 1
On Docker, --cpuset-cpus=0 will pin the container to the first core.
K8s: https://kubernetes.io/docs/tasks/administer-cluster/cpu-mana...
CPU affinity and pinning is something I think you should be able to achieve without too much hassle.
Just let the CPU scheduler do its job. Unless you know better, in which case, by all means go ahead and allocate computational resources manually. I don't see a way to make that a sensible default, though.
Neat, I didn't know it was a single flag in Docker.
The k8s method you linked definitely has some caveats as it doesn't allow this scheduling at the pod level, and requires quite a bit of fiddling to get working (atleast on GKE). This isn't even available if you use a fully managed setup like autopilot.
Maybe my expectations just aren't realistic but "easy" to me would mean I put the affinity right next to my CPU request in the podSpec :/
Single core computers are already functionally extinct, but single-threaded programs are not.