diff options
Diffstat (limited to 'docs/design/029-past-one-node.md')
| -rw-r--r-- | docs/design/029-past-one-node.md | 28 |
1 files changed, 27 insertions, 1 deletions
diff --git a/docs/design/029-past-one-node.md b/docs/design/029-past-one-node.md index 7d2f737..b3ff26d 100644 --- a/docs/design/029-past-one-node.md +++ b/docs/design/029-past-one-node.md @@ -71,7 +71,9 @@ C의 속도로 컴파일하기 쉬운 쪽**이어야 한다. 61–183배의 절� 증명을 받지 않았다. - 이 길은 위가 막혀 있다. 실행된 명령 하나의 기계 명령 74개 가운데 해석이 22개다. 이어 붙이기를 아무리 잘해도 1.42배다. 그래서 "새 뒤끝 없이 실행기의 몸을 이어 붙인다"는 이 원리의 길은 이 일에서 죽었다. - - 시험하지 않은 것: 증명을 받는 내보내기(칸을 레지스터에, 검사를 지움). 그것은 다른 주장이고, 008이 금한 일반 JIT다. + - 시험하지 않은 것: 증명을 받는 내보내기(칸을 레지스터에, 검사를 지움). 그것은 다른 주장이고 아직 시험하지 않았다. 008의 과제 A가 + 바로 그것을 묻는다(증명을 쥐고 왜 실행 중에 분배하는가, 모든 일에 실행의 원리 하나). 008이 금한 것은 실행기의 분열과 흔한 기법의 + 축소 복사이지, 증명에서의 컴파일이 아니다. 처음 이 자리에 "008이 금한 일반 JIT"라고 적은 것은 틀렸다. - **명령이 가는 곳.** 해석이 아니라 런타임의 기계다. - 앱을 줄인 변형(`events.c`, `variants`)의 코드 포인트당 기계 명령: 빈 처리기 1,583, 위치마다의 리스트를 지으면 22,651이 더, `Text` 레코드 2,951, `decide` 12,988. @@ -79,6 +81,30 @@ C의 속도로 컴파일하기 쉬운 쪽**이어야 한다. 61–183배의 절� 248(묶음 실행기는 35). - 마지막 수는 따로 적는다. 묶음 실행기가 이미 7배를 내는데, 블록 어디에든 fn이 있으면 블록 전체가 실행기로 가서 그것을 잃는다. 이 원리는 묶음 실행기를 지우자고 했다. 다음 가설은 이 7배를 다시 셈하거나 버린다고 말해야 한다. +- **메커니즘마다(`where.c`, `where.py`).** 사용자 모드의 기계 명령 100,003개마다 주소를 표본으로 받고(표본 246,581개, 답은 먼저 + 확인), 인라인된 함수의 사슬로 `step()`의 어느 명령 몸인지, 밖이면 어느 함수인지를 가렸다. 코드 포인트당 40,236개: + | 메커니즘 | 기계 명령 | 몫 | 실행된 명령 하나에 | + |---|---|---|---| + | 분배(switch, `run_calls`의 고리) | 12,298 | 30.6% | 22 | + | 리스트 짓기(append, 복사, 판, 지우기) | 6,953 | 17.3% | 13 | + | 수(산술, 비교, `//`의 `fmod`) | 5,416 | 13.5% | 10 | + | 리스트 읽기(트리 내려가기, 칸) | 5,238 | 13.0% | 10 | + | 옮김(지역, 상수, 스택) | 3,601 | 9.0% | 6.5 | + | 부름(들어가기, 나오기, 리스트 바꿔 끼우기) | 2,847 | 7.1% | 5 | + | malloc과 free | 1,609 | 4.0% | 3 | + | 사건, 고리, 가리지 못한 것 | 2,273 | 5.6% | 4 | + - **어느 계층도 절벽의 대부분을 들지 않는다.** 일반적인 계층 셋(해석, 리스트의 표현, 수의 표현)이 저마다 지워져도 1.4–1.5배다. + 절벽은 그 곱이다. + - range()의 이분 탐색 하나가 코드 포인트당 14,489개, 36%다(변형 v0r). 반복은 11.4번, 한 번에 약 1,270개다. 그 안에서 `//`가 + 186(`fmod`로 정확히 내린다), 저장 리스트의 읽기가 240이다. Vega의 C는 종류를 두 단계 표에서 한 번에 읽는다. 비교는 그대로 + 서지만, 저장 리스트 읽기의 몫은 앱이 고른 알고리즘 때문에 크다. +- **깨진 후보 하나(셈으로, 코드 전에).** "let 리스트는 프레임에서 나고 죽으며 별칭이 없는데, 런타임은 그것을 판이 있는 상태로 + 만들어 부를 때마다 바꿔 끼운다. 프레임이 이미 든 수명을 상태 계층이 다시 든다." 지울 수 있는 몫을 모두 더해도(리스트 짓기 6,953, + let 리스트의 읽기 약 2,500, 부름 약 2,500, 메모리 약 1,500) 약 13,000, 32%다. 값 없이 지워도 1.5배다. 절벽을 들지 못하니 깨졌다. +- **막대의 셈.** 실행된 명령은 549.9개, C는 기계 명령 220개다. 명령 하나가 기계 명령 하나여도 C의 2.5배다. (가)의 지움 뒤 251개를 + 하나에 3개쯤으로 내면 약 750, C의 3.4배다. 그래서 UAX #14에서 "C의 1–3배"는 실행만으로 닿지 않는다. 명령의 수도 줄어야 하고, + 550 가운데 269.5가 Vega의 C가 하지 않는 이분 탐색이다(변형 v0r에서 셈, `2026-10-19-ops-v0r.txt`). 이분 탐색의 명령 하나는 기계 + 명령 54개, 나머지 앱의 명령 하나는 92개다. ## 원리 2. 커밋이 곧 복제본이다 |