Rubyは特定の点で遅いです。しかし、それのどの部分が最も問題がありますか？
ガベージコレクターはパフォーマンスにどの程度影響しますか？ガベージコレクターを単独で実行するのに数秒かかることがありました。特にOpenGLライブラリを使用する場合はそうです。
私はRubyで特に遅い行列数学ライブラリを使用しました。rubyが基本的な数学を実装する方法に問題はありますか？
単に効率的に実装できないRubyの動的機能はありますか？もしそうなら、LuaやPythonのような他の言語はこれらの問題をどのように解決しますか？
パフォーマンスを大幅に改善した最近の作業はありますか？
Rubyは遅いです。しかし、その中で最も問題があるのはどの部分でしょうか。
柔軟性を確保するために、メソッドの「レイトルックアップ」を行います。これにより、かなり遅くなります。また、eval を可能にするためにコンテキストごとに変数名を覚えておく必要があるため、フレームとメソッドの呼び出しが遅くなります。また、MRI 1.9 にはバイトコード コンパイラ (より優れている) があり、jruby はそれを Java バイトコードにコンパイルし、HotSpot JVM の JIT コンパイラを介してコンパイルできますが、現在は適切な JIT コンパイラがありませんが、最終的には約1.9と同じ速度。
ガベージ コレクタはパフォーマンスにどの程度影響しますか? 特に OpenGL ライブラリを使用している場合は、ガベージ コレクターだけを実行するのに数秒かかることがありました。
http://www.igvita.com/2009/06/13/profiling-ruby-with-googles-perftools/のいくつかのグラフから、約 10% かかると思いますが、これはかなりの量です。 gc.c の malloc_limit を増やして再コンパイルすることで、そのヒットを減らします。
特に遅い Ruby で行列数学ライブラリを使用しました。Ruby が基本的な数学を実装する方法に問題はありますか?
Ruby 1.8 は数値クラスを実装する基本的な数学を「実装しませんでした」。Fixnum#+ Fixnum#/ のようなものを 1 回の呼び出しで 1 回呼び出しますが、これは遅かったです。Ruby 1.9 は、いくつかの基本的な数学演算をインライン化することで、少しごまかしています。
効率的に実装できないRubyの動的機能はありますか? もしそうなら、Lua や Python のような他の言語はこれらの問題をどのように解決しますか?
eval のようなものを効率的に実装するのは難しいですが、多くの作業を行うことができると確信しています。Ruby のキッカーは、クラスの定義を自発的に変更する別のスレッドの誰かに対応する必要があることです。そのため、非常に保守的でなければなりません。
パフォーマンスを大幅に改善した最近の作業はありますか?
1.9 は 2 倍のスピードアップのようなものです。また、スペース効率も向上します。JRuby は常に速度の向上に努めています [そして、おそらく KRI よりも GC に費やす時間が少ない]。それに加えて、自分が取り組んでいるちょっとした趣味のこと以外はあまり意識していません。また、1.9 の文字列は、エンコードしやすいため、時々遅くなることにも注意してください。
Ruby は、ソリューションを迅速に提供するのに非常に適しています。迅速なソリューションを提供する場合はそれほどではありません。それは、解決しようとしている問題の種類によって異なります。90 年代初頭の古い CompuServe MSBASIC フォーラムでの議論を思い出します。Windows 開発では VB と C のどちらが速いかと尋ねられたとき、通常の答えは「VB では約 6 か月」でした。
MRI 1.8 形式の Ruby は、ある種の計算集約型タスクの実行が比較的遅くなります。ほとんどのインタープリター言語は、ほとんどの主流のコンパイル済み言語と比較して、そのように苦しんでいます。
理由はいくつかあります。かなり簡単に対処できるもの (たとえば、1.8 のプリミティブ ガベージ コレクション) もあれば、そうでないものもあります。
1.9 ではいくつかの問題が解決されていますが、一般公開されるまでにはしばらく時間がかかるでしょう。JRuby、IronRuby、MagLev など、既存のランタイムを対象とするその他の実装の一部は、大幅に高速化される可能性があります。
数学的パフォーマンスに関しては、スループットがかなり遅くなっても驚かないでしょう。これは、任意の精度に対して支払う代償の一部です。繰り返しますが、問題を選択してください。Ruby で70 以上のProject Eulerの問題を解決しましたが、実行に 1 分以上かかる解決策はほとんどありませんでした。どのくらいの速さで実行する必要がありますか?
一番問題なのは「全員」です。
その「全員」が実際にその言語を使用したことがない場合は、ボーナスポイントです。
真剣に、1.9 ははるかに高速で、今では python と同等であり、jruby は jython よりも高速です。
ガベージ コレクターはどこにでもあります。たとえば、Java には 1 つあり、動的メモリ処理では C++ よりも高速です。Ruby は数値演算には適していません。しかし、そうしている言語はほとんどないので、どの言語でもプログラムに計算集約型の部分がある場合は、それらを C で書き直した方がよいでしょう (Java はそのプリミティブ型のために数学で高速ですが、それらには多大な費用がかかりました。それらは明らかに #言語の最も醜い部分で 1)。
動的機能については、高速ではありませんが、静的言語でそれらを使用しないコードはさらに遅くなる可能性があります。たとえば、Java は DSL を使用する Ruby の代わりに XML 構成を使用します。また、XML の解析にはコストがかかるため、遅くなる可能性があります。
「Ruby で遅くなりがちな特定の手法は何か」と尋ねていると思います。
1 つはオブジェクトのインスタンス化です。大量に実行している場合は、メモリ使用量が問題にならない場合でも、 flyweight patternを使用するなど、それを減らす (合理的な) 方法を検討する必要があります。非常によく似たオブジェクトを何度も何度も作成しないように作り直したあるライブラリでは、ライブラリの全体的な速度が 2 倍になりました。
Steve Dekorte: 「高級言語でマンデルブロ集合計算機を書くことは、バスで Indy 500 を走らせようとするようなものです。」
http://www.dekorte.com/blog/blog.cgi?do=item&id=4047
仕事に適したツールを使用するために、さまざまなツールを学ぶことをお勧めします。行列変換を行うことは、算術集約的な計算でタイトなループをラップする高レベル API を使用して効率的に行うことができます。C または C++ コードを Ruby スクリプトに埋め込む例については、RubyInline gem を参照してください。
Ruby よりもはるかに遅い Io 言語もありますが、Pixar でムービーを効率的にレンダリングし、SIMD アクセラレーションを使用することでベクトル演算で生の C を凌駕します。
Ruby が遅いのは、プログラムの実行時間ではなく、プログラマーのエクスペリエンスを最適化するように設計されているためです。遅さは、その設計上の決定の単なる兆候です。楽しみよりもパフォーマンスを優先する場合は、おそらく別の言語を使用する必要があります。Ruby は万能ではありません。
IMO、動的言語は一般的にすべて遅いです。これらは、静的言語がコンパイル時に行うことを実行時に行います。
構文チェック、解釈および類似型チェック、変換。これは避けられないので、ruby は c/c++/java より遅いです。間違っていたら訂正してください。
