Fixing Threads in Ruby 1.8: A 2-10x performance boost(timetobleed.com)
timetobleed.com
Fixing Threads in Ruby 1.8: A 2-10x performance boost
http://timetobleed.com/fixing-threads-in-ruby-18-a-2-10x-performance-boost/
2 comments
Does anyone know what Ruby 1.9 does for creating threads? Does it do something similar to what the author does, or something else entirely?
Hi. Author here.
Ruby 1.9 uses libpthread which creates stacks for its threads in a similar way (mmap and a guard page).
Ruby 1.9 uses libpthread which creates stacks for its threads in a similar way (mmap and a guard page).
You mean it calls pthread_create for every Ruby thread? That would mean threads are no longer green threads, since both of the widely used Pthread libraries on Linux (Linuxthreads on 2.4 versions of the kernel, and NTPL on 2.6) have a 1-to-1 mapping of POSIX threads to kernel threads.
correct. but they each take a global interpreter lock ensuring only one is executing at any given time.
wow this is a superb post. I wonder why anyone would really want to take the trouble to move to ruby 1.9 anymore...
I'd be curious to see the rest of the benchmarks.
I'd be curious to see the rest of the benchmarks.
Note that this is pretty much only measuring thread overhead rather than thread workload throughput. So on an SMP system you'd still have the same problems with blocking I/O and only using one CPU that are part and parcel with green threads. In practice that means for something like a map-reduce pattern on a multi-core system, Ruby 1.9's native threads would win by a significant margin.
Edit: Remembered based on ice799's comment below that in 1.9 the threads still won't be allowed to operate in parallel, which neuters most of the aforementioned benefits to using native threads.
Edit: Remembered based on ice799's comment below that in 1.9 the threads still won't be allowed to operate in parallel, which neuters most of the aforementioned benefits to using native threads.
I'm curious why someone would go through the trouble to stay on 1.8?
Library compatibility. Many libraries are still not compatible with 1.9. It's good to have interim improvements for 1.8 until the ecosystem has caught up with 1.9, because 1.8 is what actually powers production systems today.
"Many libraries are still not compatible with 1.9"
It's not likely they will remain so for very long
It's not likely they will remain so for very long
I hope you're right. But I'd rather that the move to 1.9 be based on its merits as enhancements to the language rather than on the lack (in 1.8) of the sorts of optimizations that were made in the article.
I would gladly accept a major library breakage for proper multi-processor support in Python. A better implementation is a significant enhancement.
I've seen quite a few of these "improvement" posts lately, which take a feature of 1.8 and bring it into parity with the performance of 1.9. I always have the feeling that the author is just looking at what 1.9 is already doing and explaining it as if they discovered it themselves.
Your response sounds dangerously close to what pro-software patents advocates would say. Just because someone else has written software which does the same thing doesn't mean that you couldn't have discovered the same method independently.
In case of this patch, even the author himself says that Ruby 1.9 doesn't do stack copying. He's not "explaining as if he discovered it himself".
In case of this patch, even the author himself says that Ruby 1.9 doesn't do stack copying. He's not "explaining as if he discovered it himself".
I'm not implying any malicious intent here; the author obviously didn't look at the 1.9 codebase and go "how can I pretend this is mine?" All I'm saying is that there has been a lot of independent discovery of Ruby 1.9-equivalent performance enhancements lately, is all, and this seems like a bit of a useless thing to do.
It seems that the techniques these bloggers are discovering have already been figured out, or at least equalled (in this case bettered, apparently) by the 1.9 team. I'd say fewer people should be working on enhancing 1.8 if they could just back-port the enhancements that already exist from 1.9. Instead, if they actually want to optimize something, start with the codebase that doesn't have huge, obvious, already-solved(!) performance flaws to begin with, and then backport the new optimizations you find.
It seems that the techniques these bloggers are discovering have already been figured out, or at least equalled (in this case bettered, apparently) by the 1.9 team. I'd say fewer people should be working on enhancing 1.8 if they could just back-port the enhancements that already exist from 1.9. Instead, if they actually want to optimize something, start with the codebase that doesn't have huge, obvious, already-solved(!) performance flaws to begin with, and then backport the new optimizations you find.