4 ms·

You compare a many thousand man years VM (HotSpot JVM) to one that has been largely written by one person in isolation ( Ruby 1.8 series ). Ruby 1.9 has 90% of

by xal 16y ago

You compare a many thousand man years VM (HotSpot JVM) to one that has been largely written by one person in isolation ( Ruby 1.8 series ). Ruby 1.9 has 90% of the features you mention above and RBX will soon remove the GIL on top of it. Async IO is arguably further along in Ruby then in Java. Ruby will never be as fast as Java, but micro optimizations like the OP will not hold back the inevitable progress of ruby vms.

bad_user 16y ago
You compare a many thousand man years VM (HotSpot JVM) to one that has been largely written by one person in isolation ( Ruby 1.8 series ). LuaJIT was also written by "one person in isolation" and yet it beats Java in some benchmarks. There are techniques first researched in the Smalltalk/Self implementations that have been known for at least 20 years (roughly the same time Ruby was born) that could've been used in Ruby 1.9. Ruby 1.9 has 90% of the features you mention above and RBX will soon remove the GIL on top of it. You're talking as if there's a list of checkboxes that just needs to be checked. It doesn't work that way. One reason the GIL is here to stay is because of the many libraries written in C that depend on it. Another reason would be performance degradation on single threaded programs ... removing the GIL on the whole needs major architectural changes ... just putting fine-grained locks on all mutable data structures won't cut it. And yet another would be the garbage collector which also needs to be optimized for true multi-threading, otherwise it becomes a bottleneck. So add this on your list ... Ruby also needs a top-notch generational garbage-collector. Async IO is arguably further along in Ruby then in Java You are probably kidding.
- xal 16y ago
  It's odd to point to C extensions when talking about the need for a GIL. The solution seems obvious. Wrap them in a mutex by default and introducing an optional API call to remove the lock. This way the important libraries will be fixed up gradually by the community and after a bit of time you won't have any C ext's left that will make use of the mutex and therefore the GIL will be gone. That's the approach that rubinius is set to take.
- lg 16y ago
  rbx will use the immix collector
  - rue 16y ago
    Uses.

by xal 16y ago

bad_user 16y ago

You compare a many thousand man years VM (HotSpot JVM) to one that has been largely written by one person in isolation ( Ruby 1.8 series ). LuaJIT was also written by "one person in isolation" and yet it beats Java in some benchmarks. There are techniques first researched in the Smalltalk/Self implementations that have been known for at least 20 years (roughly the same time Ruby was born) that could've been used in Ruby 1.9. Ruby 1.9 has 90% of the features you mention above and RBX will soon remove the GIL on top of it. You're talking as if there's a list of checkboxes that just needs to be checked. It doesn't work that way. One reason the GIL is here to stay is because of the many libraries written in C that depend on it. Another reason would be performance degradation on single threaded programs ... removing the GIL on the whole needs major architectural changes ... just putting fine-grained locks on all mutable data structures won't cut it. And yet another would be the garbage collector which also needs to be optimized for true multi-threading, otherwise it becomes a bottleneck. So add this on your list ... Ruby also needs a top-notch generational garbage-collector. Async IO is arguably further along in Ruby then in Java You are probably kidding.

xal 16y ago
It's odd to point to C extensions when talking about the need for a GIL. The solution seems obvious. Wrap them in a mutex by default and introducing an optional API call to remove the lock. This way the important libraries will be fixed up gradually by the community and after a bit of time you won't have any C ext's left that will make use of the mutex and therefore the GIL will be gone. That's the approach that rubinius is set to take.
lg 16y ago
rbx will use the immix collector
- rue 16y ago
  Uses.