aboutsummaryrefslogtreecommitdiffstats
path: root/docs/research/009-bounded-display-integration.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/research/009-bounded-display-integration.md')
-rw-r--r--docs/research/009-bounded-display-integration.md141
1 files changed, 141 insertions, 0 deletions
diff --git a/docs/research/009-bounded-display-integration.md b/docs/research/009-bounded-display-integration.md
new file mode 100644
index 0000000..0269d34
--- /dev/null
+++ b/docs/research/009-bounded-display-integration.md
@@ -0,0 +1,141 @@
+# Pure: 기록을 버리는 실행 계약을 작성물에 연결
+
+2026-09-22. **구현·기능 검증 완료. 캐시는 선택 기능으로 유지한다.**
+
+2026-09-23 후속: **기록 공간을 코드 교체 준비 공간과 공유하도록 구현했다.**
+현재 코어는 19,128 B이며, 아래 첫 통합의 20,272 B에서 1,144 B 줄었다.
+현재 비용과 검증은 문서 끝의 ‘공유 작업 공간’에 구분해 기록한다.
+
+이제 기존 `.pure` 작성물의 표시 계산에서 결과를 보관하거나 기록을 지우고,
+한 번의 장면 계산에 쓸 작업량을 제한할 수 있다. 소수점 계산·입력 순서·실패 시
+상태 복구는 기존 의미를 보존한다. [앞선 C 코어](../../prototypes/forgetful-core/README.md)의
+정수 DAG를 교체 삽입하지 않고, 실행 계약을 기존 Zig/Wasm 코어에 이식했다.
+
+## 이번에 끝낸 범위
+
+- 전체 장면에 하나의 작업 한도. 부족하면 부분 장면 없이 명시적인 표시 오류.
+- 결과와 의존성 요약을 함께 버리는 고정 크기 캐시, 버릴 수 있는 변경 일지.
+- 증거가 부족하면 재계산. 입력 이벤트나 외부 효과는 재실행하지 않는다.
+- 이벤트 실패, 상태 재정렬, 프로그램 교체, 초기화, signed zero를 포함한 보존 검사.
+- 터미널의 `limits`·`forget`·`costs`와 브라우저/Node 공통 API.
+
+조건부 추적 기록을 다룬 첫 코어와 달리, 현재 작성물의 표시식에는 분기가 없다.
+논리 연산도 기존처럼 양쪽을 모두 계산한다. 실제 LOAD에서 상태 의존성을 모으며,
+호스트가 전달한 의존성 주석을 신뢰하지 않는다. 캐시는 입력이 없는 상수의 재사용에
+변경 일지를 요구하지 않는다. 코드 교체는 상수 캐시도 폐기한다.
+
+## 채택 확인: 기존 작성물 세 개
+
+같은 새 실행기에서 캐시 0개와 32개를 비교했다. 각 파일마다 관측 100회와
+600프레임, 주기적인 누름·놓음 20회를 재생했다. **총 2,160개 스냅샷이 일치**했다.
+이는 정해진 예제 입력 기록이며 사용자 제작 경험이나 대규모 앱 평가가 아니다.
+
+| 작성물 | 실행된 표시 명령: 캐시 끔 → 켬 | 전체 호출 시간 중앙값 ms: 끔 → 켬 |
+|---|---:|---:|
+| counter | 9,360 → 93 | 3.111 → 2.693 |
+| toggle | 10,080 → 54 | 3.066 → 2.663 |
+| charge | 11,520 → 566 | 4.587 → 4.100 |
+
+시간은 입력 처리와 snapshot 구성까지 포함한 720개 호출 묶음이다. 로딩·컴파일·DOM·
+통계 읽기·동등성 검사는 제외했다. 5회씩 순서를 번갈아 측정했으며 Linux AArch64
+한 기기에서 CPU 고정·전력 통제를 하지 않았다. P99 지연이나 macOS 성능이 아니다.
+표시 명령이 크게 줄어도 전체 호출 시간의 감소는 이번 측정에서 약 11~13%였다.
+
+charge의 계측 작업 단위는 오히려 21,600에서 26,909로 늘었다. 변경 기록 확인도
+작업이기 때문이다. 이 단위는 VM 명령 개수나 CPU 시간과 같지 않다.
+
+## 첫 통합의 비용과 결정 — 별도 기록 공간을 둔 빌드
+
+| 영역 | 이전 → 현재 |
+|---|---:|
+| 코어 고정 구조 | 19,072 → 20,272 B |
+| Wasm 파일 | 48,182 → 53,125 B |
+| Wasm 선형 메모리 용량 | 65,536 → 65,536 B |
+
+**1,200바이트의 추가 기록 공간을 소비한다. 메모리를 절감한 결과가 아니다.**
+캐시를 꺼도 이 고정 공간은 예약된다. 코드·상태·캐시를 모두 임의로 늘릴 수 있는
+범용 할당기, 기록 공간의 실제 반납, 큰 문서의 의존성 표현은 구현하지 않았다.
+
+따라서 작업량 제한은 기본 적용하되 캐시는 기본으로 켜지 않는다. 작은 예제의
+이득만으로 모든 작업의 기본 정책을 바꿀 근거는 부족하다. 사용자는 CLI나 임베딩
+API에서 선택할 수 있다. 현재 한도에서는 기본 작업량 2,048로 모든 정상 표시식을
+완료할 수 있다. 실제 응답 시간이나 앱 전체 작업량의 보장은 아니다.
+
+이 단계의 완료 기준은 **실제 작성물로 연결, 기존 의미 보존, 한도 초과·복구 검증,
+추가 비용 확인**이었다. 모두 확인했으므로 같은 예제의 측정 확장은 하지 않는다.
+학술적 신규성·대규모 서비스 우위·Pure 전체 완성은 이번 결과의 주장이 아니다.
+
+## 검증과 재실행
+
+Zig 네이티브 20개와 JavaScript/CLI/Wasm 45개 검사가 통과했다. 이 통합은 Zig의
+검사와 실제 Wasm 실행으로 검증했다. 앞선 C 코어의 ASan·UBSan 결과를 이번
+Zig 변경의 검사로 대신하지 않는다.
+
+실제 Chromium에서도 작성·수정·기록 삭제·한도 초과·복구의 11개 확인을 통과했다.
+UI의 한도 초과 검사는 테스트 세션의 모듈 응답에서 기본 작업량만 1로 바꿔
+진입했으며 제품 파일은 바꾸지 않았다. 검사 뒤 원래 설정과 빈 화면으로 복원했다.
+
+- [통합 소스](../../prototypes/workbench/evaluation.zig), [실행기](../../prototypes/workbench/web/runtime.mjs)
+- [사용 방법](../../prototypes/workbench/README.md), [정확한 계약](../../prototypes/workbench/CONTRACT.md)
+- [빌드·검사·소스 해시](../../prototypes/workbench/results/2026-09-22-evaluation/verification.json)
+- [비교 원자료](../../prototypes/workbench/results/2026-09-22-evaluation/comparison.json)
+- [첫 통합의 브라우저 확인 절차](../../prototypes/workbench/results/2026-09-22-evaluation/sources/qa-evaluation.js)
+- [브라우저 결과](../../prototypes/workbench/results/2026-09-22-evaluation/browser.json),
+ [한도 초과 화면](../../output/playwright/pure-evaluation-limit.png)
+
+```sh
+node prototypes/workbench/cli.mjs prototypes/workbench/examples/charge.pure
+node prototypes/workbench/evaluation.test.mjs
+node prototypes/workbench/evaluation-check.mjs --output /tmp/pure-evaluation-new.json
+```
+
+## 공유 작업 공간 — 2026-09-23
+
+평소의 계산 기록과 교체할 코드를 준비하는 공간이 동시에 필요하지 않다는
+점을 이용했다. 두 자료를 한 공간에 번갈아 담고, 현재 실행 중인 프로그램과
+상태는 별도로 유지한다. 교체 준비 중에는 기존 표시식을 재계산한다.
+교체를 시작한 뒤 발생한 입력·초기화도 새 프로그램에 상태를 보존할 때 반영한다.
+교체가 끝나거나 취소되면 같은 공간을 빈 계산 기록용으로 돌려준다.
+
+| 항목 | 별도 공간 → 공유 공간 |
+|---|---:|
+| 전체 코어 고정 구조 | 20,272 → **19,128 B** |
+| 기능 추가 전 19,072 B 대비 증가량 | 1,200 → **56 B** |
+| Wasm 파일 | 53,125 → 53,952 B |
+| Wasm 선형 메모리 | 65,536 → 65,536 B |
+
+56 B는 제어 정보 48 B와 Zig의 유니언 안전성 확인용 8 B다. 캐시·변경 기록
+1,152 B는 기존 9,392 B 준비 공간 안에 들어간다. 코어 자료구조에서 1,144 B를
+줄였지만 Wasm 파일은 827 B 늘었다. OS 페이지 반납이나 프로세스 전체 RAM의
+절감을 측정한 결과는 아니다. 첫 통합의 시간 측정도 이 빌드의 속도 증거로 재사용하지 않는다.
+
+이전 빌드와 771개 스냅샷에서 상태·출력·진단 및 표시 작업량·명령 수·캐시 적중이
+일치했다. 입력·초기화·재적용·기록 삭제를 섞었다. 별도로 교체 준비 중 기존 이벤트와
+표시를 실행하고, 512개 명령을 준비하는 동안 설정·기록 삭제·초기화를 반복해
+교체할 코드가 훼손되지 않는지 검증했다. 거절·취소·중복 취소도 확인했다.
+Zig 네이티브 23개, JavaScript/CLI/Wasm 47개 검사가 통과했다.
+최신 Wasm을 실제 Chromium에 올린 12개 확인도 통과했다. 작성·수정·기록 삭제·
+한도 초과·복구와 공유 공간의 크기를 확인했으며, 처리되지 않은 브라우저 오류는 없었다.
+UI 한도 초과는 첫 통합과 같은 테스트 전용 모듈 응답 변경으로 유도했고,
+검사 뒤 원래 설정과 빈 작업물로 복원했다.
+
+트레이드오프는 코드 교체를 시작하면 캐시를 잃는다는 것이다. 실패·취소하더라도
+캐시까지 보존하지 않으며, 아주 작은 작업 한도는 재계산에 부족할 수 있다.
+현재 프로그램·상태·이벤트 진단은 보존한다. 동시 스레드나 비동기 재진입은 지원하지 않는다.
+
+- [현재 빌드·검증 기록](../../prototypes/workbench/results/2026-09-23-workspace/verification.json)
+- [이전 빌드와 비교한 원자료](../../prototypes/workbench/results/2026-09-23-workspace/comparison.json)
+- [보존한 이전 소스·Wasm 목록](../../prototypes/workbench/results/2026-09-22-evaluation/sources/manifest.json)
+- [현재 Wasm에서 교체 중 실행 검사](../../prototypes/workbench/workspace.test.mjs)
+- [현재 브라우저 검사 절차](../../prototypes/workbench/qa-evaluation.js),
+ [12개 확인 결과](../../prototypes/workbench/results/2026-09-23-workspace/browser.json),
+ [한도 초과 화면](../../output/playwright/pure-workspace-limit.png)
+
+```sh
+node prototypes/workbench/workspace.test.mjs
+node prototypes/workbench/workspace-check.mjs --output /tmp/pure-workspace-new.json
+```
+
+이로써 표시 계산 계약의 통합과 그 추가 공간을 줄이는 후속 구현을 마무리한다.
+이 기능의 합성 측정은 더 늘리지 않는다. 큰 앱과 문서의 메모리 문제는
+별도의 실제 작업으로 확인해야 하며 이번 결과로 해결했다고 주장하지 않는다.