4 ms·

For 1): This isn't CPU magic but the scheduler in the OS. Even when running your program with only one thread, your OS will still schedule the 100s of threads t

For 1): This isn't CPU magic but the scheduler in the OS. Even when running your program with only one thread, your OS will still schedule the 100s of threads that are running on your machine (from all applications you have open) onto the 8 cores on your machine. It constantly switches between these threads, and your Ruby thread won't be put on the same core each time. Furthermore, OSes spread load across cores on purpose to avoid unequal heating inside the processor. You can 'pin' a process to a specific core but this is not recommended. (The advantage is maybe better caching, but the disadvantage is unequal heating.)

toast0 6y ago
Do you have a reference discussing core scheduling specifically to manage heating? There's a ton of different rationales for scheduling processes to cores, and lots of core scheduling algorithms, but I wasn't aware of try to keep all the cores the same temperature. Modern CPUs can run each cores at a different clock, and you get higher clock speeds when fewer cores are running, so depending on overall system load, condensing to fewer cores can result in better throughput. As well, individual core performance varies, so some schedulers will try to identify which cores can clock the highest and schedule tasks on those cores first. Generally, there are benefits from keeping a process running on the same core, but there's all sorts of scenarios that end up with a process bouncing over many cores. For example, if you have an active cpu program and get an interrupt serviced by the core its running on, an otherwise idle core may steal the process, because the process is runnable but not running. Pinning it to any particular core might work better, but if you pin processes without a plan for all your processes, you can end up with a lot worse throughput. It's pretty easy to pin too many things to a single core and that core is 100% busy and other cores are idle, even though there were enough processes to saturate all the cores. Of course, if all of those processes are working together on the same shared memory with lots of lock contention, you might have worse throughput because of cross-core synchronization. You can spend a lot of time tweaking things, but most OSes have a pretty decent general purpose scheduler. Pinning works great for things where you take up the whole machine with a single process, and that process has good reasons to pin cpus. Ex: you're running Erlang which has its own scheduling, or you're running HAProxy and you've done the work to tightly bind each process to a specific NIC queue interrupt, so you want that process to run on the same core that handles that interrupt to avoid cross-core communication.

toast0 6y ago

Do you have a reference discussing core scheduling specifically to manage heating? There's a ton of different rationales for scheduling processes to cores, and lots of core scheduling algorithms, but I wasn't aware of try to keep all the cores the same temperature. Modern CPUs can run each cores at a different clock, and you get higher clock speeds when fewer cores are running, so depending on overall system load, condensing to fewer cores can result in better throughput. As well, individual core performance varies, so some schedulers will try to identify which cores can clock the highest and schedule tasks on those cores first. Generally, there are benefits from keeping a process running on the same core, but there's all sorts of scenarios that end up with a process bouncing over many cores. For example, if you have an active cpu program and get an interrupt serviced by the core its running on, an otherwise idle core may steal the process, because the process is runnable but not running. Pinning it to any particular core might work better, but if you pin processes without a plan for all your processes, you can end up with a lot worse throughput. It's pretty easy to pin too many things to a single core and that core is 100% busy and other cores are idle, even though there were enough processes to saturate all the cores. Of course, if all of those processes are working together on the same shared memory with lots of lock contention, you might have worse throughput because of cross-core synchronization. You can spend a lot of time tweaking things, but most OSes have a pretty decent general purpose scheduler. Pinning works great for things where you take up the whole machine with a single process, and that process has good reasons to pin cpus. Ex: you're running Erlang which has its own scheduling, or you're running HAProxy and you've done the work to tightly bind each process to a specific NIC queue interrupt, so you want that process to run on the same core that handles that interrupt to avoid cross-core communication.