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.
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.
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'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".
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.
I'd be curious to see the rest of the benchmarks.