Ruby’s GIL and transactional memory
mikeperham.com
Ruby’s GIL and transactional memory
1–10 of 21 posts
Re: Ruby’s GIL and transactional memory
#2I haven't read the linked paper yet, but if transactional memory can be used in a feedback loop with the developer to identify sources of resource contention (where, for example, more intricate locking could usefully replace both TM and the GIL) that sounds like a real win.
Re: Ruby’s GIL and transactional memory
#3Pypy has a (currently, software) transactional memory branch that is trying to remove the python GIL without changing the semantics
http://pypy.org/tmdonate.html (has the best executive summary of what the branch intends to accomplish)
Re: Ruby’s GIL and transactional memory
#4Just like with Python, why would you even care about the GIL?
Writing single multithreaded apps with low-level locking hardcoded everywhere is now quite clearly NOT the right way to build software. If you don't use locks, i.e. only use lock-free data structures and immutable state, then you won't care about the GIL. And you can use multiple processes and interproccess communications in place of threading. On Linux, the difference in performance between threads and processes is very small. Most people who complain about the GIL have not even profiled multithreading versus multiprocessing. They are just bound and determined to reinvent the wheel in their own code base.
There is no reason why you can't leverage C++ (ZeroMQ) or Erlang (RabbitMQ) to do the hard bits and write the rest of your app in nice simple Ruby (or Python) scripts that are designed according to the Actor Model.
Re: Ruby’s GIL and transactional memory
#5I haven't read the linked paper yet, but if transactional memory can be used in a feedback loop with the developer to identify sources of resource contention (where, for example, more intricate locking could usefully replace both TM and the GIL) that sounds like a real win.
To me locking means waiting which means greatly reduced performance. That is the whole reason why event-based systems like NGINX and node.js are so popular.
Look at the first slide from this talk by Professor Michael Stonebraker to see why more locking is not such a good idea. http://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker...
Just because we can do it doesn't mean that we should do it.
Re: Ruby’s GIL and transactional memory
#6Ruby needs JIT, then Incremental GC much more urgently then getting rid of GIL and getting TM.
Re: Ruby’s GIL and transactional memory
#7Just like with Python, why would you even care about the GIL? Writing single multithreaded apps with low-level locking hardcoded everywhere is now quite clearly NOT the right way to build software. If you don't use locks, i.e. only use lock-free data structures and immutable state, then you won't care about the GIL. And you can use multiple processes and interproccess communications in place of threading. On Linux, t…
> Most people who complain about the GIL have not even profiled multithreading versus multiprocessing.
This is a fair point, but the issue might be about memory usage, not speed. A unicorn setup might have two to eight worker processes to service HTTP requests. Even with copy-on-write-friendly garbage collection, the memory usage of each additional process is significant. On the other hand, a thread-based solution (using JRuby, for example) can maintain a threadpool with hundreds of worker threads because the cost of an additional thread is nearly negligible.
Re: Ruby’s GIL and transactional memory
#8Just like with Python, why would you even care about the GIL? Writing single multithreaded apps with low-level locking hardcoded everywhere is now quite clearly NOT the right way to build software. If you don't use locks, i.e. only use lock-free data structures and immutable state, then you won't care about the GIL. And you can use multiple processes and interproccess communications in place of threading. On Linux, t…
There are tiers for performance. A few hundred (or thousand) ops/sec -- a GIL isn't going to hurt too much. A few thousand -- well-designed IPC is fine. A few tens of thousands -- lock-free gets important. Hundreds of thousands (or millions) -- userspace/kernel transitions and interrupt servicing can dominate, and an application's interactions with the OS need to be very carefully managed...
It all depends on how much you want to get out of your hardware.
Re: Ruby’s GIL and transactional memory
#9Just like with Python, why would you even care about the GIL? Writing single multithreaded apps with low-level locking hardcoded everywhere is now quite clearly NOT the right way to build software. If you don't use locks, i.e. only use lock-free data structures and immutable state, then you won't care about the GIL. And you can use multiple processes and interproccess communications in place of threading. On Linux, t…
Based on our experience running large telephony applications, I would say that the threading approach, using JRuby as it provides a stable GIL-free interpreter, is vastly superior both in resource handling and developer/sysadmin productivity, also known as "less headaches".
Re: Ruby’s GIL and transactional memory
#10Just like with Python, why would you even care about the GIL? Writing single multithreaded apps with low-level locking hardcoded everywhere is now quite clearly NOT the right way to build software. If you don't use locks, i.e. only use lock-free data structures and immutable state, then you won't care about the GIL. And you can use multiple processes and interproccess communications in place of threading. On Linux, t…
> Most people who complain about the GIL have not even profiled multithreading versus multiprocessing. This is a fair point, but the issue might be about memory usage, not speed. A unicorn setup might have two to eight worker processes to service HTTP requests. Even with copy-on-write-friendly garbage collection, the memory usage of each additional process is significant. On the other hand, a thread-based solution (u…
Why would you need hundreds of worker threads? If you're using an event-loop in each process (which you probably want if only to minimize context-switching overhead, and is how Unicorn does it), then you need only one process per physical core in the machine. Anything else will just sit in the runqueue and cause context switches.
There is definitely annoying memory overhead with multiprocess (vs. multithreaded) architectures, but it's on the order of 2x-8x, not 100x. And that's 2x-8x the code size of the application, not data size - you only need duplicate interpreter objects, anything at the app or framework level (like templates or data files) can be stored in read-only shared memory or just COW'd with no writes. (It's technically not even every interpreter object - a number of function objects are completely static data that will never have additional references made, and so COW means they'll be shared perpetually between processes.)