Rubinus或MRI 1.9.3（YARV）？

Question

所以，我有一些問題要問我，我確實瀏覽了互聯網，但沒有太多可靠的答案。 大多數博客帖子會相互取消，因為他們都贊揚了不同的東西，並有基准來“證明他們的觀點”（ 我一生中從未見過這么多矛盾的基准 ）。

無論如何，我的問題是：

• 魯賓尼斯真的快嗎？ 這個顯然誠實的親Rubinius演講讓我印象深刻。 讓我感到困惑的另一件事是，很多Rubinius都是用Ruby編寫的，但不知何故它比C-Ruby更快？ 那一定是一個非常好的語言實現！
• EventMachine是否與Ruinius一起使用？ 據我所知，EventMachine部分依賴Fibers（糾正我，如果我錯了），直到1.9才實現。 我知道Rubinius最終也會支持1.9; 我不介意等一下。
• C擴展是否適用於Rubinius？ 我編寫了一個C擴展，它將從TCP流接收的二進制消息“序列化”到Ruby對象中，反之亦然（我想這些細節並不重要，但如果它有助於回答這個問題，我會更新帖子）。 這可能是很多消息！ 我設法在Ruby中編寫相同的代碼（盡管在一個月后它沒有任何意義），但事實證明它在應用程序中是一個真正的瓶頸。 所以，我不得不使用C作為我的問題的“解決方案”。 編輯 ：我記得，我使用C進行另一項任務，它是陣列的命中測試方法。 基本上它只是檢查一個“點”是否在一個多邊形內部，它在CRuby中是不可能的慢。
• 如果之前的答案是“否”，那么在Rubinus有C替代嗎？ 我收集的VM是用C ++編寫的，那么。

一些“獎金”問題：

• C-Ruby（2.0 +，YARV）是否會擺脫GIL？ 或者至少修改它以便CRuby支持真正的並行性？
• 什么是mruby ？ 我看到matz正在研究它，就描述而言，它看起來非常棒。 與CRuby（性能方面）有何不同？

我為你發動的這場文字風暴道歉！ ♥

Answer 1

魯賓尼斯真的快嗎？

在大多數基准測試中，是的。

但基准是......愚蠢。 應用程序是我們真正關心的。 因此，最好的辦法是對應用程序進行基准測試，看看它的表現如何。 Rubinius將在MRI上真正發光的兩個領域是並行性和內存使用。 Rubinius沒有GIL，所以你可以利用所有可用的線程。 它還具有更復雜的GC ，因此通常它可以在GC方面表現更好。

我在2011年10 月份在RubyConf上談論MagLev時做了那些基准測試

EventMachine是否與Rubinius一起使用？

是的，如果有部分不起作用，則應報告該問題。 話雖如此， 目前 EM測試並沒有傳遞任何Ruby實現。

C擴展是否適用於Rubinius？

是。 我保留了C-exts的兼容性問題 ，所以如果有一個你在Travis上測試過，那么Rubinius希望看到它通過rbx。 Rubinius歷來對C-api和C-exts有很好的支持，盡管如果有一天Rubinius能夠如此快地運行Ruby而不需要C-exts或C-api會很好。

C-Ruby（2.0 +，YARV）是否會擺脫GIL？ 或者至少修改它以便CRuby支持真正的並行性？

不，很可能不是。 來自RubyConf 2012的線程中， Jesse Storimer對Matz的觀點（或缺乏觀點）進行了簡潔的描述.Koichi Sasada試圖移除GIL一次並且MRI性能剛剛消失。 埃文·菲尼克斯在創造魯賓尼斯之前也嘗試了一次，但沒有取得好成績。

什么是mruby？

一個可嵌入的Ruby解釋器，類似於Lua。 Matt Aimonetti有一些文章可能會為你揭曉。

Answer 2

我對Ruby不太滿意，但我可以回答第一個問題。

魯賓尼斯真的快嗎？

我看過不同的基准，講述不同的東西。 然而，Rubinius部分用Ruby編寫的事實並不一定意味着它更慢。 我對Python中Python的PyPy也有同樣的看法。 經過一些研究和大學的正確課程，我知道為什么。

• 據我所知，兩者都是用他們語言的一個子集編寫的，應該更加簡單。 對於這樣的子集，可以比整個語言更容易地優化（例如，C）解釋器。
• 用自己的語言編寫Ruby / Python解釋器可以更靈活，更快速地對新解釋算法進行原型設計。 Ruby和Python存在的全部要點是算法可以比例如C甚至匯編程序更快地實現。 更快的算法在很多時候都超過了解釋器的小開銷。

順便說一句。 為同一語言的語言編寫翻譯也是一種常見的學術實踐，以顯示語言的強大程度。 在一個類中，我們在Lisp中用Lisp編寫了Lisp。