030: the numbers from one build (the runtime 40,847 and the hand path 813, cycles 15,735 and 348, beside Vega's 251 and 93; other builds 1-2% apart) and 602 named as the substituted algorithm (373 cycles); 9.43x said to be the emitted chain's factor, the executor's share step 1's first measurement; 009's tension stated once (sparse updates in the log's delta, whole numbers zigzag there: a second shape, the cheaper one); the caveats of 047 together; model.py's import where imports goHEADmaster

1 files changed, 23 insertions, 5 deletions

diff --git a/docs/design/030-one-path.md b/docs/design/030-one-path.md
index a9856a3..9d9490a 100644
--- a/docs/design/030-one-path.md
+++ b/docs/design/030-one-path.md
@@ -5,9 +5,12 @@
 
 ## 쉬운 말로
 
-UAX #14의 메시지 하나는 오늘 코드 포인트당 기계 명령 40,365개가 든다. 같은 앱을 손으로 바꿔 써서 잰 경로는 813개다. 그 경로에서는
-트리 밖 복사도 역직렬화도 하지 않고, 앱은 aup가 오늘 받는 그대로(키 있는 리스트와 seek)다. 그래서 Vega의 C(같은 페이로드에
-251)의 3.2배이고, 사이클로는 3.7배다(348 대 93). 이 문서는 그 경로를 런타임의 단 하나의 실행 경로로 만드는 설계다.
+UAX #14의 메시지 하나는 오늘 런타임에서 코드 포인트당 기계 명령 40,847개(사이클 15,735)가 든다. 같은 앱을 손으로 바꿔 써서 잰 경로는
+813개(사이클 348)다. 둘 다 같은 빌드에서 쟀다. 리스트의 코드를 하네스 안에 함께 지은 빌드라, 다른 빌드의 40,365와 1–2% 다르다. 그 경로에서는
+트리 밖 복사도 역직렬화도 하지 않고, 앱은 aup가 오늘 받는 그대로(키 있는 리스트와 seek)다. 그래서 같은 빌드의 Vega의 C(같은 페이로드에
+251, 사이클 93)의 3.2배이고, 사이클로는 3.7배다. 앞서 보고한 602(사이클 373)는 앱이 쓰지 않은 알고리즘으로 바꾼 수였다. 키로 하는
+seek는 기계 명령이 더 많지만, 안쪽 노드의 키를 쓰고 자식 포인터를 따라가지 않아 사이클은 더 적다. 이 문서는 그 경로를 런타임의 단 하나의
+실행 경로로 만드는 설계다.
 
 ## 경로
 
@@ -16,7 +19,7 @@ UAX #14의 메시지 하나는 오늘 코드 포인트당 기계 명령 40,365�
 | 단계 | 하는 일 | 허락하는 것 | 잰 것 |
 |---|---|---|---|
 | 테두리 | 행을 페이로드가 둔 자리에서 읽는다. 검사만 한다(행이 온전한지, 수가 유한한지, 불이 0이나 1인지). 처리기가 바꾸는 상태 하나만 따로 쓰고, 오류 없이 끝나면 그것으로 바꾼다 | 언어의 뜻(입력은 바뀌지 않는다), N2 | 1,595 → 22/점(045). 여러 필드 행은 32행 열 덩어리로 오면 1,318 → 44/행(047) |
