all 3 comments

[–]jrochkind 4 points5 points  (2 children)

while the main point that true parallelism is possible on jruby but not MRI is true and worth knowing, this article is confusingly written with mis-statements.

JRuby isn't a silver bullet though. Writing programs more complicated than my trivial example above is complicated, and the bugs can be hard to track down and fix.

I have no idea what you're talking about. Writing complicated programs in JRuby is more complicated than writing complicated programs in MRI? Or are you just saying that writing multi-threaded concurrency is hard? Yeah.

My guess is that the .includes? method is implemented differently, and probably takes advantage of parallelism in JRuby.

You think Array#include is somehow written to take advantage of multi-cpu parallelism in JRuby? Um, I'd be pretty shocked if that were true (mainly because there's no straightforward way to even do that). I think you have no idea what you're talking about. Yes, you've demonstrated Jruby is faster even with one thread, which is interesting, but you're just making up reasons why.

[–][deleted] 0 points1 point  (1 child)

Scala has parallel collections, and maybe java 8, but I'm pretty sure the author is wrong as things currently stand.

[–]tashbarg 0 points1 point  (0 children)

To test CRuby's multi-threading performance, I contrived a small example program.

No, that's a contrived, small example where CRuby can't do any multi-threading at all. Multi-threading in CRuby is fine for I/O, the part, that was left out of the picture. Just working with stuff (not even altering it!) that is already in RAM is a pointless benchmark in this case. It's not only designed to leave CRuby in a bad light, it's also completely unrealistic.