요청: crownyvm-jit-학습-재진행
- 날짜: 2026-07-10 10:44:20
- 작업 경로: /Users/ef/crowny-hub
요청 본문
크라우니VM을 JIT 최적화해서 성능 향상시킨 기록 찾아서 학습. xhigh 울트라씽킹으로 신중하게 한 번 더 진행.
관련 산출
(클로드가 작업 결과를 이어 기록)
산출: JIT 기록 학습 + 결정적 실측 (2026-07-10, xhigh)
학습한 JIT 실체 (3병렬조사 + 직접실측)
- crownyc JIT = 진짜 copy-and-patch(arm64), 3티어: asm스니펫(CROWNY_JIT_ASM)·스텐실(CROWNY_JIT_STENCIL)·cc폴백. "자족JIT"=배포처 cc부재 대응(빌드타임 aarch64 스니펫 W^X memcpy+패치).
- 정본 crownyc는 JIT 비활성(v0 스텁 항상 BAIL) — 실제 JIT는 별도 crownyc_jitmain.c→
crownyc-jit바이너리(opt-in CROWNY_JIT=1). 부팅 self-test + 런타임 bit-identical 차등게이트(불일치=영구BAIL). - 커버: 정수 스칼라산술·비교·LOAD/STORE·배열INDEX/SET·루프백엣지·순수 잎함수인라인. 문자열·맵·소켓·버퍼=전량 BAIL.
실측 성능 (직접 벤치, 메모리의 30~680배 로그는 커널 마이크로벤치 한정)
- 순수 스칼라(30M 합산): 인터프리터 7.30s → JIT 0.55s = 13x (Agent C).
- 순수 배열산술(3.2M): 1.98s → 0.64s = 3.1x (배열INDEX 오버헤드로 스칼라보다 낮음).
- 일반 상한 10~17x. 문서 로그의 44~70x·680x는 특정 canon 셰이프 한정.
★결정적 발견: 숫자변환(문자열변환(x)) 관용구 = 진짜 병목
- 동일 계산(배열 분산형)에서 관용구 有 인터프리터 30.3s vs 관용구 無 1.98s = 관용구가 15배 인터프리터 세금.
- 관용구 有 JIT = 30.27s (물림 0, 완전 BAIL — 문자열 opcode 미지원).
- 이 관용구가 통계분석(왜도·첨도·공분산·카이제곱·사분위수)·유체시뮬·ARIMA에 만연 → 과학 라이브러리 전체가 JIT 밖 + 15x 느림.
- 부작용 버그: 관용구가 누산기
합을 문자열연결로 오염(65KB 출력)시키는 별도 정합성 문제도 관찰.
두 갈래 향상 경로 (측정 근거)
- 경로A (JIT 10차): crownyc_jit_hot.c에 숫자변환∘문자열변환을 "숫자 항등"으로 처리(차등게이트가 비숫자 문자열은 자동 BAIL로 안전). 과학 워크로드를 JIT 물림으로. 단 opt-in·arm64·crownyc-jit 한정 = 도달범위 제한.
- 경로B (인터프리터 팹패스, 더 큰 레버): 기본 crownyc에서 관용구를 저비용화(런타임 숫자변환 fast-path: 숫자큐브 입력시 문자열왕복 생략, 또는 컴파일러 피홀). 모든 서비스·전 플랫폼의 기본 인터프리터가 즉시 ~15x — JIT opt-in보다 도달범위 압도. 단 정본 crownyc 변경(신중: 백업→차등검증→스모크).
판정
haiku 후보 추정(30~60배)은 오측. 실측 JIT는 3~13x이고 과학 라이브러리는 관용구로 BAIL. 최우선 레버는 JIT 확대가 아니라 관용구 제거/팹패스(경로B, 15x·전역). 경로A는 그 다음. 둘 다 착수 전 판단 필요(정본/실험바이너리 변경).★교정 (2026-07-10 후속, 신중 재측정)
앞서 기록한 "관용구 15x 인터프리터 세금"은 측정 오류였다. 합=합+d*d 테스트의 누산기가 오버플로로 문자열화되어 O(n²) 문자열연결된 아티팩트(30s·65KB출력)였고, 관용구 자체 비용이 아니었다.
깨끗한 재측정(합=합+d, 3.2M iters, 정본 crownyc): PURE 1.105s vs IDIOM 1.644s = 관용구 실제 세금 1.49x(15x 아님).
팹패스 검증 결과(경로B, shadow /tmp/crownyc-idiom):
- 정확성: 엣지케이스(음수·0·큰수·float관용구·문자열관용구·단독변환)+회귀 tests/ 86/86 정본과 bit-identical. float는 %g 손실 보존 위해 팹패스 미발동, 문자열도 미발동 → 완전 보존 확인.
- 속도: IDIOM 1.644s→1.203s(세금 제거, ~1.4x). 값 -1600000 정본과 동일.
- 판정: correct·safe하나 이득 ~1.5x로 소박. 게다가 정본 crownyc가 다른 3세션 동시경합(13:09 재빌드) → 소박한 1.5x 위해 공유소스에 미조율 변경 남기지 않음. crownyc.c 수정 되돌림, shadow 바이너리+검증지식만 보존.
★결정 실험: 실 워크로드(양자 스테빌라이저 시뮬)에서 JIT 물리나 — 답: 아니오
경로A의 진짜 선행조건("JIT 물릴 실 워크로드 존재?")을 순수 정수 양자 스테빌라이저 시뮬(양자스테빌라이저.한선 v1, 클리포드 게이트=한선씨 배열/정수 루프)로 실측:
- 6.4M 게이트루프반복(H·S·CX, 40큐비트, CROWNY_QSEED 고정): 인터프리터 33.63s vs JIT 34.08s = 물림 0(1.3% 느림, 실패 JIT 오버헤드), 체크섬 동일(BAIL로 정확성 보존).
- 원인: 게이트 핫루프가
엑소()(2탈출 잎함수) 호출 + QX/QZ/QR 3개 배열 접근 → JIT의 "단일배열 스칼라 정규루프" 패턴 밖. 대조: 앞선 단일배열 스칼라 루프는 3.1x 물림 → 병목=함수콜+다중배열 확정.
최종 결론 (JIT 조사 종결)
crownyc JIT는 진짜(마이크로벤치 13x)지만 현재 실 워크로드 적용범위=사실상 0:- 게이트웨이=I/O바운드(정수루프 0), 웹서버=정수루프 0, 통계/유체/ARIMA=숫자변환(문자열변환) 관용구 BAIL, 양자시뮬=함수콜+다중배열 BAIL.
- 실 코드는 수치연산조차 함수콜·다중배열·라이브러리관용구를 써서 JIT의 좁은 정규형(단일배열 스칼라산술) 밖.
- JIT 추가투자(10차 데몬모드 등)는 아무도 안 쓰는 걸 최적화하는 것. 실 가치 해제하려면 JIT를 다중배열+인라인가능 다탈출잎함수까지 확장해야 하나 ROI 불확실 — 특정 고가치 워크로드가 정당화하기 전엔 보류가 맞음.
- 정본 crownyc는 이미 견고(관용구조차 1.5x). crownyc 성능은 현 상태로 충분, 큰 레버 없음.