[論文レビュー] Clash of the Lambdas

Aggelos Biboudis, Nick Palladinos+1 more|arXiv (Cornell University)|Jun 25, 2014

Advanced Database Systems and Queries参考文献 7被引用数 8

ひとこと要約

この論文は、JVMおよび .NET プラットフォーム上の Java、C#、F#、Scala におけるラムダベースのストリーミング API のパフォーマンスを評価し、実装コストを隔離するためにマイクロベンチマークの結果を測定している。Java の成熟した JIT および実装技術が高いパフォーマンスをもたらす一方で、ScalaBlitz や LinqOptimizer のような最適化フレームワークは、一般的なクエリパターンの効率を著しく向上させることを明らかにした。

ABSTRACT

The introduction of lambdas in Java 8 completes the slate of statically-typed, mainstream languages with both object-oriented and functional features. The main motivation for lambdas in Java has been to facilitate stream-based declarative APIs, and, therefore, easier parallelism. In this paper, we evaluate the performance impact of lambda abstraction employed in stream processing, for a variety of high-level languages that run on a virtual machine (C#, F#, Java and Scala) and runtime platforms (JVM on Linux and Windows, .NET CLR for Windows, Mono for Linux). Furthermore, we evaluate the performance gain that two optimizing libraries (ScalaBlitz and LinqOptimizer) can offer for C#, F# and Scala. Our study is based on small-scale throughput-benchmarking, with significant care to isolate different factors, consult experts on the systems involved, and identify causes and opportunities. We find that Java exhibits high implementation maturity, which is a dominant factor in benchmarks. At the same time, optimizing frameworks can be highly effective for common query patterns.

研究の動機と目的

• 複数のハイレベルで VM ベースの言語におけるラムダ抽象のパフォーマンスオーバーヘッドを、ストリーミング API を通して評価すること。
• JVM および .NET プラットフォーム上での Java、C#、F#、Scala の実装の成熟度と最適化効果を比較すること。
• 最適化ライブラリ（例：ScalaBlitz、LinqOptimizer）が一般的なストリーミングワークロードに与える影響を評価すること。
• ラムダが多数使用されるワークロードにおけるパフォーマンスボトルネック（例：ボクシング、GC 圧力、JIT 動作）を隔離し、分析すること。
• ストリーム API における内部反復と外部反復のパフォーマンスおよびスケーラビリティへの影響を調査すること。

提案手法

• Linux および Windows プラットフォーム上でマイクロベンチマークを実施し、全言語で同等のデータ型と意味的抽象を用いた。
• 基本的な操作（偶数の平方和など）から始まり、複数のコンビネータを含む複雑なパイプラインを含む、複雑度を段階的に増加させた制御されたベンチマークスイートを用いた。
• シーケンシャルおよび並列実行の両方のパフォーマンスを測定し、スループットと GC 動作に注目した。
• エキスパートによるチューニングを適用し、JIT 動作への影響を隔離するために段階的コンパイルを無効化した。
• 便宜的オーバーヘッドを除いた言語間比較のため、手動ボクシング（refs ベンチマーク）の影響を評価した。
• ランタイムコストを低減するため、専用のライブラリ（例：ScalaBlitz、LinqOptimizer）およびコンパイラプラグイン（例：Miniboxing）の使用を検討した。

実験結果

リサーチクエスチョン

• RQ1 Java、C#、F#、Scala が JVM および .NET プラットフォーム上でラムダベースのストリーミング API のパフォーマンス特性をどのように比較できるか。
• RQ2 Java ランタイムにおける実装成熟度（例：C2 JIT）が、ラムダが多数使用されるワークロードにおいてパフォーマンスをどれほど支配的にするか。
• RQ3 ScalaBlitz や LinqOptimizer のような最適化フレームワークは、一般的なストリーミングクエリパターンのコストをどれほど効果的に低減できるか。
• RQ4 自動ボクシングはパフォーマンス劣化にどの程度影響を及ぼすか。また、手動ボクシングは言語間比較にどのように影響を及えるか。
• RQ5 JIT コンパイル動作（特に段階的コンパイル）は、Scala および Java のベンチマークにおいてパフォーマンスにどのように影響を及えるか。

主な発見

• Java は実装成熟度が高く、C2 JIT コンパイラがすべてのベンチマークで一貫して優れたパフォーマンスを発揮した。
• 段階的コンパイルを無効化したことで、大多数の Scala および Java ベンチマークでパフォーマンスが向上した。特に Scala では、段階的コンパイルを有効化した場合に約 10% のパフォーマンス劣化が観察された。
• refs ベンチマーク（手動ボクシング）では、Java がわずかに他を上回ったが、便宜的オーバーヘッドが存在しないため、Scala のパフォーマンスは直接比較可能になった。
• Scala-strict 並列テストは、内部変換器のほぼ完全なインライン化と効率的なメモリ使用のおかげで、高い競争力を示した。
• Scala の Filtered 特性では、length 演算子における遅延値からの内部ボクシングが、並列実行時でさえも測定可能な GC 圧力を引き起こした。
• ScalaBlitz や LinqOptimizer のような最適化フレームワークは、一般的なクエリパターンにおいて顕著なパフォーマンス向上を示し、Java に対しても同様のツールの開発の可能性が示唆された。