其实我觉得 Ruby 慢的原因和 thread 没有什麽太大的关系。 之前在 railscn 也和别人吵过相关的问题，不过那时他是说 mongrel 慢(相对於 FastCGI 而言)是因为 Ruby 没有 native thread 的关系，而我「相当」不以为然。 thegiive 所提到的讨论串在其实在第二篇，高手 qiezi 就点出了这点： "是不是存在这样一个误解：用真正的多线程会提高效率？用伪线程才会降低效率？" 在多 CPU 系统出现之前，threading 最主要的解决的问题是 blocking IO 的问题。 在 Unix Network Programming (http://rubyurl.com/YHt) 这本网路程式设计的圣经里， 就有比较利用各种方式来达到 non-blocking IO。而在各种方法中，用 threading 其实效能只比直接用 process 来得好而已，而比其它用 io multiplexing 或是 signal driven io 的都要远远不如。最主要就是多了要维护各 thread 的状态和 syncronization 的工作，还有要在各 threads 中切换的时间。而在多 CPU 的环境下，threading 的好处 是否真的能弥补他在这些东西上面的损失呢？ 我过去工作过的公司也有做过类似的实验，使用的是 signal driven io 和 threading 两 种实做的比较，在真的两颗 CPU 的机器上试过。结果出人意料的还是 signal driven io 的方式比较快。(不过因为 signal driven 实在太难写了，所以最後采用的还是 threading 的方式..XD) Ruby 所使用来达成「假」thread 的主要方法就有是 IO multiplexing，可以参考我的 blog 上的这篇 http://blog.pityathome.com/articles/search?q=thread。所以理论上， 如果 Ruby 自己做的 thread 切换演算法够好的话，在单 CPU 的环境下，效能是不会输 native thread 太多的。 当然在愈来愈多 CPU 的发展之下，用 threading 的方式会愈来愈吃香。 但是个人认为 Ruby 目前慢是慢在没有 VM，不能 JIT compile，所以速度才会输给 3P。 Threading 是个问题，但远远没有大家想得这麽严重。 附带一提， 1. ruby 的这种模拟出来的 thread 叫 "gren thread"。系统提供的thread 叫 "native thread" 所以那篇说 "Ruby 2.0 would support neither continuations nor green threads. " 实在很奇怪，这样是指没有模拟的 thread 了吗？ 2. 同一个论譠里有关 "ruby线程运行速度测试" 那篇其实是在测 C++ 和 Ruby， 而不是 native thread 和 green thread，对於我们的问题而言并没有参考价值。 3. 其中有提到 ruby 的 generator 是用 continuations 实做的。其实因为这样的做法 太慢，已经有人用 threading 的方式重做了，忘了是放到 1.9 还是 1.8.4 就是这样， 要去翻一下 code --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.132.134.191