diff options
Diffstat (limited to 'docs/research/132-batch-executor-floor-and-the-way-past.md')
| -rw-r--r-- | docs/research/132-batch-executor-floor-and-the-way-past.md | 20 |
1 files changed, 12 insertions, 8 deletions
diff --git a/docs/research/132-batch-executor-floor-and-the-way-past.md b/docs/research/132-batch-executor-floor-and-the-way-past.md index dafb7d8..fb31176 100644 --- a/docs/research/132-batch-executor-floor-and-the-way-past.md +++ b/docs/research/132-batch-executor-floor-and-the-way-past.md @@ -9,7 +9,7 @@ - **문제는 "연산마다 레인을 한 번 훑는 꼴" 자체다.** 묶음 실행기는 명령 하나를 레인 1024개에 한 번에 하고, 그 결과를 메모리의 레인 배열에 쓴다. 다음 명령이 그것을 다시 읽는다. 기계어(JIT)는 같은 값을 레지스터에 두고 다음 연산으로 넘긴다. 요소당 명령이 묶음은 4–12개, 기계어는 1–2개다. 이것은 구현의 흠이 아니라 꼴의 값이고, 데이터베이스 쪽 문헌이 같은 수를 잰다(아래). -- **비용의 자리는 셋이다.** 요소마다(레인 훑기), 묶음마다(묶음을 열 때마다 블록을 다시 읽고 꼴을 정하는 값, 약 6,500 명령), +- **비용의 자리는 셋이다.** 요소마다(레인 훑기), 묶음마다(묶음을 열 때마다 블록을 다시 읽고 꼴을 정하는 값, 작은 블록에서 약 2,200 명령, 배낭의 블록에서 약 0.9 µs), 후보마다(걸러내기 뒤 차례대로 하는 꼬리, 약 250 명령). 셋 가운데 범용으로 거의 다 없앨 수 있는 것이 둘째다. 셋째는 리스트 쪽 C라 줄일 수 있다. 첫째가 바닥이다. - **근본적인 길은 "레지스터 타일"이다.** 레인 1024개를 명령마다 훑는 대신, 레인 4–16개를 레지스터에 올려 두고 몸체의 명령을 그 @@ -31,17 +31,21 @@ BFS 간선당 112개 가운데 약 45개가 레인 훑기다(`to` 모으기 12, ### 묶음마다 -같은 몸체를 레인 1024개와 256개로 돌려 명령의 차를 묶음 수의 차로 나눴다(`costs/sum0`, `ops0`: 회차 1,024,000, 묶음 1,000과 -4,000). +같은 몸체를 레인 1024개와 256개로 돌려 명령의 차를 묶음 수의 차로 나눴다(`costs/sum0`, `ops0`: 메시지 하나에 회차 1,024,000, +`icount`가 세 번 돌아 묶음 3,000과 12,000). | 모듈 | 1024 레인 | 256 레인 | 묶음마다 | |---|---:|---:|---:| -| `sum0` (회차를 세는 합) | 4,789만 명령 / 1,621만 사이클 | 6,886만 / 2,345만 | **6,990 명령 / 2,410 사이클** | -| `ops0` (`let` 하나와 `max`) | 6,641만 / 3,036만 | 8,534만 / 3,683만 | 6,310 / 2,160 | +| `sum0` (회차를 세는 합) | 4,789만 명령 / 1,621만 사이클 | 6,886만 / 2,345만 | **2,330 명령 / 805 사이클** | +| `ops0` (`let` 하나와 `max`) | 6,641만 / 3,036만 | 8,534만 / 3,683만 | 2,100 / 720 | -묶음 하나를 여는 데 약 6,500 명령, 약 1 µs다. 블록을 다시 읽어 지역 변수의 꼴을 정하고(`batch_run`의 앞머리, `recurrences`, +(2026-10-08 고침: 처음에는 `icount`의 세 번을 한 번의 묶음 수(1,000과 4,000)로 나눠 6,990 / 2,410과 6,310 / 2,160, "약 +6,500 명령, 약 1 µs"로 적었다. 세 배였다. 시간으로 따로 재도 `sum0`은 묶음마다 0.34 µs다([025](../design/025-batch-programs.md)).) + +작은 블록의 묶음 하나를 여는 데 약 2,200 명령, 약 0.3 µs다. 블록이 크면 더 든다(배낭은 약 0.9 µs, 025). 블록을 다시 읽어 지역 변수의 꼴을 정하고(`batch_run`의 앞머리, `recurrences`, `sums`), 명령마다 값의 꼴(균일·아핀·레인)을 물어 가르고(`pass`), 끝에서 검사하고 쓴다(`settle`). 024는 처음부터 "묶음 프로그램은 -루프마다 한 번 만든다"고 했는데, 그 단계를 만들지 않았다. 배낭에서는 이 값이 시간의 약 20%다(`batch_run` 10.7%, `pass` 8.5%). +루프마다 한 번 만든다"고 했는데, 그 단계를 만들지 않았다. 배낭에서는 이 값이 시간의 약 38%다(아래 표의 1024와 256의 차를 셋으로 나눈 4.4 ms; 처음에는 표본의 `batch_run` 10.7%와 `pass` +8.5%로 약 20%라 적었지만, 묶음마다의 값은 다른 함수에도 흩어져 있다). **레인을 줄이면 느려진다.** 024는 레인 자리를 L1(64 KB) 안에 두려고 256 레인을 적었고, 1단계에서 디스패치 값을 나누려고 1024로 늘렸다. 지금 디스패치는 명령당 약 20 ns라 다시 256으로 줄여 봤다(`b9`의 코드, `BATCH`만 바꿈, 5번의 중앙값). @@ -103,7 +107,7 @@ C 컴파일러가 가는 곳 어디서나 같고, 메모리를 적게 쓴다"([0 ### A. 묶음 프로그램을 로드 때 한 번 (024의 못 만든 단계) 루프마다 로드 때 한 번, 명령마다 피연산자의 꼴과 폭, 묶음마다 할 검사, 미룬 효과의 차례를 정해 둔다. 묶음을 열 때는 그 프로그램을 -돈다. 둘째 자리(묶음마다 약 6,500 명령)가 거의 사라지고 `pass`의 꼴 묻기도 사라진다. 범용이고, 아래 B의 전제이기도 하다 +돈다. 둘째 자리(묶음마다 약 2,200 명령에서 배낭의 0.9 µs)가 거의 사라지고 `pass`의 꼴 묻기도 사라진다. 범용이고, 아래 B의 전제이기도 하다 (B도 프로그램이 있어야 한다). 바닥(첫째 자리)은 건드리지 않는다. ### B. 레지스터 타일 해석 (근본적인 길) |