From 91ab9a09db49be3c6f1259d3ef453c893b7ba0bd Mon Sep 17 00:00:00 2001 From: eunhhu Date: Mon, 19 Oct 2026 14:50:05 +0100 Subject: 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 go --- docs/design/030-one-path.md | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) (limited to 'docs') 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% 움직인다. + ## 정할 것(사용자의 결정) 내보낸 처리기를 제품에서 무엇이 기계어로 바꾸는가. -- cgit v1.2.3