其實我覺得 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