본문으로 이동

속성:Attempt

S3 연구 메모리

Text

직접 해본 방법이나 설정을 적습니다.

( | ) (20 | 50 | 100 | 250 | 500) 보기
이 속성을 사용하는 문서 20개를 보여줍니다.
p
The runner converted the absolute .venv/bin/python launcher through Path.resolve() before spawning the calibration CLI.  +
The runner assigned TMPDIR to a deeply nested per-model directory under the repository-private executable cache.  +
PMR proactively shrinks pages, decouples shrink from writeback, and batches unmapping/writeback in storage-friendly form.  +
POD-Attention co-schedules prefill and decode attention on each SM with adjustable resource allocation and integrates with Sarathi-Serve.  +
Polymorphic Error Correction reinterprets the same redundancy across fault models, combining an inline MAC with iterative correction.  +
간단한 측정 인프라로 application power의 통계 profile을 만들고, 평균 power budget과 threshold 이상 지속전류를 나타내는 sustained budget을 별도로 모델링해 consolidation 조합을 선택한다.  +
The work derives an empirical component-level fault model from public field-error logs and projects it to DDR5, HBM3, and LPDDR5 with on-die ECC and repair options.  +
읽기 지연·대역폭을 균형 배치하고 계층 간 병렬성과 crash consistency를 제공한다.  +
공식 출판 메타데이터와 공개 1차 출처를 탐색했지만, 방법·구현·평가를 확인할 수 있는 원문 또는 공식 초록을 확보하지 못했다. 제목에서 기술 내용을 추론하지 않았다.  +
PVM은 게스트 하이퍼바이저와 최소 공유 영역, 효율적 shadow paging을 사용한다.  +
r
WSBuffer buffers only small/unaligned write scraps, sends aligned large regions directly, and uses two-stage flushing plus concurrent page management.  +
Front-end에서 request arrival order를 ID로 포착해 back-end I/O까지 전달하고, 각 노드가 같은 global request order를 존중하도록 cooperative scheduler를 구현한다.  +
Application hint로 critical process를 지정하고 process dependency와 I/O dependency에 criticality를 상속해 request가 기다리는 writes만 NVWC에 admit한다.  +
동일한 L40S GPU에서 여섯 실험을 각각 실행했다: Triton rebase, FNO spectral convolution의 stacked 3M, fused multi-LoRA, RoPE training fusion, shape-adaptive attention proxy, CUDA BSR sparse-low-rank runtime. 각 실험은 전체 JSON 벤치마크 산출물로 수치 정확도와 성능을 함께 검증했다.  +
- 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; next: Port the R = t_complex/t_real probe to GPU (L40S) to test whether the FNO contraction's memory/launch-boundedness persists on hardware with cheaper launches and a different compute:bandwidth balance — if R crosses 3 at large channels, the 3M win reopens where CPU rules it out.; 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; next: Measure both capacity knees on GPU (L40S): the prior run measured only the output knee (Y≈0.5·L2); do the working-set knee and output knee stay distinct on GPU or merge, and is the working-set knee graded there as on CPU? Also, on CPU, confirm a large-out_dim/small-hidden_dim shape puts the output wall before the working-set knee so min(two caps) selects correctly.; 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…; next: GPU-adjudicate the two named regimes: compile both lowerings for a narrow (K = J = 32, policy predicts −55.6%, slot model predicts +24% — they disagree in sign) and a wide (K = J = 128, predicts +24.9%) dense complex contraction, and measure wall-clock, registers/thread, achieved occupancy, and spill load/store. If the modeled reversal at narrow shapes does not appear on hardware, the `occ_sat` knee or the no-spill-traffic assumption is the component to revise.; 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…; next: Separate the two candidate causes of sibling outcome clustering, now the sole load-bearing unknown. Sampler-side (low temperature / near-duplicate proposals) is directly addressable by config; objective-side (a parent's local basin admitting only one kind of edit) is not. The pilot checkpoints already store per-program code, so a code-similarity-versus-outcome-concordance analysis on existing trees can begin this split with no model server: if sibling pairs with near-identical code are the ones…; 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…; next: Combine the two independent levers measured this session and test whether they compose: a `mode_leading` SpectralConv1d that also caches the decayed weight (`weights * decay_mask`) at eval. The stage profile shows the weight recompute is f_wp = 0.31/0.49 at Cin=256/512 — exactly the shapes where the mode_leading end-to-end win is weakest (1.87x/1.71x) despite a 5.75-14.49x contraction win. Caching alone is independently measured at 1.93x/2.39x, bit-exactly. The falsifiable question is whether t…; 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…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; 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…; next: GPU-adjudicate held-out rectangular shapes to identify the reload law and test the tiling corollary: (K=128,J=32), (K=32,J=128), (K=256,J=40), plus a J-tiled K=J=128 contraction built from J=32 tiles. The rho*K and const reload models predict ~4x different spill traffic at (32,128), so one launch separates them. If the J-tiled variant recovers the amortization win at K=J=128, the wide-shape loss is a scheduling artifact fixable by tiling rather than grounds to decline to amortize.; 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…; next: Measure both capacity knees on GPU (L40S). The prior GPU run located only the output knee (Y ~ 0.5*L2); the working-set knee was never measured there. Two sharp questions: (a) does the boundary ordering survive a usable fraction of 0.5, which tightens the bound to knee/(0.5*L2) and inverts iff the working-set knee exceeds half the L2; (b) is the working-set knee graded on GPU as on CPU, or does the launch-bound regime flatten it? Secondary CPU follow-up: characterize what the working-set knee d…; 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…; next: Test whether the decayed weight can become a training win rather than an inference-only cache, by folding the decay into the parameter at initialization (store W' = W * decay and train that directly), removing the f_wp stage entirely instead of memoizing it. This is bit-exact in the forward but NOT gradient-equivalent: it rescales each mode's gradient by decay[k], changing the effective per-mode learning rate under any non-scale-invariant optimizer. Falsifiable question: is the training traject…; 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…; next: Test parent-selection directly, since A1g promoted it to the top lever and — unlike A1f's proposed diversity intervention — it is a scheduler change rather than a sampler change, so it can be projected offline first. On the existing committed trees, replay the pilot's actual parent-selection policy against a q-band-targeted alternative (bias selection toward A1f's productive band q in [0.4, 0.6)) and compare predicted conversion under each, using A1g's q-conditional outcome rates rather than th…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1  
- mlir-fft-compiler: safely inspected and stopped the legacy square-only compile; no new rectangular/tiled timing artifact. Exploratory artifact preserved. - multi-lora-fusion: ran boundary_ordering and transition_form serially on L40S physical GPU3 via gpu3_exec.py using an isolated commit snapshot.  +