4 ms·

Incremental garbage collection is great for realtime-ish use cases like games and multimedia, too, because if you tune the collector right, you can ensure your

Incremental garbage collection is great for realtime-ish use cases like games and multimedia, too, because if you tune the collector right, you can ensure your GC never causes you to drop frames or fail to mix a sound buffer on time. Need to hit vsync every 16ms? Just run a 1-3ms incremental GC every frame when you have time to spare, and as long as your game's theoretical performance is good enough, you won't ever hitch. This is one of Lua's advantages for game scripting because it's had a fairly solid incremental collector for a while, making it easy to give the GC a fixed chunk of time to operate in every frame so your game never pauses. Scripting is a huge boon for people doing game development, game prototyping, and multimedia scripting (toolsets like Processing, for example), so having another scripting language to choose from for that is awesome.

digi_owl 12y ago
This was also one of the major changes in the Android ART VM vs Dalvik.
the8472 12y ago
MRI still has the global interpreter lock, i.e. is effectively single-threaded for CPU-bound tasks. IO/waiting for forked jobs can be done in background threads since the lock is released on some select function calls. So while incremental GC certainly does bring down latency caused by the GC it does not bring down latency for tasks that could be parallelized.
- chrisseaton 12y ago
  MRI is multi-threaded, even for CPU-bound tasks - it just doesn't run those threads in parallel.
  - nitrogen 12y ago
    Hence the "effectively" in the parent comment; Ruby's interpreter lock can be very problematic in threaded apps that use I/O functions from C-based gems that forget to release the lock.
    - chrisseaton 12y ago
      It's not a case of 'effectively' or not. MRI is 100%, totally, unequivocally, multi-threaded. The fact that those threads do not run in parallel is an entirely unrelated issue. Parallelism is not an essential quality of multi-threading.
      - canadev 12y ago
        I don't understand what this means... Can you explain? Here's my basic understanding: MRI is a single process, with multiple threads... They can't run in parallel because of the global interpreter lock (which is used because the code in MRI is not thread safe? Meaning each thread can touch the same memory and may leave it in a broken state for another thread, so we lock access to it first...). So: there are multiple threads, I am guessing each with their own task (maybe one to run the code, one to do garbage collection, ... I have no idea), but because of the GIL they can't be parallelized. Still multi-threaded anyway.
        nitrogen 12y ago
        You can create multiple OS-level threads in MRI using Thread.new. Those threads can run code at the same time, just not Ruby code. There is a function that C extensions are supposed to call while running I/O that can block, or while running CPU-intensive non-Ruby code, that releases the global lock.
      - teacup50 12y ago
        This is a completely pointless semantic distinction that nobody cares about. What makes threads interesting is parallelism; if the goal is merely cooperative or pre-emptive multitasking, where there's no concurrency, then you're "effectively" not multi-threaded as per any modern expectation.
        chrisseaton 12y ago
        If threads aren't interesting except for parallelism, what do you think people were using them for the multiple decades when the vast majority of people were running single-cored uniprocessor systems? The answer is that it's often useful to manage multiple things at the same time, even if we can't or don't want to actually do them at the same time. We may want to use blocking IO for the simplicity it gives us compared to asynchronous IO, but allow other parts of the system to continue to run during that blocking. We may want to let threads and the kernel manage our context and context switches for us, instead of manually storing and restoring state, because it can be simpler that way.
- nitrogen 12y ago
  If you write a C extension to do CPU-intensive stuff, you can release the lock.
dmpk2k 12y ago
At least in games Ruby has a hard time competing with LuaJIT; all that extra headroom is really nice to have, because 16ms isn't much at all. Having said that, GC improvements are a good thing. Some of the RPG Maker folks will be delighted when this eventually reaches them.

digi_owl 12y ago

This was also one of the major changes in the Android ART VM vs Dalvik.

the8472 12y ago

MRI still has the global interpreter lock, i.e. is effectively single-threaded for CPU-bound tasks. IO/waiting for forked jobs can be done in background threads since the lock is released on some select function calls. So while incremental GC certainly does bring down latency caused by the GC it does not bring down latency for tasks that could be parallelized.

chrisseaton 12y ago
MRI is multi-threaded, even for CPU-bound tasks - it just doesn't run those threads in parallel.
- nitrogen 12y ago
  Hence the "effectively" in the parent comment; Ruby's interpreter lock can be very problematic in threaded apps that use I/O functions from C-based gems that forget to release the lock.
  - chrisseaton 12y ago
    It's not a case of 'effectively' or not. MRI is 100%, totally, unequivocally, multi-threaded. The fact that those threads do not run in parallel is an entirely unrelated issue. Parallelism is not an essential quality of multi-threading.
    - canadev 12y ago
      I don't understand what this means... Can you explain? Here's my basic understanding: MRI is a single process, with multiple threads... They can't run in parallel because of the global interpreter lock (which is used because the code in MRI is not thread safe? Meaning each thread can touch the same memory and may leave it in a broken state for another thread, so we lock access to it first...). So: there are multiple threads, I am guessing each with their own task (maybe one to run the code, one to do garbage collection, ... I have no idea), but because of the GIL they can't be parallelized. Still multi-threaded anyway.
      - nitrogen 12y ago
        You can create multiple OS-level threads in MRI using Thread.new. Those threads can run code at the same time, just not Ruby code. There is a function that C extensions are supposed to call while running I/O that can block, or while running CPU-intensive non-Ruby code, that releases the global lock.
    - teacup50 12y ago
      This is a completely pointless semantic distinction that nobody cares about. What makes threads interesting is parallelism; if the goal is merely cooperative or pre-emptive multitasking, where there's no concurrency, then you're "effectively" not multi-threaded as per any modern expectation.
      - chrisseaton 12y ago
        If threads aren't interesting except for parallelism, what do you think people were using them for the multiple decades when the vast majority of people were running single-cored uniprocessor systems? The answer is that it's often useful to manage multiple things at the same time, even if we can't or don't want to actually do them at the same time. We may want to use blocking IO for the simplicity it gives us compared to asynchronous IO, but allow other parts of the system to continue to run during that blocking. We may want to let threads and the kernel manage our context and context switches for us, instead of manually storing and restoring state, because it can be simpler that way.
nitrogen 12y ago
If you write a C extension to do CPU-intensive stuff, you can release the lock.

dmpk2k 12y ago

At least in games Ruby has a hard time competing with LuaJIT; all that extra headroom is really nice to have, because 16ms isn't much at all. Having said that, GC improvements are a good thing. Some of the RPG Maker folks will be delighted when this eventually reaches them.