Re: Ruby Thread

看板Ruby作者contagious (布穀飽吃不堡)時間18年前 (2006/11/03 20:02)推噓1(1推 0噓 3→)

留言4則, 1人參與討論串2/7 (看更多)

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