5 ms·

Ah okay in that case that makes much more sense to me for the threaded version, I was meaning fake threaded in the sense only one thread is ever ran at a time b

Ah okay in that case that makes much more sense to me for the threaded version, I was meaning fake threaded in the sense only one thread is ever ran at a time but of course they are scheduled onto different OS threads like you say which means they will run across my logical cores. But for the single threaded version I still seen spikes across all cores is this some CPU magic and if so what techniques are involved? Or am I just misreading my CPU usage like a doughnut? > There's synchronisation. Many VM services are global. What do you mean by this? And I just realized I'm talking to Chris Seaton thank you for your work on TruffleRuby super awesome project.

chrisseaton 6y ago
> But for the single threaded version I still seen spikes across all cores is this some CPU magic and if so what techniques are involved? The kernel must be moving the Ruby process around if you're looking at the single-threaded case. That doesn't sound right though - moving a process to a different core damages its cache. But Ruby doesn't influence that it's down to the OS. Maybe the kernel has some subtle good reason to do it if you're running other services in the background? > What do you mean by this? Ractors acquire locks and CAS to do things to update the VM on what they're doing. They don't run entirely purely in parallel. GC is the big example. This benchmark shouldn't really need to use the GC... but maybe it does. Does your system malloc have a global lock too?
- JW_00000 6y ago
  > Maybe the kernel has some subtle good reason to do it I think OSes spread load across cores to prevent unequal heating across the chip.
  - chrisseaton 6y ago
    Hmm that’d be a disaster for cache I think that’s extremely unlikely but I’m not an OS expert.
    - CyberDildonics 6y ago
      You are comparing something that happens on the scale of multiple seconds to something that happens on the scale of microseconds.
    - pjmlp 6y ago
      If you want a process to stay put in a specific core, you need to ask the OS for it, however this might still influence the performance, as naturally there are other processes running there and the OS cannot honour the request if everyone does the same. However it already improves not copying the process context across all cores. I used this to good effect back in the Windows NT/2000 days, whose scheduler wasn't that smart about when to move processes across cores.
JW_00000 6y ago
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.

chrisseaton 6y ago

> But for the single threaded version I still seen spikes across all cores is this some CPU magic and if so what techniques are involved? The kernel must be moving the Ruby process around if you're looking at the single-threaded case. That doesn't sound right though - moving a process to a different core damages its cache. But Ruby doesn't influence that it's down to the OS. Maybe the kernel has some subtle good reason to do it if you're running other services in the background? > What do you mean by this? Ractors acquire locks and CAS to do things to update the VM on what they're doing. They don't run entirely purely in parallel. GC is the big example. This benchmark shouldn't really need to use the GC... but maybe it does. Does your system malloc have a global lock too?

JW_00000 6y ago
> Maybe the kernel has some subtle good reason to do it I think OSes spread load across cores to prevent unequal heating across the chip.
- chrisseaton 6y ago
  Hmm that’d be a disaster for cache I think that’s extremely unlikely but I’m not an OS expert.
  - CyberDildonics 6y ago
    You are comparing something that happens on the scale of multiple seconds to something that happens on the scale of microseconds.
  - pjmlp 6y ago
    If you want a process to stay put in a specific core, you need to ask the OS for it, however this might still influence the performance, as naturally there are other processes running there and the OS cannot honour the request if everyone does the same. However it already improves not copying the process context across all cores. I used this to good effect back in the Windows NT/2000 days, whose scheduler wasn't that smart about when to move processes across cores.

JW_00000 6y ago

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.