Fixing Threads in Ruby 1.8: A 2-10x performance boost

wheels 17 years ago | |

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.

jcapote 17 years ago | |

I'm curious why someone would go through the trouble to stay on 1.8?

FooBarWidget 17 years ago | | |

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.

rbanffy 17 years ago | | |

"Many libraries are still not compatible with 1.9"

It's not likely they will remain so for very long

grandalf 17 years ago | | |

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.

rbanffy 17 years ago | | |

I would gladly accept a major library breakage for proper multi-processor support in Python. A better implementation is a significant enhancement.

derefr 17 years ago | |

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.

FooBarWidget 17 years ago | | |

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".

derefr 17 years ago | | |

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.