속성:Observation
직접 확인한 결과를 적습니다. 원인에 대한 해석은 따로 적습니다.
p
Path resolution produced the base /usr/bin/python3.12 executable, so sys.prefix no longer identified the project .venv. The calibration CLI failed its venv guard 3.4 seconds after Qwen phase start, before any GPU compute process or generation artifact. +
The lexical project venv and private vLLM snapshot passed. During Qwen engine initialization, ZMQ rejected its generated ipc path because the Unix sockaddr path exceeded 107 bytes. The suite failed before any GPU compute process or generation record. +
workloads=applications on real mobile devices; baselines=Android memory reclamation; metrics=response time; results=up to 43.6% improvement +
workloads=mixed prefill/decode LLM serving in Sarathi-Serve; baselines=non-overlapped/coarse-overlap attention; metrics=attention speedup and serving throughput; results=up to 59% attention speedup, 28% mean; up to 22% offline throughput +
workloads=64-byte cache lines; 40-bit DDR5 channels; multiple memory fault models; baselines=fixed ECC plus MAC designs; metrics=fault correction; detection probability; MAC width; results=near-100% detection; up to 60-bit MAC; supports multiple correction modes +
Xen server의 다양한 조합에서 평균전력을 오차 5% 이내, sustained power를 10% 이내로 예측했다. 대표 사례에서는 budget을 만족하면서 한 서버의 application 수를 baseline 2개에서 3개로 늘렸다. +
workloads=public memory-error logs; projected DDR5, HBM3, and LPDDR5 systems; baselines=alternative on-die ECC and repair configurations; metrics=predicted system reliability; fault coverage; results=no quantitative headline stated in accessible primary abstract +
workloads=KV workloads on Optane DCPMM and NVMe; baselines=state-of-the-art KV stores; metrics=throughput; tail latency; results=Up to 13.1× throughput. +
현재 확인된 것은 작업 제목뿐입니다. 출판 여부, workload, baseline, metric, 구현과 정량 결과는 확인되지 않았습니다. +
workloads=Alibaba/Ant production, tens of thousands containers/day; CPU, memory, I/O benchmarks; baselines=nested KVM; metrics=memory virtualization performance; CPU/I/O performance; results=Outperforms nested KVM for concurrent memory virtualization; exact aggregate not abstract-verified. +
r
workloads=buffered-I/O workloads on high-bandwidth SSDs; baselines=ext4, F2FS, Btrfs, XFS, ScaleCache; metrics=throughput and latency; results=up to 3.91x throughput and 82.80x latency improvement +
MongoDB/Linux prototype의 YCSB scan에서 처리량은 noop 147.92, deadline 150.25, cfq 145.40, coop 150.76 ops/s로 비슷했지만 tail latency는 CFQ 대비 최대 57%, noop/deadline 대비 최대 32% 감소했다. +
PostgreSQL과 Redis에서 blind all-write caching 대비 최대 2.2배 성능과 최대 87% write-traffic 감소를 보였다. SSD NVWC에서 PostgreSQL은 ALL 대비 약 1.8-2.2배, SYNC 대비 2.2-2.5배였다. Redis에서는 ALL 대비 throughput 17-32% 및 47-55% 향상과 cached write 20-29% 및 84-87% 감소를 보였으며 99.99th latency는 79-83ms 대 기존 1초 초과였다. +
1) Triton rebase는 3.76–7.82배 빨랐지만 모든 측정점에서 최대 절대 오차 기준 2e-4를 넘었고, 65,536 keys에서 1.41e-2였다. 2) FNO에서는 네 shape 모두 native complex einsum이 가장 빨랐다. stacked 3M의 output-scale 상대 오차는 6.37e-7 이하였으나 native 대비 속도는 0.28–0.37배였다. 3) fused LoRA는 N=4–128에서 2.95–81.37배 빨랐지만 affine 모델 R²=0.314, speedup 오차 35–61%였고 batch 95→143에서 요청당 비용이 1.76배 증가했다. 4) RoPE fusion의 bf16 forward/gradient 상대 오차는 각각 0.48%/0.58% 이하였고 forward는 1.05–1.22배 빨랐으나 seq_len 2048의 forward+backward는 0.74배였다. 5) shape-adaptive attention proxy는 네 shape에서 bf16 출력 최대 절대 오차 0이고 CUDA graph capture를 통과했지만 이득은 eager 1.04–1.11배, graph 1.02–1.06배였다. 6) CUDA BSR 63개 지점은 모두 수치적으로 유효했지만 크기 1024/2048은 측정 범위에서 dense를 이기지 못했다. 크기 4096의 crossover sparsity는 block 16/32/64에서 각각 86.2%/71.9%/60.7%였고 최대 speedup은 1.73/2.30/2.42배였다. +
spectral-operator-compiler [scientific outcome=negative]: The FNO spectral contraction 'bim,iom->bom' is not multiply-bound: its wall-clock cost ratio R = t_complex/t_real over the identically-shaped real contraction caps at ~2.6 (Cin=Cout=512) and never clears the R>3 threshold required for any Karatsuba/3-multiply implementation to yield a wall-clock win (upper bound min(R/3,4/3) ≤ 0.88 < 1). A same-BLAS square complex GEMM control clears R>3 (R→4.0 at n=2048), so the boundedness is a property of the FNO batched-mode shape (many small GEMMs), not the library.; validation: python -m pytest -q → 279 passed (264 prior + 15 new); python -m benchmarks.bench_multiply_boundedness → FNO R caps 2.6, GEMM control R→4.0; JSON artifact written; Re-ran benchmark 4x to confirm the channel-heavy row stabilizes at R≈2.6 (earlier 3.96 was noise) under best-of-9; commit 0bf1148b9cc8731097d190863f60685a2befd46c; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1 +
multi-lora-fusion [scientific outcome=positive]: For fused multi-LoRA GEMMs on CPU, the per-request-latency-vs-batch curve has TWO distinct capacity knees at the last-level cache, on two different tensors, not one graded transition: the total working set crosses the LLC first (a graded knee), and the output tensor Y crosses it second as a razor-sharp step at Y==LLC. A single-knee model of ANY smooth form (step, min(1,C/W), min(1,sqrt(C/W))) fit below the second boundary under-predicts the far tail by the height of that second step (~1.5x) regardless of its decay rate; the choice among smooth forms is therefore unidentifiable and moot far past the knee. A two-boundary model (graded working-set knee times an output-tensor step past Y==cache…; validation: pytest -q — 526 passed (514 -> 526, +12); python -m experiments.resolve_transition_form — second knee reproducibly at N 504->512, Y/L3 0.984->1.000, jump ~1.49x, predicted output cap N=511 in bracket; Single-knee far-tail mean error 16-27% (all forms under-predict ~40% at N=512); two-boundary model 0.8% mean / 2.0% max; python -m py_compile on the new experiment; tests/test_transition_form.py pins the finding to the committed JSON; commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; PR https://github.com/mrcha033/multi-lora-fusion/pull/1 +
mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
mlir-fft-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S physical GPU 3에서 complex128 dense contraction을 SM 포화 grid로 검증했다. 네 lowering 모두 max abs error 4.89e-15 이하로 통과했다. K=J=32는 real_fold 6.919 ns/problem, complex_spec 5.352 ns/problem으로 Gauss가 22.65% 빨라 예측 -55.6%의 부호를 반박했다. K=J=128은 117.700 대 143.690 ns/problem으로 Gauss가 22.08% 느려 예측 +24.9%를 반박했다. N=32에서는 register 164/252, occupancy 19.87/14.34%이나 spill이 없고 instruction 감소가 우세했다. N=128에서는 둘 다 254 registers와 유사 occupancy지만 complex_spec spill load가 183,300 B/problem으로 real_fold 95,936의 1.91배, DRAM은 3.10배여서 누락된 spill-traffic 항이 패배 원인으로 확인됐다.; validation: Both lowerings produce numerically correct results at both shapes (max-abs error vs W @ x within fp64 tolerance) — no timing is reported for a kernel that does not compute the contraction; Measured registers/thread is reported alongside the model's prediction (baseline 8 + 2*MAXLIVE: ~140 vs ~204 at n=32, capped at 255 for both at n=128), so the register model is checked independently of the timing result; The sign of the measured time advantage at K = J = 32 is reported: negative confirms the…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler +
mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
mlir-fft-compiler outcome inconclusive: expected rectangular/tiled artifact was not produced; exploratory occupancy artifact only.
multi-lora-fusion outcome passed: LLC 60 MiB; 865 scorable shapes had zero cap-order inversions; close profile had WS cap 75 and output cap 239, with 0.261x graded WS rise and 0.791x output step. Far-tail transition showed N=384 resident to N=448 spilled, output/LLC 0.400 to 0.467, 1.638x jump. Single-knee max relative error 45.0–55.6%; two-boundary mean/max relative error 38.1%/48.4% on the far tail. +