docs: refine detailed estimation package taxonomy [skip-ci]

Author: yoshifuminakamura

docs/cx/ESTIMATION_PACKAGE_SPEC.md

@@ -100,6 +100,48 @@ The target design is that the application side only needs to specify:
 Estimation methods are strongly coupled with how the required measurement data is obtained.
 Therefore BenchKit should preferably be able to represent not only the estimation model, but also the measurement assumptions of the method as part of the package.
 
+### 3.3.1 取得方式ごとの詳細パッケージ / Detailed Packages by Acquisition Path
+
+詳細推定パッケージは、単に「詳細推定」でひとまとめにせず、少なくとも取得方式ごとに区別できることが望ましい。
+たとえば以下のような区別を許容すべきである。
+
+- `instrumented_app_sections`
+  - アプリ自前の区間時間や区間別結果を入力とする package
+- `instrumented_tool_sections`
+  - Caliper などの外部ツール由来の区間時間や区間別結果を入力とする package
+- `counter_based`
+  - 特定区間に対して採取された詳細性能カウンターを入力とする package
+
+Detailed estimation packages should not be grouped together as a single undifferentiated category.
+They should preferably be distinguishable at least by acquisition path, for example:
+
+- `instrumented_app_sections`
+  - packages that use application-defined interval timings or section-wise results
+- `instrumented_tool_sections`
+  - packages that use interval timings or section-wise results from external tools such as Caliper
+- `counter_based`
+  - packages that use detailed counters collected for specific sections
+
+### 3.3.2 区間ごとの複合推定 / Section-Wise Composite Estimation
+
+推定パッケージは、単一手法だけでなく、区間ごとに異なる推定方式を束ねる複合パッケージであってもよい。
+特に以下を許容すべきである。
+
+- 計算区間はカウンターベース
+- 通信区間は別個の通信モデル
+- その他の区間は区間時間ベース
+
+この場合、BenchKit は最終 FOM が複数区間の推定結果の合成であることを受け入れられるべきである。
+
+An estimation package may be a composite package that combines different estimation methods for different sections, rather than a single method.
+In particular, the framework should allow cases such as:
+
+- compute sections estimated with counter-based methods
+- communication sections estimated with a separate communication model
+- other sections estimated from interval timings
+
+In such cases, BenchKit should be able to accept that the final FOM is composed from multiple section-wise estimation results.
+
 ### 3.4 Git 公開を前提にしない / Do Not Assume Git Publication
 
 推定パッケージは、常に Git 管理下に置けるとは限らない。
@@ -200,6 +242,7 @@ Examples:
 - 任意入力
 - 補助入力
 - 外部入力
+- 区間ごとの必要入力
 
 The package must define the inputs required for estimation.
 
@@ -209,6 +252,7 @@ It should preferably be able to express at least:
 - optional inputs
 - auxiliary inputs
 - external inputs
+- section-wise required inputs
 
 ### 4.4 適用可能性判定 / Applicability Evaluation
 
@@ -316,17 +360,21 @@ These are suitable for high-frequency runs and PoC work.
 
 例:
 
-- `section_breakdown_scaling`
-- `annotated_interval_model`
-- `external_counter_model`
+- `instrumented_app_sections`
+- `instrumented_tool_sections`
+- `counter_based_section_model`
+- `communication_section_model`
+- `composite_section_model`
 
 これらは、深い分析や将来機評価に向く。
 
 Examples:
 
-- `section_breakdown_scaling`
-- `annotated_interval_model`
-- `external_counter_model`
+- `instrumented_app_sections`
+- `instrumented_tool_sections`
+- `counter_based_section_model`
+- `communication_section_model`
+- `composite_section_model`
 
 These are suitable for deeper analysis and future-system evaluation.
 

docs/cx/ESTIMATION_SPEC.md

@@ -90,15 +90,37 @@ At least conceptually, the estimation flow should separate:
 - 簡易推定:
   FOM、ノード数、既知の比較基準など少数の情報から行う推定
 - 詳細推定:
