[論文レビュー] There is no fast lunch: an examination of the running speed of evolutionary algorithms in several languages

J. J. Merelo, Pablo García‐Sánchez+2 more|arXiv (Cornell University)|Nov 3, 2015

Evolutionary Algorithms and Applications参考文献 9被引用数 3

ひとこと要約

この論文は、Lua、JavaScript（Node.js）、Python、Scala の4つの人気プログラミング言語を用いて、ビット反転変異という進化的アルゴリズム（EA）の演算処理の実行速度をベンチマークしている。両言語とも文字列表現とベクター表現を用いている。結果として、Python や JavaScript のようなインタプリタ型言語が、C++ や Java、Scala のようなコンパイル型言語よりも、さまざまな問題サイズにおいて高速であることが判明し、科学的計算タスクにおいてコンパイル型言語が常に高速であるという仮定に疑問を呈している。

ABSTRACT

It is quite usual when an evolutionary algorithm tool or library uses a language other than C, C++, Java or Matlab that a reviewer or the audience questions its usefulness based on the speed of those other languages, purportedly slower than the aforementioned ones. Despite speed being not everything needed to design a useful evolutionary algorithm application, in this paper we will measure the speed for several very basic evolutionary algorithm operations in several languages which use different virtual machines and approaches, and prove that, in fact, there is no big difference in speed between interpreted and compiled languages, and that in some cases, interpreted languages such as JavaScript or Python can be faster than compiled languages such as Scala, making them worthy of use for evolutionary algorithm experimentation.

研究の動機と目的

• 進化的アルゴリズム（EA）の実装において、コンパイル型言語（例：C++、Java、Scala）が解釈型言語（例：Python、JavaScript、Perl）よりも本質的に高速であるという一般的な仮定に挑戦すること。
• 広く使われているプログラミング言語が、EA のコアな変異演算子を実行する際のパフォーマンスを評価すること。これは頻繁に呼び出されながらも、しばしば無視されがちな演算である。
• 言語の選択が、さまざまな遺伝子染色体サイズやデータ表現（ビットストリング対ブールベクター）において、実行時間に顕著な影響を与えるかどうかを評価すること。
• 研究者が開発のしやすさとパフォーマンスの両面を考慮して、科学的計算の文脈でプログラミング言語を選択する根拠を提供すること。

提案手法

• 8ビットから65,536ビットまでのさまざまな長さのバイナリ文字列に対して、Lua、JavaScript（Node.js）、Python、Scala の4言語でビット反転変異演算をベンチマークすること。
• 2つのデータ表現を用いて変異を実装する：ビットストリング（'0' と '1' の文字列）とベクター表現（Scala では Vector[Boolean]、他の言語では配列など）。
• 言語やランタイムの特性に起因するパフォーマンスの差を孤立させるために、言語間で一貫した最小限の実装を採用し、アルゴリズム的またはライブラリレベルの最適化を避ける。
• 各テストケースで10,000回の変異処理の実行時間を測定し、統計的分析のためのCSV形式で結果を記録すること。
• R と ggplot2 を用いてパフォーマンスのトレンドを可視化し、サイズに応じたパターン、パラメータの飽和、パフォーマンスの劣化を特定すること。
• 複数の問題サイズにわたる分析を通じて、スケーラビリティを評価し、言語固有のパフォーマンス特性を同定すること。

実験結果

リサーチクエスチョン

• RQ1 進化的アルゴリズムにおける変異演算子の実行時間に、プログラミング言語の選択が顕著に影響を与えるか？
• RQ2 Python や JavaScript、Lua のような解釈型言語は、C++ や Java、Scala のようなコンパイル型言語よりも、基本的な EA 演算において遅いか？
• RQ3 異なるデータ表現（ビットストリング対ブールベクター）は、言語ごとにパフォーマンスにどのように影響を与えるか？
• RQ4 実行時間は遺伝子染色体サイズに対して非線形的に変化するか？ また、サイズに依存するパラメータの飽和点や変曲点が存在するか？
• RQ5 開発速度とエコシステムの支援を考慮した場合、解釈型言語が実世界の EA ワークロードにおいてコンパイル型言語を上回る性能を示せるか？

主な発見

• Lua は小規模な遺伝子染色体サイズ（128ビットまで）において最も高速なパフォーマンスを示し、この範囲で他のすべての言語を上回った。
• Python と JavaScript（Node.js）は、広いサイズ範囲にわたり非常に一貫したパフォーマンスを示し、1,024ビットまで文字列サイズに依存しない実行時間となった。
• より大きな遺伝子染色体サイズ（1,024ビット以上）においても、Python と JavaScript は強力なパフォーマンスを維持し、特に最大サイズ範囲では Python が全体で最も速かった。
• Scala は JVM をターゲットとするコンパイル型言語であるにもかかわらず、128ビットを超えるほとんどの問題サイズにおいて、Python や JavaScript のような解釈型言語に劣った。
• 言語間のパフォーランス格差はサイズに応じて一貫していなかった。一部の言語（例：Lua）はパラメータの飽和を示しており、実行時環境における文字列処理の効率性を示唆している。
• データ表現の選択（ビットストリング対ベクター）は、サイズが大きくなるに従い効果が薄れるが、測定可能な影響を及ぼしており、解釈型言語ではビットストリングが一般的に高速であった。