After chatting with @john and Ivo Anjo at RubyConf, I went down a rabbit hole trying to understand how Ruby Thread Priority adjusts the effective Thread Quantum.
https://github.com/bensheldon/good_job/issues/1554
=> More informations about this toot | More toots from bensheldon@ruby.social
Can anyone help me understand, from a performance standpoint, how switching between two Ruby processes (at the OS/Kernel level) is different than switching between two threads within the same Ruby process?
Cause Ruby Threads are OS/Kernel-level threads right? So it seems like it would be same same, perf wise (to me?).
(Assume I don't care at all about shared memory; just CPU cycles)
=> More informations about this toot | More toots from bensheldon@ruby.social
@bensheldon is it a question of the Global VM Lock? In the same thread, the GVL would have to be released and acquired, whereas in two processes, no need to touch the GVL?
I'm speculating, I don't have exact knowledge about that.
=> More informations about this toot | More toots from francois@ruby.social
@francois that's mostly what the topic centers around.
I guess the conclusion I'm circling around is: using Ruby Threads is performatively worse than using multiple processes. Because Ruby threads still uses OS kernel switching AND also has to do GVL locking/unlocking on top of that.
This is not quite a Unicorn vs Puma thing, but that's a lot of the context of these thoughts. Cause other than sharing resources (memory, db connections) multiple processes seems better for perf.
=> More informations about this toot | More toots from bensheldon@ruby.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini