Add adaptive compressed telemetry execution benchmark

TASK_DETAILS.md

@@ -204,14 +204,18 @@ We welcome new engineering problem ideas — even without complete verification
       <td>Polarization-multiplexed holography</td>
     </tr>
     <tr>
-      <td rowspan="2"><b>ComputerSystems</b></td>
+      <td rowspan="3"><b>ComputerSystems</b></td>
       <td><code>MallocLab</code></td>
       <td>High-performance C memory allocator (utilization &amp; throughput)</td>
     </tr>
     <tr>
       <td><code>DuckDBWorkloadOptimization</code></td>
       <td>Index / materialized-view selection and query rewriting on official DuckDB workloads</td>
     </tr>
+    <tr>
+      <td><code>AdaptiveCompressedTelemetryExecution</code></td>
+      <td>CPU-measured adaptive telemetry compression with lossless decoding, compressed-domain queries, and storage/compute cost trade-offs</td>
+    </tr>
     <tr>
       <td><b>EngDesign</b></td>
       <td><code>CY_03, WJ_01, XY_05, AM_02, AM_03, YJ_02, YJ_03</code></td>

TASK_DETAILS_zh-CN.md

@@ -204,14 +204,18 @@ Frontier-Eng 目前已覆盖以下领域的任务。每个任务均配有可运
       <td>偏振复用全息</td>
     </tr>
     <tr>
-      <td rowspan="2"><b>ComputerSystems</b></td>
+      <td rowspan="3"><b>ComputerSystems</b></td>
       <td><code>MallocLab</code></td>
       <td>高性能 C 动态内存分配器（utilization &amp; throughput）</td>
     </tr>
     <tr>
       <td><code>DuckDBWorkloadOptimization</code></td>
       <td>基于 DuckDB 官方 workload 的索引 / 物化视图选择与查询改写</td>
     </tr>
+    <tr>
+      <td><code>AdaptiveCompressedTelemetryExecution</code></td>
+      <td>实测 CPU 的自适应遥测数据压缩、无损解码、压缩态查询与存储/计算成本权衡</td>
+    </tr>
     <tr>
       <td><b>EngDesign</b></td>
       <td><code>CY_03, WJ_01, XY_05, AM_02, AM_03, YJ_02, YJ_03</code></td>

benchmarks/ComputerSystems/AdaptiveCompressedTelemetryExecution/README.md

@@ -0,0 +1,79 @@
+# Adaptive Compressed Telemetry Execution
+
+This CPU benchmark co-designs a telemetry column format and the operators that
+consume it. Candidate C++ code encodes five correlated columns into opaque blocks,
+decodes them losslessly, and answers exact filters and conditional sums directly
+from those blocks. The evaluator compiles and runs the candidate, measures real
+CPU time, checks every decoded byte and query answer, and reports both absolute
+performance and a public cost-per-logical-TiB objective.
+
+The task is motivated by the CPU and representation-efficiency requirements in the
+[OpenTelemetry Logs Data Model](https://opentelemetry.io/docs/specs/otel/logs/data-model/)
+and by recent work on composable, query-aware formats such as
+[FastLanes](https://vldb.org/pvldb/vol18/p4629-afroozeh.pdf).
+
+## Files
+
+- `Task.md`: full API, workload, correctness, measurement, and scoring contract.
+- `references/problem_config.json`: public execution, pricing, and scenario settings.
+- `scripts/init.cpp`: editable raw-column starter implementation.
+- `baseline/solution.cpp`: immutable copy of the raw starter.
+- `baseline/result_log.txt`: recorded starter measurement.
+- `verification/codec_api.h`: immutable candidate ABI.
+- `verification/benchmark_driver.cpp`: immutable timed C++ driver.
+- `verification/evaluator.py`: dataset generator, compiler, oracle, and scorer.
+- `verification/test_evaluator.py`: end-to-end and integrity regression tests.
+- `frontier_eval/`: unified-task metadata.
+
+## Requirements
+
+- Python 3.10 or newer; only the standard library is used.
+- `g++` with C++20 support.
+- A Linux-like host for CPU affinity and resource limits.
+
+No database, service, network access, accelerator, or task-specific Python package
+is required. The driver pins each timed process to one available CPU.
+
+## Direct evaluation
+
+From this task directory:
+
+```bash
+python verification/evaluator.py scripts/init.cpp
+```
+
+The uncompressed starter must be correct and scores exactly `1.0`. Measurements
+vary by CPU, but the evaluator measures the immutable baseline in the same run for
+every changed candidate. A score above `1.0` reduces the modeled monthly cost using
+measured storage bytes and CPU time.
+
+Compilation deliberately uses `-march=native`. Absolute throughput, modeled cost,
+and candidate-to-baseline ratios can therefore vary across CPU models and compiler
+versions. Compare leaderboard runs only within the same evaluation host and
+environment; the co-measured immutable baseline controls within-run comparisons.
+
+To retain detailed measurements:
+
+```bash
+python verification/evaluator.py scripts/init.cpp \
+  --metrics-out metrics.json --artifacts-out artifacts.json
+```
+
+## Unified evaluation
+
+From the repository root:
+
+```bash
+python -m frontier_eval \
+  task=unified \
+  task.benchmark=ComputerSystems/AdaptiveCompressedTelemetryExecution \
+  algorithm=openevolve \
+  algorithm.iterations=0
+```
+
+## Editing contract
+
+Only edit the code between `EVOLVE-BLOCK-START` and `EVOLVE-BLOCK-END` in
+`scripts/init.cpp`. Preserve the function signatures in `verification/codec_api.h`.
+The editable block may add standard or compiler-provided headers, helpers, metadata,
+adaptive encoding selection, SIMD code, and any self-contained block representation.

benchmarks/ComputerSystems/AdaptiveCompressedTelemetryExecution/Task.md

@@ -0,0 +1,179 @@
+# Task: Adaptive Compressed Telemetry Execution
+
+## 1. Engineering problem
+
+Telemetry backends continuously ingest timestamped events and later scan them for
+incident response, dashboards, retention, and audit queries. Storing every field as
+an uncompressed 64-bit value is fast but expensive. Aggressive compression can
+reduce storage traffic while making ingestion, full decoding, or selective queries
+more CPU-intensive. The useful engineering problem is therefore not compression in
+isolation: it is joint design of a block representation and the operators that use
+that representation.
+
+The [OpenTelemetry Logs Data Model](https://opentelemetry.io/docs/specs/otel/logs/data-model/)
+defines common timestamp, severity, resource, and attribute concepts and explicitly
+calls out efficient serialization and space use. Modern systems research similarly
+co-designs compression and execution: the
+[FastLanes file format](https://vldb.org/pvldb/vol18/p4629-afroozeh.pdf) uses
+composable data-parallel encodings, multi-column relationships, partial decoding,
+and compressed-vector access, while
+[MorphStore](https://arxiv.org/abs/2004.09350) studies complete analytical pipelines
+over compressed representations.
+
+This benchmark presents the same open design space in a self-contained CPU task.
+Candidate code is actually compiled and timed; there is no analytical prediction of
+codec or query performance.
+
+## 2. Logical schema
+
+Every row contains five unsigned 64-bit columns:
+
+| Index | Column | Meaning |
+|---:|---|---|
+| 0 | `timestamp_ns` | Event time in Unix nanoseconds; nondecreasing within a scenario |
+| 1 | `service_id` | Service or tenant identifier |
+| 2 | `severity` | OpenTelemetry-style numeric severity |
+| 3 | `duration_us` | Request or operation duration in microseconds |
+| 4 | `payload_bytes` | Event payload size in bytes |
+
+Rows are divided into public `block_rows`-sized blocks. The candidate owns the
+entire byte representation inside each block and may encode columns independently,
+jointly, or adaptively.
+
+## 3. Candidate API
+
+The immutable declarations are in `verification/codec_api.h`:
+
+```cpp
+bool encode_block(const BlockView& input,
+                  std::vector<std::uint8_t>& encoded);
+
+bool decode_block(const EncodedView& encoded,
+                  const MutableBlock& output);
+
+std::uint64_t query_block(const EncodedView& encoded,
+                          const QuerySpec& query);
+```
+
+`EncodedView` supplies the opaque bytes and row count to a fresh process. An encoded
+block must therefore be self-contained; pointers, process-global state, source-file
+references, and external side files are invalid representations.
+
+`decode_block` must reproduce every original value exactly. The evaluator allocates
+the output columns.
+
+## 4. Exact query semantics
+
+All ranges are inclusive and arithmetic uses unsigned 64-bit values. Inputs are
+chosen so correct aggregates do not overflow.
+
+- `CountEqual`: count rows where `filter_column == low`.
+- `CountRange`: count rows where `low <= filter_column <= high`.
+- `SumWhereEqual`: sum `value_column` where `filter_column == low`.
+- `SumWhereRange`: sum `value_column` where
+  `low <= filter_column <= high`.
+
+A correct baseline may decode inside `query_block`. More advanced solutions can
+answer from metadata, dictionaries, bit-packed vectors, learned residuals, or other
+compressed representations.
+
+## 5. Workloads
+
+The evaluator generates three deterministic, multi-column datasets:
+
+1. `steady_api_traffic`: regular timestamps, low service cardinality, and mostly
+   informational events.
+2. `bursty_multitenant_observability`: rotating hot tenants, burst boundaries,
+   higher cardinality, and localized error periods.
+3. `incident_distribution_shift`: correlated changes in service popularity,
+   severity, duration, and payload during an incident.
+
+Each scenario uses a separate seed and contains eight exact query templates covering
+equality, ranges, conditional sums, time windows, hot values, and low-selectivity
+conditions. The generator seed can be overridden by the evaluator CLI for robustness
+testing.
+
+## 6. Verification and measurement
+
+The evaluator performs the following steps:
+
+1. Enforce the source-size limit and compile the candidate with
+   `g++ -std=c++20 -O3 -march=native`.
+2. Generate each raw dataset outside the timed region.
+3. Run encoding in a CPU-pinned child process after warm-up.
+4. Delete the raw input, then start a fresh process to decode the encoded file.
+5. Compare the complete decoded binary output byte-for-byte with the original.
+6. Start another fresh process, execute every query over every block, and compare
+   all integer results with an independent Python oracle.
+7. Report median, minimum, and maximum wall time over the configured measured rounds.
+
+File loading, compilation, encoded-file writing, decoded-file writing, and result
+serialization are excluded from the timed regions. Candidate allocation and the
+actual encode/decode/query functions are included. Each child is pinned to one CPU,
+so the elapsed time is a practical single-core performance measurement. A memory
+limit, process CPU limit, wall timeout, encoded-size limit, and output-file limit are
+enforced.
+
+The evaluator reports:
+
+- encode and decode GiB/s;
+- compressed-query batch GiB/s;
+- encoded bytes and compression ratio;
+- per-phase timing samples and peak resident memory; and
+- cost components and score for every scenario.
+
+Scenario failures are isolated. The evaluator records baseline, candidate, and
+score errors on the affected scenario and continues through the remaining public
+scenarios. Successful ratios remain available through `partial_combined_score` for
+diagnosis, but any failed scenario keeps the official `valid` and `combined_score`
+at zero so a candidate cannot benefit by skipping a difficult workload.
+
+## 7. Economic objective
+
+Let:
+
+- `r = encoded_bytes / logical_bytes`;
+- `H_e`, `H_d`, and `H_q` be measured encode, full-decode, and fixed-query-batch
+  core-hours extrapolated to one logical TiB;
+- `P_s` be the public storage price coefficient in dollars per GiB-month;
+- `P_c` be the public CPU price coefficient in dollars per core-hour; and
+- `D` and `Q` be scenario-specific monthly full-decode and query-batch counts.
+
+The scenario cost is:
+
+```text
+storage_cost = 1024 * r * P_s
+cpu_cost     = P_c * (H_e + D * H_d + Q * H_q)
+monthly_cost_per_logical_TiB = storage_cost + cpu_cost
+```
+
+The coefficients are versioned workload parameters, not claims about a particular
+cloud vendor. They make the storage/CPU trade-off explicit while every performance
+input to the formula comes from executed candidate code.
+
+For scenario `i`:
+
+```text
+ratio_i = baseline_monthly_cost_i / candidate_monthly_cost_i
+```
+
+`combined_score` is the geometric mean of the three ratios. The raw starter is the
+immutable baseline and scores exactly `1.0`; larger is better.
+
+## 8. Correctness and resource gates
+
+Any compilation error, timeout, crash, false return, oversized block, incomplete
+decode, byte mismatch, query mismatch, or non-finite metric yields
+`valid=0.0` and `combined_score=0.0`.
+
+The public limits are in `references/problem_config.json`:
+
+- candidate source: at most 1,000,000 bytes;
+- encoded block: at most twice its raw bytes plus a small fixed allowance;
+- process address space: 1 GiB;
+- at most 64 candidate processes per real user where `RLIMIT_NPROC` is supported;
+- one pinned CPU per timed process; and
+- no external libraries, assets, services, or network access.
+
+The task permits portable C++, compiler intrinsics, adaptive block selection, and
+self-contained metadata. Only the code inside the EVOLVE markers may change.

benchmarks/ComputerSystems/AdaptiveCompressedTelemetryExecution/baseline/result_log.txt

@@ -0,0 +1,62 @@
+AdaptiveCompressedTelemetryExecution baseline validation
+Date: 2026-07-17
+
+Host
+  OS: Linux 5.15.0-153-generic x86_64
+  CPU: 2 x AMD EPYC 7313 (32 physical / 64 logical cores total)
+  Python: 3.10.12
+  Compiler: g++ 11.4.0
+  Compile target: -O3 -march=native (measurements are host-dependent)
+  Candidate process cap: RLIMIT_NPROC=64 where supported
+  GPU/container/external service: not used
+
+Direct command (from task directory)
+  python verification/evaluator.py scripts/init.cpp \
+    --metrics-out metrics.json --artifacts-out artifacts.json
+
+Direct metrics
+  valid: 1.0
+  combined_score: 1.0
+  partial_combined_score: 1.0
+  runtime_s: 6.591881075873971
+  scenario_count: 3
+  successful_scenario_count: 3
+  failed_scenario_count: 0
+  candidate_compression_ratio: 1.0000755310058593
+  candidate_encode_gib_s: 15.891468137733515
+  candidate_decode_gib_s: 36.09563159308368
+  candidate_query_batch_gib_s: 3.204557804794705
+  candidate_total_monthly_cost_per_tib: 74.20395162021418
+
+Per-scenario frozen starter result
+  steady_api_traffic
+    compression_ratio=1.0000755310058593
+    encode_gib_s=16.26411464925721
+    decode_gib_s=35.57928773112305
+    query_scanned_gib_s=26.527365035557704
+    monthly_cost_per_logical_tib=25.678239670068667
+    score_ratio=1.0
+  bursty_multitenant_observability
+    compression_ratio=1.0000755310058593
+    encode_gib_s=16.092824855684697
+    decode_gib_s=36.23796783506379
+    query_scanned_gib_s=27.275291745248598
+    monthly_cost_per_logical_tib=24.575535172063333
+    score_ratio=1.0
+  incident_distribution_shift
+    compression_ratio=1.0000755310058593
+    encode_gib_s=15.347782218457338
+    decode_gib_s=36.48177895660945
+    query_scanned_gib_s=23.440786398253035
+    monthly_cost_per_logical_tib=23.950176778082177
+    score_ratio=1.0
+
+Development headroom check
+  A temporary fixed-width delta codec was validated by the same evaluator. It
+  stored timestamp deltas plus narrowed service, severity, duration, and payload
+  fields; it was not committed as the starter. The candidate passed byte-exact
+  decoding and all independent query oracles, scored 2.556401106833809, reduced
+  compression ratio from 1.0000755310058593 to 0.32512435913085935, and reduced
+  total modeled monthly cost from 74.1947212474412 to 29.255996084436042. Its
+  minimum per-scenario score was 2.248306349794879. This confirms substantial
+  headroom for richer adaptive formats and compressed execution strategies.