（比類のないものを比較することは、常に両刃の剣です。
以下は、合理的にサポートされた決定の基礎として得られた結論が役立つ場合、LLVM / JIT を利用したコード ベンチマークを他の LLVM / JIT を利用した代替手段と比較する必要があるという公正な信念に基づいて提示されています。)
イントロ : (numbaスタッフと [us] の結果は、ページの少し下に表示されます )
敬意を表して、julia-lang の公式サイトでは、表形式のパフォーマンス テストのセットを提示しています。ここでは、2 つのカテゴリの事実が述べられています。1つ目は、パフォーマンステストの実行方法に関連しています（ジュリア、LLVMでコンパイルされたコード実行v / s pythonを使用し、GILステップの解釈されたコード実行のままです）。2 つ目は、C でコンパイルされたコードの実行を相対的な時間の単位として使用して、他の言語が同じ「ベンチマーク タスク」を完了するのにどれくらいの時間がかかるか = 1.0
結果を含む表の上にある章のヘッダーには、次のように書かれています (cit.:)
高性能 JIT コンパイラ
Julia の LLVM ベースの Just-In-Time (JIT) コンパイラと言語の設計を組み合わせることで、C のパフォーマンスに近づき、多くの場合、C のパフォーマンスに匹敵することができます
。と呼ばれる「ベンチマーク タスク」-s の.
pi-sum
これは解釈された Python にとって 2 番目に悪い時間であり、LLVM/JIT でコンパイルされた Julia コードまたは C でコンパイルされた代替よりも21.99 倍遅く実行されたことが示されました。
そこで、小さな実験の話が始まりました。
@numba.jit( JulSUM, nogil = True ):
リンゴとリンゴを比較してみましょう。julia コードが 22 倍高速に実行されると報告されている場合は、まず、単純に解釈された Python コードの実行を測定してみましょう。
>>> def JulSUM():
... sum = 0.
... j = 0
... while j < 500:
... j += 1
... sum = 0.
... k = 0
... while k < 10000:
... k += 1
... sum += 1. / ( k * k )
... return sum
...
>>> from zmq import Stopwatch
>>> aClk = Stopwatch()
>>> aClk.start();_=JulSUM();aClk.stop()
1271963L
1270088L
1279277L
1277371L
1279390L
1274231L
つまり、コアのpi-sum実行時間は約 1.27x.xxx [us] ~ 約 1.27~1.28 [s] です。
julia-lang Webサイトの言語プレゼンテーションの表の行をpi-sum考えると、LLVM/JIT を利用した julia コードの実行は約 22 倍速く、つまり57.92 [ms]未満で実行されるはずです。
>>> 1274231 / 22
57919
numba.jitでは、 ( v24.0 )を使用してオレンジをリンゴに変換しましょう。
>>> import numba
>>> JIT_JulSUM = numba.jit( JulSUM )
>>> aClk.start();_=JIT_JulSUM();aClk.stop()
1175206L
>>> aClk.start();_=JIT_JulSUM();aClk.stop()
35512L
37193L
37312L
35756L
34710L
したがって、JIT コンパイラーが機能した後、numba-LLVM を実行した python は、ベンチマーク時間を約 34.7 ~ 37.3 [ms]のどこかで示します。
もっと先に行ける？
確かに、numbaまだ多くの微調整を行っていませんが、コード例は非常に些細なものであり、将来的に驚くような進歩が見られることはあまりありません。
まず、ここで不要な GIL ステッピングを削除しましょう。
>>> JIT_NOGIL_JulSUM = numba.jit( JulSUM, nogil = True )
>>> aClk.start();_=JIT_NOGIL_JulSUM();aClk.stop()
85795L
>>> aClk.start();_=JIT_NOGIL_JulSUM();aClk.stop()
35526L
35509L
34720L
35906L
35506L
nogil=True
実行はそれほど長くはありません
が、それでも数 [ミリ秒] 短縮され、すべての結果が ~ 35.9 [ミリ秒] 未満になります。
>>> JIT_NOGIL_NOPYTHON_JulSUM = numba.jit( JulSUM, nogil = True, nopython = True )
>>> aClk.start();_=JIT_NOGIL_NOPYTHON_JulSUM();aClk.stop()
84429L
>>> aClk.start();_=JIT_NOGIL_NOPYTHON_JulSUM();aClk.stop()
35779L
35753L
35515L
35758L
35585L
35859L
nopython=True
すべての結果を一貫して ~ 35.86 [ms] 未満で
取得するための最後の仕上げのタッチのみを行います(対 LLVM/JIT-julia の ~ 57.92 [ms] )。
DSP 処理のエピローグ:
高速化された DSP 処理の追加の利点に関する OP の質問のために、Intel が IA64 プロセッサの内部性に最適化されたバイナリで新しい地平を開いた+ Intel Python
(Anaconda 経由) を試してテストすることができます。インテルの ILP4 の知識、ベクトル化、および実行時に独自の CPU が示す分岐予測の詳細に基づいて、CPU にバインドされた追加のトリックが実行される場合があります。これを比較するには、テストする価値があります (さらに、VisualStudio に統合された非破壊的なコード分析ツールを利用して、in-vitro コード実行のホットスポットをリアルタイムで分析することができます。これは、DSP エンジニアが大好きなものです。 、彼/彼女ではないですか？numba