aboutsummaryrefslogtreecommitdiffstats
path: root/docs/design/027-computation-core.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/design/027-computation-core.md')
-rw-r--r--docs/design/027-computation-core.md14
1 files changed, 14 insertions, 0 deletions
diff --git a/docs/design/027-computation-core.md b/docs/design/027-computation-core.md
index 06bfe02..687a51f 100644
--- a/docs/design/027-computation-core.md
+++ b/docs/design/027-computation-core.md
@@ -479,6 +479,20 @@
- 명령 수(b41 대 b40): 묶음과 함께 BFS +0.12%, 실행기만 BFS −0.09%, 나머지 ±0.001% 안이다. 은행 질의(s40과 s41을 한 번에 번갈아
여섯 번)는 in_credit +0.09%, per_branch +0.05%, ranks +0.03%, 나머지 ±0.01% 안이다. 처음 세 번의 in_credit +1.16%는 그 질의의
흔들림이었다(같은 빌드의 여섯 번 사이 2.75%).
+ - **4f-4 만듦(2026-10-19).**
+ - Pure: 반복은 몇 겹이든 둔다(검증기의 8겹 거절이 없어졌다). 로드가 모듈의 가장 깊은 겹을 센다(`nesting`). 8겹까지는 전처럼 실행의
+ 스택에 겹 칸을 두고, 더 깊은 모듈은 부르는 실행기(runner 2)가 앱의 칸(`PureApp.deep`, 그 겹만큼 자람)으로 돈다. 그래서 `run()`의
+ 뜨거운 길은 그대로다. JIT은 8겹까지인 모듈만 컴파일한다. 함수의 겹(호출 프레임의 크기)도 막지 않고 센다(u32).
+ - aup: 소스의 32 KB가 없어졌다(파일과 표준 입력을 크기대로 읽는다). 컴파일러의 표는 고정 배열 그대로이되 Pure의 너비에 맞춰
+ 올렸다(상태 4,096, 입력 1,024, 보기 4,096, 핸들러 4,096, 레코드 1,024, 레코드 필드 16,384): 컴파일러는 15 MB를 calloc으로
+ 잡고, 쓰지 않는 칸은 메모리에 올라오지 않는다. 진단은 그 수를 말한다. 출력은 255까지(Pure의 저장 너비), 걷기와 집계가 도는
+ 리스트는 상태 번호 256 아래(그 인자의 바이트)라고 aup가 미리 말한다. 표를 정말 모듈에 맞춰 자라게 하는 것은 컴파일러의 표
+ 전체를 바꾸는 일이라 남겼다.
+ - 시험: 단위 시험이 40겹의 반복을 로드해 끝까지(2^20번) 돌리고, 2^40번은 일의 예산에서 멈추게 한다(8겹은 스택에서 돈다). aup의
+ 시험이 상태 301, 입력 40, 보기 70, 레코드 20인 48 KB 소스를 짓고 pure-run으로 마지막 것들까지 돌린다.
+ - 명령 수(b42 대 b41): 묶음과 함께 BFS −0.12%, 실행기만 BFS +0.09%, 나머지 ±0.001% 안이다. 은행 질의(s41과 s42를 한 번에 번갈아
+ 여섯 번)는 in_credit +1.04%, per_branch +0.60%, ranks +0.36%, 나머지 ±0.01% 안이다. 그 셋은 흔들림이다: 은행 앱에는 함수가 없어
+ 바뀐 길(부르는 실행기)을 지나지 않고, s42의 in_credit 여섯(3.51M–3.55M)은 같은 s41 빌드가 앞서 낸 여섯(3.49M–3.59M) 안에 있다.
- **차례의 까닭.**
- 4a는 작고, 3단계의 끝을 맺는다.
- 4b는 가장 많이 지운다. 키 있는 메시지와 기준 리비전이 사라지면 4d가 단순해진다.