64비트가 스펙의 기본값이 되는 게 정말 기대되는 부분임, 특히 온라인 영상 편집기 같은 웹앱들은 32비트 한계 때문에 지금도 여러가지 제약을 많이 받고 있음, Figma에서도 이런 제약을 직접 경험하고 있음, 한 가지 궁금한 점은 모바일 기기에서 탭별 주소 지정 메모리 제한이 그대로 유지될지 여부임, 보통은 OS에 의해 정의되어 있어서 32비트 공간과 직접적으로 연결되어 있지 않을 수도 있음
Video editor 같은 앱이 문서 브라우저에 들어온다는 것이 옳은지 의문임, 잘 만들어진 네이티브 운영체제가 있음에도 이제 아무도 쓰지 않는다는 점이 아쉬움, 만약 기존 운영체제 프로세스에서 주는 가상화보다 더 강력한 가상화 머신이 필요하다면, 아예 목적에 맞는 추상화를 설계하는 게 정직하다고 생각함, 단순한 문서 리더를 억지로 영상 편집기로 개조하는 느낌이 있음
아쉽게도 Memory64 기능은 성능 페널티가 꽤 큼, 기존 32비트에서는 런타임이 매번 4GB 전체를 할당해버려서 경계 체크가 사실상 필요 없었지만, 64비트에서는 경계를 직접 확인해야 하기 때문임, 4GB 이상 메모리가 꼭 필요하다면 어쩔 수 없이 써야 함
GC, 참조 타입, JS string API가 도입되는 것도 기대됨, 오랜만에 반가운 J, 잘 지내고 있는지 궁금함
웹앱이 4GiB 메모리 한도에 막히는 게 당연해 보이긴 함, 요즘 메일 읽는 데 512GiB가 최소인 세상 느낌임
가비지 컬렉션이 추가된다는 점이 정말 신기함, 기존에는 Wasm에서 스택에 직접 접근할 수 없어서 스택 스캐닝 같은 전통적 GC 접근이 불가능했음, 덕분에 러우 레벨 언어 성격을 유지하면서 struct, array 타입, unboxed tagged int 등으로 메모리 레이아웃을 명시하고, 할당과 수명 관리는 Wasm이 처리하게 됨, 여기까지임, 감탄스러움
GC가 도입되면서 비GC 환경까지 모두 지원하는 구조라 신선함, 이 점이 D 언어와 유사함(D는 비GC와 GC 모두 빠른 컴파일, 실행 지원함), 참고로 Dlang 컴파일러인 LDC로도 이제 Wasm 생성 가능함 Generating WebAssembly with LDC
이 변화로 WebAssembly.Memory 객체의 크기 축소가 가능해지는지 궁금함, 메모리를 해제해도 아직 브라우저에 할당된 상태로 남는다는 점에서 매우 중요한 이슈임 이슈1이슈2
WASM이 DOM을 직접적으로 건드릴 수 있게 되는 시점이 언제인지 궁금함, 이게 원래 WASM의 핵심 목적 같았는데, 지금은 웹과 거의 상관없는 별도의 괴물처럼 느껴짐, JavaScript는 언제쯤 안 써도 되게 될지 궁금함
이 부분과 멀티스레드 접근이 제대로 지원되길 바람, Rust 앱을 써서 wasm으로 컴파일해서 아래처럼 바로 불러오고 싶음:
고성능 웹앱, 또는 브라우저 확장 같은 곳에서 메모리, 성능 이슈가 실제로 크니까 이게 엄청 도움이 될 것임, wasm 기반 앱이면 v8을 건너뛰고 wasmer 같은 엔진도 직접 쓸 수 있음, 웹 기술이 Electron 같은 데스크톱 앱에 쓰이는 건 데스크톱 API가 너무 별로고 이식성이 없어서라고 생각함, WASM의 네이티브 지원이 강화되면 Slack, VSCode, Discord 같은 앱들이 더 가벼워질 수 있음
지금도 WASM 프로그램으로 DOM 접근 가능함, 다만 기존 JS API를 통해야 해서, 한때 WASM 전용 API를 논의했으나 단점이 많아져서 결국 폐기된 상태임
설계 잘된 프런트엔드 언어를 기다리며 상황을 지켜보고 있음, 그런데 DOM에 접근할 때 JS 래퍼를 거치는 게 그렇게까지 비효율적인가 의문임, 대부분의 코드는 이미 비효율적이어서, 여기서 오는 오버헤드는 실제로 그다지 두드러지지 않는다고 생각함
JavaScript에 문제가 있다고 생각한다면 DOM 쪽은 더 심각한 걸 알게 될 것임
DOM 참조를 가지게 되면 가비지 컬렉션 가능한 객체를 직접 들여다볼 수 있게 된다는 점이 tricky함, 웹 JavaScript 보안 모델상 GC 내부를 들여다볼 수 없어야 하는데, 만약 WASM이 DOM에 포인터를 들고 있다면 그걸 어떻게 처리해야 할지가 문제임, GC가 제대로 도입된 후에는 이 문제가 다시 논의될 수 있겠지만, GC 없는 WASM에서는 거의 답이 없는 문제로 보임
WASM 개발을 1년 정도 팔로업 안 했더니, 버전별 릴리즈 모델로 넘어갔다는 걸 이제야 알게 되었음, 여러 기능이 옵션으로 남을 줄 알았는데, 이제는 모든 구현체가 모든 기능을 지원해야 특정 버전 호환이라고 말할 수 있게 된 듯함(WASM 3.0 등), 두 번째로 3.0 완전 지원하는 non-browser 워크타임이 누가 될지 궁금함, wasmtime이 첫 번째일 것 같음(deno는 v8 기반이라 제외), GC는 특히 tricky한 기능처럼 느껴짐, 3.0 릴리즈가 기존 "evergreen" 모델과 어떻게 연결되는지 아는 사람 있는지 궁금함, evergreen은 계속 표준 초안만 갱신하고, 공식 최종 버전은 따로 두지 않는 모델임, 현재 최신 Candidate Recommendation Draft가 사실상 표준으로 간주됨 wasm feature 현황wasm 2.0 소식최신 표준 초안
wasmtime은 이미 wasm 3.0의 주요 기능을 전부 지원함, GC는 동료 Nick Fitzgerald가 몇 년 전에 구현했고, tail call은 작년에 Jamey Sharp와 Trevor Elliott가 완전 범위로 구현했음(시그니처 제한 없이, 트램폴린 필요 없음), 예외 처리도 나와서 곧 정식 릴리즈 예정임, "3.0"이라는 릴리즈는 엔진별로 각 기능을 이미 다 준비해왔다는 신호라고 보면 됨, 나는 wasmtime과 Cranelift 메인테이너임
Wizard는 research 용 툴이지만 Wasm 3.0을 모두 지원함, 대신 인터프리터와 baseline 컴파일러만 있고, v8이나 wasmtime처럼 최적화된 컴파일러는 없음, 그래서 속도 자체는 느림
버전 관리가 JavaScript의 feature set 방식처럼 될 것 같음, 즉 각 런타임이 어떤 기능 셋을 지원하는지로 말해지게 됨, wasm에서 feature discovery(기능 탐지)는 어떻게 돌아가는지 궁금함
GC 지원이 추가된 점이 정말 반가움, 예전엔 WASM에서 스택에 직접 접근이 안 돼서 전통적 stack scanning 방식의 GC 구현이 사실상 불가능했음
WebAssembly 커뮤니티가 개발자 경험(DX)를 더 신경 써야 한다고 느낌, 직접 컴파일러를 하나 작성해서 Wasm을 타겟으로 삼아봤는데 꽤 불편했음, 정형화된 의미를 가진 언어라고 생각했지만 실제로는 Binaryen.js로 Wasm을 생성하는 과정에서 명확한 인스트럭션 집합을 타겟팅하는 기분이 별로 안 들었음, 아마 Binaryen 자체와 문서 부족 탓이라고 생각함, Wasm 텍스트 스니펫은 작성할 때 재밌었다는 점이 위안임 jasmine wasm 컴파일러
Binaryen은 예전 Wasm가 AST라서 쌓인 레거시가 많음, 새로운 기능들은 기존 모델에 맞추기가 어려움, 우리 컴파일러는 따로 추상 Wasm 표현용 자료구조를 정의해서 쓰고, 컴파일 디폴트는 .wasm, 디버그 때는 .wat로 각각 내보냄, 꽤 직관적이라 인스트럭션 셋은 괜찮다고 생각함 Scala.js wasm backend
TypeScript에서 Binaryen을 써보다가 비슷하게 답답함을 느낌, Rust 기반 wasm-tools로 갈아탔는데 훨씬 나은 경험이었음
구체적으로 어떤 부분이 힘들었는지 궁금함, validation error가 정말 짜증나는 경우가 있어서 Wizard에도 --trace-validation 옵션을 둠, 검증 과정을 보기 쉽게 시각화해줌
binaryen.js 문서나 바인딩이 실제로 많이 부족하긴 함, 현재는 core Binaryen의 최적화 개선에 역량이 집중돼 있어서 JS/TS 쪽은 발전이 느림, 그래도 누군가 JS/TS 바인딩 개선에 시간을 쓴다면 모두에게 좋을 거라고 생각함
순수 어셈블리 코드를 처음부터 만드는 게 더 쉽다는 느낌도 받음, 대부분의 자료가 Rust 툴에 집중되는데, 직접 손으로 쓰는 경험도 중요함, compiler와 assembly는 별개임, 컴파일러 개발자만 Wasm에 관심 가지는 게 아니라는 관점도 필요함
WASM에 여전히 기대를 가지고 있음, 이번 릴리즈가 멋져 보임, envoy에서 트래픽 많은 WASM 플러그인을 돌리고 있고, zellij 같은 터미널 앱용 플러그인에도 WASM을 쓰고 있음, 작은 사이드 프로젝트에선 rust leptos 기반 wasm 웹앱도 운영 중임, 솔직히 3개 중 2개는 기술적으로 최적 선택이 아닐 수도 있지만, 이 흐름이 앞으로 잘 이어질 것 같음, 모두 수고 많음
단순한 게 최고임, 내 바람은 더 쉽고 빠른 Go struct 전달 방법임, go struct를 런타임에 넣거나 뺼 때 코드가 꼬이지 않고, 덧댄 솔루션을 쓸 일 없었으면 함, 여러 언어에 쓸 만한 범용 솔루션도 좋고, 그런데 현실적인 제한이 따르는 것도 괜찮음, 나에겐 go가 가장 중요함
이 말에 공감함, 그리고 GC 없는 언어에서도 현실적으로 별로 더 낫지 않음, 실제로는 wasm에서 GC된 런타임들이 오히려 더 엉망임, 지금까지 쓴 JavaScript 중에 최악 경험은 수동 포인터 정리였음, C++에서는 스코프 벗어나면 소멸자가 처리해주는데 wasm, js에서는 전부 직접 관리해야 해서 JNI 했던 기억이 더 나았음(go 포함), 그리고 고생 끝에 겨우 struct 하나 전달하면 호출당 오버헤드가 커서 결국 더 큰 단위로 포장해 넘기기 시작함, 나 역시 wasm이 파이프라인만 괜찮아지길 바람, 지금까지는 힘듦
네이티브 코드라면 해법은 똑같음: 언어 간에 표준 구조(C struct 등)에 맞추거나 serialize/deserialzie 함, 여러 런타임을 뒤섞어서 쓸 때 언어들이 직접 지원 안 하면 진짜 피곤한 상황임, 이게 왜 문제인지 obvious함
원하는 게 뭔지 정확히는 모르겠으나, WASI의 근간이 되는 component model이 도움이 될 듯함, 이 모델은 각 모듈이 자체적으로 데이터를 메모리에 맵핑하는 방식을 정하고(나중엔 GC heap까지도), 구조체 타입 같은 것도 인터페이스로 정의해서 컴파일러가 glue 코드를 자동 생성하게 해줌
이건 WASM 스펙이 아니라 라이브러리 영역인 것 같음, 내부적으로 이런 코드 제너레이터를 잘 써본 경험 있음
OpenMP 지원 기대 중임, 실험적으로 Solvespace 웹 빌드를 돌리고 있고, OpenMP 지원되면 크게 좋아질 것 같음 online solvespace demo, 브라우저에서 돌아가는 오픈소스 CAD임
Solvespace 정말 멋진 툴이라고 생각함, 예전에 유튜브 튜토리얼 따라가면서 분할형 키보드 케이스를 설계해서 CNC로 만들기도 했었음, 빠르게 결과를 만들 수 있었음, 유지 관리해줘서 고마움
지금까지 본 WASM 기반 웹 UI 중 최고라고 생각함, 데스크톱 빌드를 Emscripten으로 돌릴 때 가장 어려웠던 점이 뭔지 궁금함
아직 언급된 적 없는 내용이라 남김: multiple-memories 기능이 WebGPU 리소스 매핑 시 중복 복사를 피하는 데 사용될 수 있을지 궁금함, 지금은 ArrayBuffer에 매핑된 게 있어서 WASM에서는 JS 통해 복사해야 하고 성능이 불리함, 여러 WASM 메모리와 Clang/LLVM의 address space 기능이 해결책이 될 것 같지만 실제로 그렇게 간단한지는 잘 모르겠음
이 모든 게 예전 segmented memory, far-pointers 떠올림, 최근에 Gameboy 게임을 짜보고 있어서 메모리 매핑이 "재미"의 일부이긴 한데, 제약 없는 환경에서 이걸 반복하는 건 좀 싫음, DOS/Win16 시절 far pointers를 묻어버린 데는 그만한 이유가 있었음
Hacker News 의견
64비트가 스펙의 기본값이 되는 게 정말 기대되는 부분임, 특히 온라인 영상 편집기 같은 웹앱들은 32비트 한계 때문에 지금도 여러가지 제약을 많이 받고 있음, Figma에서도 이런 제약을 직접 경험하고 있음, 한 가지 궁금한 점은 모바일 기기에서 탭별 주소 지정 메모리 제한이 그대로 유지될지 여부임, 보통은 OS에 의해 정의되어 있어서 32비트 공간과 직접적으로 연결되어 있지 않을 수도 있음
Video editor 같은 앱이 문서 브라우저에 들어온다는 것이 옳은지 의문임, 잘 만들어진 네이티브 운영체제가 있음에도 이제 아무도 쓰지 않는다는 점이 아쉬움, 만약 기존 운영체제 프로세스에서 주는 가상화보다 더 강력한 가상화 머신이 필요하다면, 아예 목적에 맞는 추상화를 설계하는 게 정직하다고 생각함, 단순한 문서 리더를 억지로 영상 편집기로 개조하는 느낌이 있음
아쉽게도 Memory64 기능은 성능 페널티가 꽤 큼, 기존 32비트에서는 런타임이 매번 4GB 전체를 할당해버려서 경계 체크가 사실상 필요 없었지만, 64비트에서는 경계를 직접 확인해야 하기 때문임, 4GB 이상 메모리가 꼭 필요하다면 어쩔 수 없이 써야 함
GC, 참조 타입, JS string API가 도입되는 것도 기대됨, 오랜만에 반가운 J, 잘 지내고 있는지 궁금함
웹앱이 4GiB 메모리 한도에 막히는 게 당연해 보이긴 함, 요즘 메일 읽는 데 512GiB가 최소인 세상 느낌임
가비지 컬렉션이 추가된다는 점이 정말 신기함, 기존에는 Wasm에서 스택에 직접 접근할 수 없어서 스택 스캐닝 같은 전통적 GC 접근이 불가능했음, 덕분에 러우 레벨 언어 성격을 유지하면서 struct, array 타입, unboxed tagged int 등으로 메모리 레이아웃을 명시하고, 할당과 수명 관리는 Wasm이 처리하게 됨, 여기까지임, 감탄스러움
GC가 도입되면서 비GC 환경까지 모두 지원하는 구조라 신선함, 이 점이 D 언어와 유사함(D는 비GC와 GC 모두 빠른 컴파일, 실행 지원함), 참고로 Dlang 컴파일러인 LDC로도 이제 Wasm 생성 가능함 Generating WebAssembly with LDC
이 변화로 WebAssembly.Memory 객체의 크기 축소가 가능해지는지 궁금함, 메모리를 해제해도 아직 브라우저에 할당된 상태로 남는다는 점에서 매우 중요한 이슈임 이슈1 이슈2
WASM이 DOM을 직접적으로 건드릴 수 있게 되는 시점이 언제인지 궁금함, 이게 원래 WASM의 핵심 목적 같았는데, 지금은 웹과 거의 상관없는 별도의 괴물처럼 느껴짐, JavaScript는 언제쯤 안 써도 되게 될지 궁금함
이 부분과 멀티스레드 접근이 제대로 지원되길 바람, Rust 앱을 써서 wasm으로 컴파일해서 아래처럼 바로 불러오고 싶음:
고성능 웹앱, 또는 브라우저 확장 같은 곳에서 메모리, 성능 이슈가 실제로 크니까 이게 엄청 도움이 될 것임, wasm 기반 앱이면 v8을 건너뛰고 wasmer 같은 엔진도 직접 쓸 수 있음, 웹 기술이 Electron 같은 데스크톱 앱에 쓰이는 건 데스크톱 API가 너무 별로고 이식성이 없어서라고 생각함, WASM의 네이티브 지원이 강화되면 Slack, VSCode, Discord 같은 앱들이 더 가벼워질 수 있음
지금도 WASM 프로그램으로 DOM 접근 가능함, 다만 기존 JS API를 통해야 해서, 한때 WASM 전용 API를 논의했으나 단점이 많아져서 결국 폐기된 상태임
설계 잘된 프런트엔드 언어를 기다리며 상황을 지켜보고 있음, 그런데 DOM에 접근할 때 JS 래퍼를 거치는 게 그렇게까지 비효율적인가 의문임, 대부분의 코드는 이미 비효율적이어서, 여기서 오는 오버헤드는 실제로 그다지 두드러지지 않는다고 생각함
JavaScript에 문제가 있다고 생각한다면 DOM 쪽은 더 심각한 걸 알게 될 것임
DOM 참조를 가지게 되면 가비지 컬렉션 가능한 객체를 직접 들여다볼 수 있게 된다는 점이 tricky함, 웹 JavaScript 보안 모델상 GC 내부를 들여다볼 수 없어야 하는데, 만약 WASM이 DOM에 포인터를 들고 있다면 그걸 어떻게 처리해야 할지가 문제임, GC가 제대로 도입된 후에는 이 문제가 다시 논의될 수 있겠지만, GC 없는 WASM에서는 거의 답이 없는 문제로 보임
WASM 개발을 1년 정도 팔로업 안 했더니, 버전별 릴리즈 모델로 넘어갔다는 걸 이제야 알게 되었음, 여러 기능이 옵션으로 남을 줄 알았는데, 이제는 모든 구현체가 모든 기능을 지원해야 특정 버전 호환이라고 말할 수 있게 된 듯함(WASM 3.0 등), 두 번째로 3.0 완전 지원하는 non-browser 워크타임이 누가 될지 궁금함, wasmtime이 첫 번째일 것 같음(deno는 v8 기반이라 제외), GC는 특히 tricky한 기능처럼 느껴짐, 3.0 릴리즈가 기존 "evergreen" 모델과 어떻게 연결되는지 아는 사람 있는지 궁금함, evergreen은 계속 표준 초안만 갱신하고, 공식 최종 버전은 따로 두지 않는 모델임, 현재 최신 Candidate Recommendation Draft가 사실상 표준으로 간주됨 wasm feature 현황 wasm 2.0 소식 최신 표준 초안
wasmtime은 이미 wasm 3.0의 주요 기능을 전부 지원함, GC는 동료 Nick Fitzgerald가 몇 년 전에 구현했고, tail call은 작년에 Jamey Sharp와 Trevor Elliott가 완전 범위로 구현했음(시그니처 제한 없이, 트램폴린 필요 없음), 예외 처리도 나와서 곧 정식 릴리즈 예정임, "3.0"이라는 릴리즈는 엔진별로 각 기능을 이미 다 준비해왔다는 신호라고 보면 됨, 나는 wasmtime과 Cranelift 메인테이너임
Wizard는 research 용 툴이지만 Wasm 3.0을 모두 지원함, 대신 인터프리터와 baseline 컴파일러만 있고, v8이나 wasmtime처럼 최적화된 컴파일러는 없음, 그래서 속도 자체는 느림
버전 관리가 JavaScript의 feature set 방식처럼 될 것 같음, 즉 각 런타임이 어떤 기능 셋을 지원하는지로 말해지게 됨, wasm에서 feature discovery(기능 탐지)는 어떻게 돌아가는지 궁금함
GC 지원이 추가된 점이 정말 반가움, 예전엔 WASM에서 스택에 직접 접근이 안 돼서 전통적 stack scanning 방식의 GC 구현이 사실상 불가능했음
WebAssembly 커뮤니티가 개발자 경험(DX)를 더 신경 써야 한다고 느낌, 직접 컴파일러를 하나 작성해서 Wasm을 타겟으로 삼아봤는데 꽤 불편했음, 정형화된 의미를 가진 언어라고 생각했지만 실제로는 Binaryen.js로 Wasm을 생성하는 과정에서 명확한 인스트럭션 집합을 타겟팅하는 기분이 별로 안 들었음, 아마 Binaryen 자체와 문서 부족 탓이라고 생각함, Wasm 텍스트 스니펫은 작성할 때 재밌었다는 점이 위안임 jasmine wasm 컴파일러
Binaryen은 예전 Wasm가 AST라서 쌓인 레거시가 많음, 새로운 기능들은 기존 모델에 맞추기가 어려움, 우리 컴파일러는 따로 추상 Wasm 표현용 자료구조를 정의해서 쓰고, 컴파일 디폴트는 .wasm, 디버그 때는 .wat로 각각 내보냄, 꽤 직관적이라 인스트럭션 셋은 괜찮다고 생각함 Scala.js wasm backend
TypeScript에서 Binaryen을 써보다가 비슷하게 답답함을 느낌, Rust 기반 wasm-tools로 갈아탔는데 훨씬 나은 경험이었음
구체적으로 어떤 부분이 힘들었는지 궁금함, validation error가 정말 짜증나는 경우가 있어서 Wizard에도 --trace-validation 옵션을 둠, 검증 과정을 보기 쉽게 시각화해줌
binaryen.js 문서나 바인딩이 실제로 많이 부족하긴 함, 현재는 core Binaryen의 최적화 개선에 역량이 집중돼 있어서 JS/TS 쪽은 발전이 느림, 그래도 누군가 JS/TS 바인딩 개선에 시간을 쓴다면 모두에게 좋을 거라고 생각함
순수 어셈블리 코드를 처음부터 만드는 게 더 쉽다는 느낌도 받음, 대부분의 자료가 Rust 툴에 집중되는데, 직접 손으로 쓰는 경험도 중요함, compiler와 assembly는 별개임, 컴파일러 개발자만 Wasm에 관심 가지는 게 아니라는 관점도 필요함
WASM에 여전히 기대를 가지고 있음, 이번 릴리즈가 멋져 보임, envoy에서 트래픽 많은 WASM 플러그인을 돌리고 있고, zellij 같은 터미널 앱용 플러그인에도 WASM을 쓰고 있음, 작은 사이드 프로젝트에선 rust leptos 기반 wasm 웹앱도 운영 중임, 솔직히 3개 중 2개는 기술적으로 최적 선택이 아닐 수도 있지만, 이 흐름이 앞으로 잘 이어질 것 같음, 모두 수고 많음
단순한 게 최고임, 내 바람은 더 쉽고 빠른 Go struct 전달 방법임, go struct를 런타임에 넣거나 뺼 때 코드가 꼬이지 않고, 덧댄 솔루션을 쓸 일 없었으면 함, 여러 언어에 쓸 만한 범용 솔루션도 좋고, 그런데 현실적인 제한이 따르는 것도 괜찮음, 나에겐 go가 가장 중요함
이 말에 공감함, 그리고 GC 없는 언어에서도 현실적으로 별로 더 낫지 않음, 실제로는 wasm에서 GC된 런타임들이 오히려 더 엉망임, 지금까지 쓴 JavaScript 중에 최악 경험은 수동 포인터 정리였음, C++에서는 스코프 벗어나면 소멸자가 처리해주는데 wasm, js에서는 전부 직접 관리해야 해서 JNI 했던 기억이 더 나았음(go 포함), 그리고 고생 끝에 겨우 struct 하나 전달하면 호출당 오버헤드가 커서 결국 더 큰 단위로 포장해 넘기기 시작함, 나 역시 wasm이 파이프라인만 괜찮아지길 바람, 지금까지는 힘듦
네이티브 코드라면 해법은 똑같음: 언어 간에 표준 구조(C struct 등)에 맞추거나 serialize/deserialzie 함, 여러 런타임을 뒤섞어서 쓸 때 언어들이 직접 지원 안 하면 진짜 피곤한 상황임, 이게 왜 문제인지 obvious함
원하는 게 뭔지 정확히는 모르겠으나, WASI의 근간이 되는 component model이 도움이 될 듯함, 이 모델은 각 모듈이 자체적으로 데이터를 메모리에 맵핑하는 방식을 정하고(나중엔 GC heap까지도), 구조체 타입 같은 것도 인터페이스로 정의해서 컴파일러가 glue 코드를 자동 생성하게 해줌
이건 WASM 스펙이 아니라 라이브러리 영역인 것 같음, 내부적으로 이런 코드 제너레이터를 잘 써본 경험 있음
OpenMP 지원 기대 중임, 실험적으로 Solvespace 웹 빌드를 돌리고 있고, OpenMP 지원되면 크게 좋아질 것 같음 online solvespace demo, 브라우저에서 돌아가는 오픈소스 CAD임
Solvespace 정말 멋진 툴이라고 생각함, 예전에 유튜브 튜토리얼 따라가면서 분할형 키보드 케이스를 설계해서 CNC로 만들기도 했었음, 빠르게 결과를 만들 수 있었음, 유지 관리해줘서 고마움
지금까지 본 WASM 기반 웹 UI 중 최고라고 생각함, 데스크톱 빌드를 Emscripten으로 돌릴 때 가장 어려웠던 점이 뭔지 궁금함
아직 언급된 적 없는 내용이라 남김: multiple-memories 기능이 WebGPU 리소스 매핑 시 중복 복사를 피하는 데 사용될 수 있을지 궁금함, 지금은 ArrayBuffer에 매핑된 게 있어서 WASM에서는 JS 통해 복사해야 하고 성능이 불리함, 여러 WASM 메모리와 Clang/LLVM의 address space 기능이 해결책이 될 것 같지만 실제로 그렇게 간단한지는 잘 모르겠음
multi-memory toolchain 지원 논의가 있긴 했으나, LLVM에서 여러 주소공간을 활용한 구현이 실제로 됐는지는 잘 모르겠음
이 모든 게 예전 segmented memory, far-pointers 떠올림, 최근에 Gameboy 게임을 짜보고 있어서 메모리 매핑이 "재미"의 일부이긴 한데, 제약 없는 환경에서 이걸 반복하는 건 좀 싫음, DOS/Win16 시절 far pointers를 묻어버린 데는 그만한 이유가 있었음