論文の概要: Misleading Microbenchmarks on the Java Virtual Machines
- arxiv url: http://arxiv.org/abs/2605.23570v1
- Date: Fri, 22 May 2026 12:38:12 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-05-25 17:29:20.347377
- Title: Misleading Microbenchmarks on the Java Virtual Machines
- Title(参考訳): Java仮想マシン上のマイクロベンチマークの誤解
- Authors: Filippo Schiavio, Lubomír Bulej, Walter Binder,
- Abstract要約: Java仮想マシン(JVM)では、開発者はメソッドやクラスの最もパフォーマンスの良い実装を選択するためにマイクロベンチマークを使うことが多い。
本稿では,非現実的プロファイルを誘導する条件下でのマイクロベンチマークの使用が,既存のガイドラインに従っているにもかかわらず,どのように誤解を招くかを示す。
- 参考スコア(独自算出の注目度): 1.4885603159356078
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Developers often use microbenchmarks to choose the most performant implementation of a method or a class. On the Java Virtual Machine (JVM), this is commonly done using the Java Microbenchmark Harness (JMH) which addresses common pitfalls of measuring code performance on the JVM. However, even using JMH guidelines cannot overcome the fundamental issue of context. Microbenchmarks inherently execute code in isolation, without interference from other application code competing for CPU resources, such as cache or branch-predictor capacity. On managed runtimes with tiered dynamic compilation, such as the JVM, the speculative, profile-driven nature of compilation decisions means that code performance is highly dependent on profiles collected during early execution. Because profiles usually include also branch probabilities and receiver types (besides code hotness metrics), a badly designed microbenchmark may cause the JVM to collect an unrealistic profile, resulting in aggressive, yet misleading, optimizations, that would not occur in a real application. In this paper, we demonstrate how using microbenchmarks under conditions that induce the JVM to collect unrealistic profiles yields misleading results despite following existing guidelines. We also extend these guidelines by suggesting actions to make the microbenchmark results more representative.
- Abstract(参考訳): 開発者は、メソッドやクラスの最もパフォーマンスの良い実装を選択するために、マイクロベンチマークを使うことが多い。
Java仮想マシン(JVM)では、これは一般的にJava Microbenchmark Harness(JMH)を使って行われます。
しかし、JMHガイドラインを使うことでさえ、コンテキストの根本的な問題を克服することはできない。
Microbenchmarkは本質的に、キャッシュやブランチ予測能力といったCPUリソースと競合する他のアプリケーションコードから干渉することなく、独立してコードを実行する。
JVMのような階層化された動的コンパイルを備えたマネージドランタイムでは、コンパイル決定の投機的でプロファイル駆動的な性質は、コードパフォーマンスが早期実行時に収集されたプロファイルに大きく依存していることを意味する。
プロファイルは通常、分岐確率やレシーバタイプ(コードのホットネスメトリクスの他に)も含んでいるため、ひどい設計のマイクロベンチマークは、JVMが非現実的なプロファイルを収集する原因となり、その結果、実際のアプリケーションでは起こらない、攻撃的だが誤解を招く、最適化をもたらす可能性がある。
本稿では,JVMに非現実的なプロファイルの収集を誘導する条件下でのマイクロベンチマークの使用が,既存のガイドラインに従っているにも関わらず,どのように誤解を招くかを実証する。
マイクロベンチマークの結果をより代表的なものにするためのアクションを提案することで、これらのガイドラインを拡張します。
関連論文リスト
- JEDI: Java Evaluation of Declarative and Imperative Queries [1.6042394978941517]
ストリームベースのアプリケーションに特化したベンチマークが不足している。
この作業では、Stream APIをターゲットにしたベンチマークスイートであるJEDIを紹介します。
論文 参考訳(メタデータ) (2026-05-22T12:07:55Z) - MapReplay: Trace-Driven Benchmark Generation for Java HashMap [1.198637189064676]
アプリケーションベンチマークのリアリズムとマイクロベンチマークの効率を組み合わせたベンチマーク手法であるMapReplayを提案する。
MapReplayをDaCapo-ChopinとRenaissanceに適用すると、結果のスイートであるMapReplayBenchがアプリケーションレベルのパフォーマンストレンドを再現する。
論文 参考訳(メタデータ) (2026-03-14T16:46:09Z) - EVM-QuestBench: An Execution-Grounded Benchmark for Natural-Language Transaction Code Generation [9.472124187479915]
オンチェーントランザクションのシナリオでは、小さなエラーでさえ、ユーザにとって不可逆的な損失を引き起こす可能性がある。
EVM-QuestBenchは自然言語トランザクションスクリプト生成のための実行基盤ベンチマークである。
単一動作精度と複数ステップのワークフロー完了の間に永続的な非対称性を示す分割スコアを用いて,20のモデルを評価し,大きな性能ギャップを求める。
論文 参考訳(メタデータ) (2026-01-10T13:25:27Z) - MIB: A Mechanistic Interpretability Benchmark [77.35046700898326]
4つのタスクと5つのモデルにまたがる2つのトラックを持つメカニスティック解釈可能性ベンチマークMIBを提案する。
MIBを用いて、帰属とマスク最適化の手法が回路のローカライゼーションにおいて最適であることがわかった。
因果変数の局在化では、教師付きDAS法がニューロンより優れているが、SAEの特徴はニューロンより優れている。
論文 参考訳(メタデータ) (2025-04-17T17:55:45Z) - ThrowBench: Benchmarking LLMs by Predicting Runtime Exceptions [4.852619858744873]
大規模言語モデル(LLM)は、コード理解と合成の驚くべき能力を示している。
4つの異なるプログラミング言語で書かれた2,400以上の短いユーザ記述プログラムからなるベンチマークであるThrowBenchを紹介する。
我々は6つの最先端コードLLMのベンチマーク評価を行い、19~38%(F1スコア)の適度なパフォーマンスを確認した。
論文 参考訳(メタデータ) (2025-03-06T09:22:23Z) - DOCE: Finding the Sweet Spot for Execution-Based Code Generation [69.5305729627198]
本稿では,候補生成,$n$-best再ランク,最小ベイズリスク(MBR)復号化,自己老化などを含む包括的フレームワークを提案する。
本研究は,実行ベースメソッドの重要性と,実行ベースメソッドと実行フリーメソッドとの差を明らかにする。
論文 参考訳(メタデータ) (2024-08-25T07:10:36Z) - How to Prune Your Language Model: Recovering Accuracy on the "Sparsity
May Cry'' Benchmark [60.72725673114168]
下流データセットの微調整中における正確なBERTプルーニングの問題を再考する。
そこで我々は,SMCベンチマークの挑戦においても,プルーニングを成功させるための一般的なガイドラインを提案する。
論文 参考訳(メタデータ) (2023-12-21T03:11:30Z) - Defining Standard Strategies for Quantum Benchmarks [0.1759008116536278]
我々は、どのベンチマークも従うべき特徴のセットを定義し、ベンチマークと診断を区別する。
ベンチマーク最適化の問題点、それらの最適化がいつ適切か、どのように報告されるべきか、について論じる。
スケーラブルなミラー量子ボリュームベンチマークを導入する。
論文 参考訳(メタデータ) (2023-03-03T17:50:34Z) - The Benchmark Lottery [114.43978017484893]
ベンチマーク宝くじ」は、機械学習ベンチマークプロセスの全体的な脆弱さを記述している。
アルゴリズムの相対的性能は、異なるベンチマークタスクを選択するだけで大幅に変化する可能性がある。
論文 参考訳(メタデータ) (2021-07-14T21:08:30Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト(すべての情報・翻訳含む)の品質を保証せず、本サイト(すべての情報・翻訳含む)を使用して発生したあらゆる結果について一切の責任を負いません。