-  section、overlap、詳細性能カウンター、アノテーション区間時間などを使う推定
+  アプリ自前の区間時間、外部ツール由来の区間時間、詳細性能カウンターなどを使う推定
 
 Estimation should not always assume detailed counters or detailed annotations.
 At minimum, the following stages should be able to coexist:
 
 - lightweight estimation:
   estimation from a small number of inputs such as FOM, node count, and known comparison baselines
 - detailed estimation:
-  estimation using section, overlap, detailed counters, or annotated interval timings
+  estimation using application-defined interval timings, tool-derived interval timings, or detailed counters
+
+### 3.2.1 詳細推定の取得方式差異 / Different Acquisition Paths Within Detailed Estimation
+
+詳細推定は単一の方式として扱うべきではない。
+少なくとも、以下の取得方式の違いを区別できることが望ましい。
+
+- `instrumented_app_sections`
+  - アプリ自前で出力された区間時間や区間別結果に基づく推定
+- `instrumented_tool_sections`
+  - Caliper などの外部ツール由来の区間時間や区間別結果に基づく推定
+- `counter_based`
+  - 特定区間に対して詳細性能カウンターが採取されていることを前提とする推定
+
+Detailed estimation should not be treated as a single undifferentiated method.
+At minimum, it should be possible to distinguish the following acquisition paths:
+
+- `instrumented_app_sections`
+  - estimation based on interval timings or section-wise results emitted by the application itself
+- `instrumented_tool_sections`
+  - estimation based on interval timings or section-wise results collected by external tools such as Caliper
+- `counter_based`
+  - estimation that assumes detailed counters are available for specific sections
 
 ### 3.3 追跡可能性 / Traceability
 
@@ -224,6 +246,14 @@ However, from the perspective of BenchKit, the following should be identifiable:
 - scaling method
 - future-system assumption
 
+また、推定モデルは常に単一モデルである必要はない。
+区間ごとに異なる推定方式を組み合わせる複合推定を許容すべきである。
+特に、計算区間、通信区間、入出力区間などに対して、別々の推定方式を適用できることが望ましい。
+
+The estimation model need not always be a single monolithic model.
+Composite estimation that combines different estimation methods for different sections should be allowed.
+In particular, it is desirable to apply separate estimation methods to compute, communication, and I/O sections.
+
 ### 4.4 比較基準 / Comparison Baseline
 
 推定では、比較基準となる benchmark result が重要である。
@@ -268,6 +298,12 @@ Lightweight estimation without section breakdown, overlap, communication interva
 
 When this kind of adjustment is applied, it must be made explicit in `assumptions` or `model` in Estimate JSON.
 
+また、通信区間の推定方式は、計算区間とは独立に切り替え可能であることが望ましい。
+たとえば、計算区間はカウンターベース、通信区間は別個の通信モデル、その他の区間は区間時間ベースという組合せを許容すべきである。
+
+In addition, the estimation method for communication sections should preferably be switchable independently from that of compute sections.
+For example, the framework should allow combinations such as counter-based estimation for compute sections, a separate communication model for communication sections, and interval-timing-based estimation for other sections.
+
 ### 4.5 適用可能性判定 / Applicability Evaluation
 
 推定実行前に、対象方式が必要とする入力が揃っているかを判定できることが望ましい。
@@ -326,9 +362,10 @@ BenchKit は少なくとも、以下の推定方式を受け入れられるこ
 
 入力:
 
-- section / overlap
+- アプリ自前の区間時間や区間別結果
+- 外部ツール由来の区間時間や区間別結果
 - 詳細性能カウンター
-- アノテーション区間時間
+- 区間ごとの方式切替情報
 - より複雑なモデルや外部モデル
 - 各システム側のターゲットノード数
 
@@ -366,9 +403,10 @@ If additional correction terms are introduced, they should be treated not as the
 
 Inputs:
 
-- section / overlap
+- application-defined interval timings or section-wise results
+- tool-derived interval timings or section-wise results
 - detailed performance counters
-- annotated interval timings
+- section-wise method-selection information
 - more complex or external models
 - target node count for each system