1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
# 027 — 작성 정의만큼만 예약하는 네이티브 실행물
2026-09-24. Linux AArch64, GCC 14.2, Zig 0.15.2. 첫 공개 체크포인트의 중간 결과다.
**기본 실행 코어의 범위를 늘리지 않고, 선택한 앱 인스턴스의 반복 비용을 줄였다.**
이 문서는 당시의 고정 용량 빌드 결과다. 이후 정의와 상태를 분리한
[028 불변 프로그램 공유](028-shared-fixed-program.md)가 현재 CLI·피어 구조와 측정값이다.
## 제거한 비용
기존 native scalar 모듈은 작은 작성물에도 상태 32개, 입력 8개, 명령 512개, 반응 64개,
포인터 대상 24개의 최대 배열을 **실행 정의와 교체 준비 공간 각각에** 예약했다. 실행 전용 CLI와
피어는 빌드된 정의를 실시간 교체하지 않지만 인스턴스마다 20,064 B를 차지했다. 이 비용은
동일한 작성물을 여러 독립 인스턴스로 운영할수록 반복된다.
`prepare.mjs`가 이미 검증한 `.pure` 정의의 상태·입력·명령·반응·대상 개수를 Zig 빌드 프로필에
함께 기록하도록 했다. `native-fixed.zig`는 기존 `engine.zig`를 해당 용량으로 빌드한다.
배열이 비어 있을 때 Zig가 인덱스 연산을 컴파일할 수 있도록 0개 항목에는 1칸만 예약한다.
언어의 상한 32/8/512/64/24는 그대로 검사한다.
```text
.pure → 기존 컴파일러의 검증된 정의 → application.c + fixed-profile.zig
↓
같은 scalar VM의 정확한 배열 용량
```
고정 정의를 쓰는 `manage.py native` CLI와 `--peer`만 이 프로필을 선택한다. 작성 중에 새
정의를 적용하는 `--desktop`과 브라우저 Wasm은 여전히 전체 용량을 가진다. 고정 실행물에서
다른 정의로 바꾸려면 다시 빌드한다. 입력 하나의 실행 중에 크기 검사나 동적 배열 할당을
추가하지 않았고, 새 파서나 별도 인터프리터도 만들지 않았다. 앱 계산은 여전히 기존 scalar
VM이며 AOT로 모든 연산을 기계어로 펼친 결과는 아니다.
## 동작·한도 검증
[전체 용량 결과](../../prototypes/workbench/results/2026-09-24-fixed-capacity/general-parity-final.json)와
[고정 용량 결과](../../prototypes/workbench/results/2026-09-24-fixed-capacity/fixed-parity-final.json)는
동일한 기존 작성물 11개, 입력 170단계에 대해 네이티브 상태·출력을 Wasm 결과와 대조한다.
명령 319개인 `layout.pure`, 공통 규칙·대상별 배치를 포함한다. 두 C 호스트는 ASan/UBSan으로
실행했고 Zig 모듈은 ReleaseSafe였다. 고정 `routed-layout.pure`에서는 용량보다 큰 상태·입력·
명령 정의가 거절되고 기존 활성 상태·버전이 남는 것도 확인했다. 브라우저/CLI 회귀 87개,
Zig 코어 37개, TLS 피어의 [인증·저장·오류 시나리오](../../prototypes/workbench/results/2026-09-24-fixed-capacity/peer-check.json)도 통과했다.
| 작성물 | 명령 수 | 전체 용량 인스턴스 | 고정 용량 인스턴스 |
|---|---:|---:|---:|
| 비어 있는 작성물 | 0 | 20,064 B | 1,320 B |
| 카운터 | 17 | 20,064 B | 1,576 B |
| 직접 조작 | 82 | 20,064 B | 3,248 B |
| 대상별 공유 규칙 배치 | 117 | 20,064 B | 5,712 B |
| 피어와 CLI의 묶음 배치 | 117 | 20,064 B | 5,456 B |
| 명시적 세 도형 배치 | 319 | 20,064 B | 11,792 B |
이는 `pure_scalar_bytes()`가 요구하는 인스턴스 저장 공간이다. 앱 컨트롤러, TLS·GTK,
스택·저장소·힙 관리 비용을 포함한 값이 아니다.
반복 비용의 실제 효과를 별도로 확인했다. 같은 묶음 배치 정의로 독립 scalar 인스턴스
1,000개를 초기화한 Linux 프로세스에서, 초기화 전후 RSS 차이의 3회 중앙값은 전체 용량
**19,808 KiB**, 고정 용량 **5,536 KiB**였다. 둘 다 같은 실제 준비 정의를 적재했고
각 인스턴스의 버전을 읽어 유효한 초기화를 확인했다. [원자료](../../prototypes/workbench/results/2026-09-24-fixed-capacity/instance-memory.json)와
[재현 하네스](../../prototypes/workbench/native/instance-memory.c)를 보관했다. 이 수치는
**scalar 인스턴스 1,000개의 메모리 확대 비용**만 비교한다. 1,000명 서비스의 전체 메모리나
처리량·지연 개선이라는 뜻은 아니다.
## 실행물 전체 비용
동일한 `routed-layout.pure`와 `-O2 -g` C 빌드의 [ELF 섹션 원자료](../../prototypes/workbench/results/2026-09-24-fixed-capacity/size.txt),
[stripped 파일 크기](../../prototypes/workbench/results/2026-09-24-fixed-capacity/stripped.txt),
[CLI 빌드 식별](../../prototypes/workbench/results/2026-09-24-fixed-capacity/fixed-cli-build.json),
[피어 빌드 식별](../../prototypes/workbench/results/2026-09-24-fixed-capacity/fixed-peer-build.json).
| 선택한 범위 | 전체 용량 | 고정 용량 |
|---|---:|---:|
| scalar 오브젝트 `text` | 33,020 B | 18,252 B |
| CLI 실행물 `text` | 62,827 B | 48,059 B |
| CLI stripped ELF | 68,000 B | 68,000 B |
| TLS 피어 실행물 `text` | [026의 기준](026-secure-peer-link.md) 75,969 B | 61,201 B |
| TLS 피어 stripped ELF | [026의 기준](026-secure-peer-link.md) 133,936 B | 68,400 B |
CLI의 `text`가 줄어도 stripped 파일은 이 호스트의 ELF 배치·정렬 때문에 같은 68,000 B였다.
따라서 파일 크기 개선이라고 보고하지 않는다. 반면 피어는 세그먼트 경계를 넘어 실제
stripped 파일도 작아졌다. 동적 OpenSSL의 파일·메모리 비용은 여전히 별도이며, 이번 피어 서버
유휴 RSS 한 번의 관찰은 7,888 KiB였다. 공통 실행 코어 아카이브의 5,932 B 예산 및 CLI가
libc만 직접 요구하는 성질은 그대로다.
## 다음에 제거할 중복
고정 용량 안에서도 각 인스턴스가 동일한 실행 정의를 **두 벌의 배열 공간에** 보관한다.
이번 변경은 최대 크기 예약을 줄였지만 준비된 명령을 인스턴스 간 공유하지는 않는다.
따라서 많은 독립 앱을 운영하는 다음 검증에서는 불변 프로그램을 공유하고 변경 가능한 상태·
입력 소유권·평가 기록만 인스턴스에 둘 수 있는지 확인해야 한다. 정의 교체의 원자성,
동시 실행의 수명, 스냅샷 호환성을 유지하면서 실제 반복 메모리를 더 줄일 수 있을 때
구조를 채택한다. 큰 서비스 성능이나 컴파일 시간 우위는 아직 입증하지 않았다.
|