-| 처리기 | 지역과 스택은 레지스터에 둔다. 부름은 맨 부름이다. 사건의 리스트는 타입 있는 버퍼다. 레코드에 담은 리스트는 복사하지 않고 함께 쓴다. 정수는 정수로 다룬다 | 오늘의 증명(스택 모양, fn마다의 집합), N1, N4, 표현의 결정 | 38,623 → 564–788/점(045) |
+| 처리기 | 지역과 스택은 레지스터에 둔다. 부름은 맨 부름이다. 사건의 리스트는 타입 있는 버퍼다(내보낸 사슬에서 9.43배). 레코드에 담은 리스트는 복사하지 않고 함께 쓴다. 정수는 정수로 다룬다 | 오늘의 증명(스택 모양, fn마다의 집합), N1, N4, 표현의 결정 | 38,623 → 564–788/점(045) |
 | 저장 리스트 읽기 | 메모리의 리프(binary64 열)를 그 자리에서 읽는다. 키로 찾을 때는 안쪽 노드의 키로 내려가 리프의 키 열에서 찾는다. 사건 안에서는 리프를 쥐고 있는다 | N2(사건 안에서 바뀌지 않음), 키 있는 리스트의 선언 | keyed_shared 788, 끝에서 끝 813, 사이클 348(045) |
 | 커밋 | 덧붙이기는 마지막 리프의 빈칸에 셀만 그 자리에서 쓰고, 개수는 커밋 레코드에 둔다. 흩어진 갱신은 오늘의 로그 레코드로 쓴다 | 쥔 스냅숏은 제 개수 너머를 읽지 않는다 | 덧붙이기 리스트 바이트 25.9 / 10.9 / 10.0(오늘 65.5 / 15.7 / 12.4), 갱신은 로그 그대로(047) |
 | 복제 | 저장소가 제 sync에서 끊은 제 파일 연산을 pure link로 보낸다. 확인은 heard다 | 원리 2 | 바이트 같음, kill -9 90번, 접두 867곳(046) |
@@ -45,7 +48,8 @@ UAX #14의 메시지 하나는 오늘 코드 포인트당 기계 명령 40,365�
 ## 표현의 결정(증명이 필요 없는 것)
 
 - 사건의 리스트: 타입 있는 버퍼다(수는 binary64, 정수 열은 N1이면 i64, 불은 u8). 키 없고 인덱스 없는 리스트가 받는 연산을 모두 한다.
-  9.43배다.
+  9.43배는 내보낸 사슬 안의 인자다(분배와 메모리 칸이 지워진 뒤). 실행기 안에서는 몫이 훨씬 작을 것이다. 인자는 몫이 아니다. 차례 1에서
+  처음 잴 것이지 예측이 아니다.
 - 입력의 행: 페이로드 그 자리에서 읽는다. 필드가 하나인 레코드는 행이 곧 열이다. 필드가 여럿인 메시지는 32행의 열 덩어리(메모리 리프의
   열)로 바꾼다. 메시지 형식을 바꾸는 일이고, 1.0 전이라 깰 수 있다.
 - 통째로 바뀌는 bytes 상태: 버퍼 둘을 번갈아 쓴다.
@@ -54,6 +58,20 @@ UAX #14의 메시지 하나는 오늘 코드 포인트당 기계 명령 40,365�
   이미 가진 색인을 다시 짓는다. aup의 걸림이 하나 있다. fn 안의 접기가 fn의 매개변수를 읽지 못해서, seek를 처리기에 써야 했다.
   매개변수는 접기 동안 정해진 값이니 받아들이는 것이 맞다(aup의 일).
 
+## 009와의 긴장(한 번 적는다)
+
+항목의 셀은 덧붙이기에서 한 모양을 지킨다. 패킷, 리프, 리프의 꼬리, 복제 모두 binary64다. 흩어진 갱신에서는 델타라는 그릇이 어떤
+리프 모양보다 싸다(047: 3–5배 이상). 오늘의 로그는 거기에 더해 정수를 zigzag varint로 줄인다. 정수에 대해서는 둘째 바이트 모양이고,
+그것이 이기는 모양이다. 이 설계는 흩어진 갱신을 로그에 둔다. 그래서 정수의 델타에서는 009의 철칙을 지키지 않는다. 지키려면 델타의
+값을 binary64로 두면 된다(바뀜 하나에 약 7 B 더). 그 값을 치를지는 재고 나서 정한다.
+
+## 단서
+
+- 047은 바이트를 세는 모형이지 저장소가 아니다. 델타 방을 읽는 값은 세지 않았고, 리프는 가득 찼다고 보았으며, 커밋 레코드의 크기는 가정했다.
+- 기준선의 은행 실행에는 트리 커밋이 없다(리스트만 바뀐다). 기준선은 실행마다 메시지 2만 개라, 그 안에 이미지 체크포인트가 없다.
+- 패킷을 리프로 받는 것은 메시지 형식을 바꾸는 일이고, 텍스트 열을 설계하기 전까지는 수에만 해당한다.
+- 손으로 쓴 경로의 수는 하네스 빌드마다 1–2% 움직인다.
+
 ## 정할 것(사용자의 결정)
 
 내보낸 처리기를 제품에서 무엇이 기계어로 바꾸는가.