한선씨 P5 — 성능 네이티브화 트랙 (bignum/ECC 병목 조사)
개요
P1~P4에서 순수 한선씨로 bignum·RSA·ECC/ECDSA를 정확하게 구현했으나
secp256k1 검증 8분·RSA-2048 비현실 = 순수 VM 성능 한계. "무엇을 하면
실용권에 드는가"를 정량 판단하는 조사(구현 아님, C 소스 무접촉).
무엇을 했는지
- 병목 프로파일:
큰수곱해(순수곱셈) vs 큰수나눔(모듈러축소, 자릿수당
이진탐색) 벤치 — 나눗셈이 곱셈보다
71배 느림(1.35ms vs 96.3ms/회,
256비트 규모).
--profile opcode 카운트로 교차검증(3,268,774 vs 46,039
opcode/회 = 71.0배, 벽시계와 일치). 상위 opcode는 ADD/LOAD_FP/LOAD/STORE
— 즉 인터프리터 디스패치 오버헤드가 지배적, 특수 중연산이 아님.
- 몽고메리 REDC 소규모 실증: bignum.한선 표현 위에서 표준 워드단위
REDC를 프로토타입 구현(스크래치패드, 라이브러리 미변경). Python
T·R⁻¹ mod n과 정확히 일치(diff=0). 성능 1.35ms/회 — 스쿨북 나눗셈
대비
71.6배 단축, 모듈러곱 전체론 약 36배.
- 레버리지 비교표: (a)알고리즘개선(순수한선씨, 위험낮음) vs
(b)핫opcode C네이티브(추정 20~80배, 이번 조사 범위 밖) vs (c)JIT(기존
3~13배 결론 재탕 금지) vs (d)외부위임(openssl, TLS stunnel 선례).
- secp256k1 실용화 필요조건 추정: 몽고메리 단독은 점당 모듈러역원이
새 병목이 되어 개선 제한적 → Jacobian 좌표(역원을 스칼라곱 전체 1회로
격리)와 결합 필수. 추정: 8분 → (몽고메리+Jacobian, 순수한선씨) 약 20초
→ (+핫opcode C화) 약 0.2~1초.
두 축(알고리즘+C화) 동시 투자 필요.
- 도메인별 투자권고: 암호 실키(RSA-2048/실서명검증) = 순수구현은
교육/감사용 유지, 실사용은 외부위임(openssl) 별도경로 권고. 수치
대용량(비암호) = 몽고메리 REDC를 bignum.한선에 정식 반영 1순위 권고
(순수성 유지+즉시 이득).
관련 파일
- 산출 문서:
/Users/ef/CrownyOS/crownyc/docs/한선씨-P5-20260710/성능네이티브화_조사.md
- 참조(P4):
/Users/ef/CrownyOS/crownyc/docs/한선씨-P4보완-20260710/ECC검증.md
- 라이브러리(무변경):
pkg/libs/bignum.한선, pkg/libs/타원곡선.한선, pkg/libs/RSA.한선
- 벤치 스크립트(스크래치패드, 비영속):
/private/tmp/claude-501/-Users-ef/75958a3d-340c-4503-b5cb-7ff1ab34a93b/scratchpad/perf/*.한선
발견한 함정(신규)
crownyc run <(hanseonc_high ...) 프로세스치환으로 .toau 전달 시
큰수곱해 등의 결과가 조용히 0이 됨(파일 리다이렉트는 정상) — 로더가
파이프(seek 불가) 입력 크기 조회에 실패하는 것으로 추정. 벤치/자동화
스크립트는 반드시 파일 기반 컴파일로 작성할 것.
잔여 이슈 (P6 제안)
bignum.한선에 큰수모듈러거듭제곱_몽고메리 정식 함수 추가(REDC
조건부 최종감산 보완 + 회귀 검증).
타원곡선.한선에 Jacobian 좌표 점연산 추가, affine과 교차대조.- 핫 opcode(
BIGNUM_MULACC) C화는 별도 승인 트랙(이번 조사는 C 무접촉).
- RSA/ECDSA "순수 vs 외부위임" 두 경로 문서화.