CrownyVM v11 업그레이드 — 네이티브 대용량 사전 (2026-07-02)
배경
- 한선씨 전환 착수→VM 한계 실증: 맵(729슬롯 체인, 큐브힙) 6만 어휘 = 84s+셀힙48M OOM.
- 감사: 캡(맵729·셀힙48M·STR65536·배열4095)=전부 C #define=2진 에뮬레이터 임의상한, 3진본질 아님.
- 인터프리터는 빠름(순수100만루프 0.24s=0.24µs/op). 병목=맵 체인스캔+큐브힙 저장.
- 사장님 지시: VM을 에뮬레이터 수준에서 고성능/고효율 도구로 업그레이드.
구현 (crownyc.c + hanseonc_high.c)
네이티브 사전 NDict: 큐브힙 밖 malloc, FNV-1a 64 해시, 오픈어드레싱, load 0.7 자동리사이즈.
신규 opcode/빌트인:
사전생성()=875 → 핸들
사전넣어(사전,키,값)=876
사전꺼내(사전,키)=877 → 값(없으면 -1)
사전있나(사전,키)=878 → 참/거짓
사전크기(사전)=879
★사전파일적재(경로,키칸,값칸)=880 → C에서 PSV 통째파싱, 값 문자열 인터닝(중복카테고리 1핸들)
삽입지점: str_len 뒤(C헬퍼), case 874 뒤(exec), 이름표 2곳, hanseonc_high 빌트인표.실측 (before → after)
| 항목 | 맵(기존) | 네이티브 사전(v11) | 개선 |
|---|
| 6만 삽입+조회 | 41s | 0.48s | 85배 |
| 실제 psv 6만 적재 | 84s+OOM | 0.37s | 227배+ (OOM 해소) |
| 정확도 | 100%(정수)/OOM(문자열) | 100% | — |
| 저장 | 큐브힙(48M 한계) | C malloc(무제한) | 스케일 |
- word→카테고리 O(1) 직접접근 = 셀코어 로직DB 달성. 6만~수백만 확장 가능.
회귀
- 최종회귀.sh 19/19 PASS (컴파일·실행), 방사형셀DB 9/9·대화상태 30/30 등. 기존기능 무손상.
- 백업: crownyc.c.bak-20260702-002649
잔여 (진행)
- 방사형셀코어·뫼비우스·오라클대응·에너지변화 클러스터링/세그멘테이션: openclaw 아카이브 발굴중(background).
- VM 비교: 과거VM vs 현재 + 상용VM 정량비교 예정.
VM 비교 (과거 vs 현재 vs 상용)
과거 v10 → 현재 v11
- 6만적재 84s+OOM → 0.37s(227배). 6만삽입조회 41s→0.48s. 큐브힙48M한계→C무제한. 순수루프/함수콜 동일. 회귀 19/19.
vs 상용 (100만 함수콜 실측/참고)
| VM | 유형 | 100만콜 |
|---|
| LuaJIT | JIT | ~0.005s |
| Node V8 | JIT | 0.011s(실측) |
| JVM | JIT | ~0.01s |
| WASM | AOT | ~0.02s |
| CPython | 인터프리터 | 0.073s(실측) |
| CrownyVM v11 | 인터프리터+3진에뮬 | 0.57s(실측) |
- 포지셔닝: 2진상용 대비 CPython~8배·V8~52배 느림. 단 유일 균형3진 시맨틱+v11 데이터층 C속도+채팅 ms 충분.
- 속도 다음레버: computed-goto→Cube 27B 복사제거→트릿 int64패킹(3^27<2^43)→JIT.
openclaw 아카이브 발굴 (설계자료 위치 확정)
/Users/ef/openclaw-archive-2026-06-28/.openclaw-gemini/workspace/CrownyOS-v0.3-macOS/CrownyOS.app/Contents/Resources/engine
cube/cogcube.py = ★셀코어(CogCube: energy_map()+cells) = 방사형셀코어
mobius/chain.py = 뫼비우스 로직(MobiusChain: learn/query/tick, anchor_tags)
MGR.clusters = 에너지 기반 클러스터링, cube.energy_map()=에너지맵
knowledge/(트리), trident/(삼지창), rns/, db/crownydb.py
background Explore 에이전트가 알고리즘 상세 추출중.【방사형셀코어 구현개선】(07-02) — openclaw 설계 복원
발굴 에이전트가 openclaw 아카이브 CrownyOS-v0.3 engine 설계 완전복원:
cogcube.py: 27셀 큐브 idx=(x+1)9+(y+1)3+(z+1), 중심13=핵, absorb() 극성보존 빈셀탐색, 음(-0)=pointer/recursion 자유
trident/propagation.py: ★에너지 클러스터/세그 — E≥0.7→Ti(클러스터승격)/E≤0.3→Ta(세그먼트분해)/else Om. activate(+0.05)/decay/contradict(-0.2), 729리뷰 정규화, contradiction_threshold=3
mobius/chain.py: MobiusEdge{from,to,twist축,반전규칙}, 의미적 반전연결(문제↔기회), visited 루프방지, 학습=추론 미분리
오라클대응: 벡터 균형3진+뫼비우스DB, property graph(RDF/OWL), trit해시 O(1)인덱스+WAL, 8B 벡터시그니처
4세대로직/온톨로직(RTF): 티옴타음 4상, 온톨로지=DB코어(온톨로지→크라우니DB→언어/런타임→앱)
★구현: libs/방사형셀코어.한선 (에너지=0~1000 정수, VM float회피). 13/13 PASS.
큐브생성/셀인덱스/활성화/감쇠/모순/방향/흡수(4단계)/리뷰/뫼비우스연결/뫼비우스순회.
잔여: 오라클대응(벡터시그니처·property graph)·음(-0) pointer/recursion·CrownyDB CQL은 차기. 라이브 통합처 미정(대기).【3진 셀코어 vs C해시 효율 + LuaJIT 4상 분석】(07-02)
Q1: C사전 vs 삼지창 셀코어 (실측, 6만 셀주소 radix-3)
- 해시(2진): 조회 0.03µs/회. radix-3 트라이(3진): 0.13µs/회(11강하). 트라이 노드 149008.
- C무제한=용량한계 제거일뿐 효율우위 아님. 평면조회=해시 빠름.
- 삼지창 셀코어 우위: 경우의수 3^11→3^(11k) 지수, 충돌0, 이웃/순서접근, 에너지클러스터/세그/뫼비우스 네이티브(해시 불가), 진짜3진HW 최고효율.
- 결론: 하이브리드(멤버십=사전, 추론=삼지창셀코어). 3진이 속도까지=트릿패킹+JIT=LuaJIT원리.
Q2: LuaJIT 원리→CrownyVM (4상 울트라씽킹)
- LuaJIT: ①TraceJIT ②NaN박싱(64b태그) ③asm인터프리터+레지스터바이트코드 ④인라인캐싱.
- CrownyVM 병목: Cube 27B by-value(push/pop/인자 27B memcpy, NaN박싱 8B의 3.4배), 스택switch, JIT無.
- ★핵심레버=트릿박싱: 3^27=7.6조<2^43 → 큐브값 43b팩, int64여유, 상위비트 4상태그. NaN박싱 3진판. 27B→8B 복사3.4배↓.
- 로드맵: 1.트릿박싱 2.computed-goto 3.레지스터바이트코드 4.삼지창 trace-JIT. 목표 CPython추월·V8근접. 데이터층 이미 C속도(v11).
【지식증강 로직 v1】(07-02) — 삼지창 에너지 셀코어 엔진
- libs/지식증강.한선 7/7 PASS. 내용깊이 핵심레버 첫 버전.
- 학습→에너지 활성화(재확신→티 신뢰지식), 모순→강등(타 세그먼트분리), 삼지창 신뢰방향.
- 질의→관련지식 수집: ①직접사실 ②같은클러스터 승격(티)지식 ③뫼비우스 반전연결(문제↔기회) = 내용깊이.
- 미지개념→옴(빈결과, 환각없이 정직). LLM위임 대체 방향.
- 다음: ①저장을 병렬배열→v11 네이티브사전(무제한 O(1)) 교체 ②ai.crowny.org 파이프라인 통합(matched의미어→지식증강 질의로 응답 enrich) ③오라클대응(8B벡터시그니처·property graph·CQL)·음(-0)pointer/recursion.
대기 작업 큐 (사장님 지시)
【VM 정량목표 + 트릿박싱 측정 + 병렬 3작업】(07-02)
트릿박싱 측정(결정적): 구조체 크기 지배
- 캐시로 Cube 27→40B(+48%) → 순수100만루프 0.25s→1.07s(4배 느림), 함수콜 0.56s→0.43s(캐시효과 23%↑).
- ★결론: 정답=캐시 아니라 축소. 27B→8B(int64 값팩, 3^24=2.8e11<2^38). 산술 O(24)→O(1).
- 리팩터 범위: .t[ 450 = 태그235(t24/25/26→별도필드) + 값트릿206(TGET/TSET 또는 op 전면교체).
VM 정량목표 (사장님 3대 목표)
- ①극한속도: Cube 27B→8B, 순수루프 0.25→≤0.08s(3배), 함수콜 0.56→≤0.18s, 산술 O(24)→O(1).
- ②극한병렬사고: SWAR 트릿병렬(24iter→1~3 word op), 삼지창 3분기 동시평가.
- ③극한 4상 최소의사결정수렴: N지분류 log3N(=log2N/1.58, 6561→8결정), 티옴타음 옴/음으로 강제이분 회피.
병렬 3작업 완료
- #2 지식증강.한선 11/11 + 지식증강.js + 크라우니AI.js 통합(씨앗33, 회귀정상)
- #3 오라클대응.한선 16/16 (8트릿벡터시그·property graph·CQL)
- #4 음자유도.한선 18/18 (음=포인터/재귀·4상통합)
다음: 트릿박싱 int64 값팩 리팩터(태그 별도필드+값 packed, cube_add/to_int/divmod O(1), 19/19 게이트). 백업 crownyc.c.bak-20260702-002649.
【삼지창 JIT 영향분석 + 순서결정】(07-02)
- 원리=암달의 법칙: JIT은 VM 인터프리터 핫루프만 가속.
- 크게영향(5~15배): compute-bound 한선씨 핫루프 — 시뮬/CAE/모터동역학/삼진신경망커널/대규모 에너지클러스터/대량변환. VM계산 80~95%→전체 5~8배.
- 무영향: 웹/프록시(I/O바운드, VM계산 5~15%뿐)·C네이티브빌트인(v11사전·SHA256·TLS·수학, 이미 C)·JS서비스(ai.crowny.org, VM밖)·짧은요청(핫루프아님)·콜드/1회성.
- ★결론: 트릿박싱 먼저가 맞음. 트릿박싱=넓은이득(모든 한선씨 실행 1.5~3배, 짧은경로·콜드포함), JIT=깊은이득(compute 핫루프만). 라이브 대부분(웹·규칙·채팅)은 트릿박싱으로 이득·JIT 거의무이득. JIT은 compute 워크로드 커질때 상위레버.
- → 트릿박싱 int64 값팩 리팩터 착수(백업 crownyc.c.bak-20260702-002649, COPY작업, 회귀19/19 게이트).
【트릿박싱 ROI 검증 → 비추천 결론】(07-02)
- 합성벤치(크기효과 격리, 2억회 push/pop/copy): 27B 0.378s vs 7B 0.267s = 1.42x (3배 아님).
- 지난 "27→40B 4배느림"=캐시 ivok분기 아티팩트, 크기효과 아님. 순수 크기효과 1.4배뿐.
- 패킹 시 TGET/TSET 비트연산이 24트릿 산술루프에 추가→compute 오히려 느려질 수 있음. net marginal.
- 리팩터 규모: 값트릿접근 546곳 sed + .t통짜전달 13곳(float 서브시스템 shim) + {0}보존 패킹. 위험 높음.
- ★결론: 트릿박싱 ROI 나쁨(546곳 위험 대비 ~1.4x copy만) → 비추천.
- 재권고 순서: ①computed-goto 디스패치(~1.2~1.3x 전opcode, ~30줄 저위험) ②삼지창 JIT(compute 5~8x). 데이터층 최대이득(227배)은 v11로 이미 확보.
- JIT은 트릿박싱과 완전 별개(핫루프 네이티브 컴파일). 순서: computed-goto → JIT.
【computed-goto 효율확인 → 저ROI, VM정리 완결】(07-02)
- computed-goto 효율확인: 함수호출 2.43ns vs CMD op당 ~83ns = 제거이득 ~3%. switch 1184case=이미 점프테이블, DATA opcode 인라인+상수 ival캐시됨. → 비추천.
- op당 83ns 대부분=본질적 3진산술(cube_to_int/cube_add 24트릿루프). 마이크로최적화 한계.
- ★VM정리 완결: 인터프리터 최적화=v11 네이티브사전 227배가 핵심이득. 트릿박싱(1.4x·비추천)·computed-goto(3%·비추천) 검증후 스킵.
- JIT 기획: 핫 T/O/A 트레이스→네이티브(디스패치+3진산술 핫패스 제거). compute-hot 5~8배, 웹/채팅/규칙엔 무효. 대형. → compute워크로드 성장시 착수, 지금은 기획보관.
- 사장님 지침 "VM 정리되면 LLM 계속" → LLM(크라우니AI/지식증강) 복귀.