WebAssembly의 JavaScript Promise Integration (JSPI) API에 새로운 API가 추가되었으며 Chrome M126 릴리스에서 사용할 수 있습니다. 변경된 사항, Emscripten과 함께 사용하는 방법, 그리고 JSPI를 위한 로드맵에 대해 논의합니다.
JSPI는 순차적인 API를 사용하는 WebAssembly 애플리케이션이 비동기적인 웹 API에 접근할 수 있도록 하는 API입니다. 많은 웹 API는 JavaScript Promise 객체를 바탕으로 만들어졌습니다: 요청된 작업을 즉시 수행하는 대신, 이를 수행하기 위한 Promise를 반환합니다. 반면에, WebAssembly로 컴파일된 많은 애플리케이션은 호출자가 완료될 때까지 대기하는 API가 지배적인 C/C++ 세계에서 유래됩니다.
WebAssembly의 JavaScript Promise Integration(JSPI) API가 Chrome M123 릴리스와 함께 오리진 트라이얼에 진입합니다. 이를 통해 여러분과 사용자들이 이 새로운 API로부터 이점이 있는지 테스트할 수 있습니다.
JSPI는 순차적 코드라고 불리는 코드를 WebAssembly로 컴파일한 후 비동기적인 웹 API에 액세스할 수 있도록 하는 API입니다. 많은 웹 API는 JavaScript의 Promise를 기반으로 설계되어 요청된 작업을 즉시 수행하는 대신 그 작업을 수행하겠다는 Promise를 반환합니다. 작업이 최종적으로 수행되면 브라우저의 작업 실행기가 Promise와 함께 콜백을 호출합니다. JSPI는 이 구조에 연결되며, WebAssembly 애플리케이션이 Promise가 반환될 때 중단되고, Promise가 완료될 때 다시 실행되는 기능을 제공합니다.
V8의 짜릿한 세계에 오신 것을 환영합니다. 여기서는 속도가 단순한 기능이 아닌 삶의 방식입니다. 2023년을 보내며 V8이 올해 이룩한 놀라운 성과를 축하할 때입니다.
혁신적인 성능 최적화를 통해 V8은 웹의 끊임없이 진화하는 환경에서 가능한 것의 경계를 계속해서 넓혀가고 있습니다. 우리는 새로운 중간 단계 컴파일러를 도입하고, 최고 단계 컴파일러 인프라, 런타임 및 가비지 컬렉터에 여러 가지 개선을 적용하여 전반적으로 상당한 속도 향상을 이루었습니다.
WebAssembly Garbage Collection (WasmGC)에 대한 최근의 글은 쓰레기 수집(GC) 제안이 GC 언어를 Wasm에서 더 잘 지원하도록 어떻게 목표를 설정하는지 고수준에서 설명하고 있습니다. GC 언어들의 인기를 고려할 때 이는 매우 중요합니다. 이번 글에서는 Java, Kotlin, Dart, Python, C# 같은 GC 언어를 Wasm으로 포팅하는 기술적 세부 사항에 대해 살펴볼 것입니다. 실제로 두 가지 주요 접근 방식이 있습니다:
우리는 WebAssembly 꼬리 호출을 V8 v11.2에 출시합니다! 이 게시물에서는 이 제안에 대한 간략한 개요를 제공하고, Emscripten을 사용한 C++ 코루틴의 흥미로운 사용 사례를 보여주며, V8이 꼬리 호출을 내부적으로 처리하는 방법을 보여줍니다.
호출이 현재 함수에서 반환하기 전에 실행되는 마지막 명령일 때 꼬리 위치에 있다고 말합니다. 컴파일러는 호출자 프레임을 버리고 호출을 점프로 대체하여 이러한 호출을 최적화할 수 있습니다.
이것은 특히 재귀 함수에 유용합니다. 예를 들어, 연결 리스트 요소의 합을 계산하는 다음과 같은 C 함수를 보세요:
int sum(List* list, int acc) {
if (list == nullptr) return acc;
return sum(list->next, acc + list->val);
}
정상적인 호출로는 이 작업은 𝒪(n) 스택 공간을 소비합니다: 리스트의 각 요소는 호출 스택에 새로운 프레임을 추가합니다. 리스트가 충분히 길면 스택이 매우 빠르게 넘칠 수 있습니다. 호출을 점프로 대체함으로써 꼬리 호출 최적화는 이 재귀 함수를 루프로 변환하여 𝒪(1) 스택 공간을 사용하게 만듭니다:
V8에는 WebAssembly 코드를 기계 코드로 컴파일하여 실행할 수 있도록 하는 두 가지 컴파일러가 있습니다: 기본 컴파일러 __Liftoff__와 최적화 컴파일러 TurboFan 입니다. Liftoff는 TurboFan보다 훨씬 빠르게 코드를 생성할 수 있어 빠른 시작 시간을 제공합니다. 반면 TurboFan은 더 빠른 코드를 생성하여 높은 성능을 제공합니다.
우리는 .wasm 파일을 생성하거나 조작하는 컴파일러 및 기타 도구의 수가 점점 늘어나고 있으며, 때로는 그 안을 살펴보고 싶을 때가 있습니다. 아마도 당신은 그런 도구의 개발자이거나, 더 직접적으로는 Wasm을 대상으로 삼는 프로그래머로서 생성된 코드가 어떤 모습인지 성능이나 기타 이유로 궁금할 수 있습니다.
Emscripten은 항상 웹 및 Node.js와 같은 기타 JavaScript 환경에 컴파일하는 것을 최우선으로 고려해 왔습니다. 하지만 WebAssembly가 JavaScript 없이 사용되기 시작하면서 새로운 사용 사례가 등장하고, 우리는 Emscripten에서 독립형 Wasm 파일을 출력할 수 있는 지원을 개발해 왔습니다. 이는 Emscripten JS 런타임에 의존하지 않는 파일입니다. 이 게시물에서는 그 이유가 흥미로운 이유를 설명합니다.
WebAssembly는 일반적으로 소스 언어에서 컴파일되며, 이는 개발자가 WebAssembly를 사용하기 위해 도구가 필요함을 의미합니다. 그렇기 때문에 V8 팀은 LLVM, Emscripten, Binaryen, WABT와 같은 관련 오픈 소스 프로젝트에서 작업하고 있습니다. 이 게시물은 Emscripten과 LLVM에서 우리가 수행해 온 작업을 설명하며, 곧 Emscripten이 기본적으로 LLVM WebAssembly 백엔드로 전환할 수 있게 될 것입니다. 많은 테스트를 거쳐 문제를 보고해주세요!
개발자들 사이에는 가장 빠른 코드는 실행되지 않는 코드라는 말이 있습니다. 마찬가지로, 가장 빠른 컴파일 코드도 컴파일되지 않아야 합니다. WebAssembly 코드 캐싱은 Chrome과 V8에 새롭게 도입된 최적화 기술로, 컴파일러가 생성한 네이티브 코드를 캐싱하여 코드 컴파일을 피하려고 합니다. 우리는 JavaScript 코드 캐싱에 관해 이미 글을 작성했으며, 이 최적화를 활용하기 위한 모범 사례에 대해 논의한 바 있습니다. 이번 블로그 글에서는 Chrome의 WebAssembly 코드 캐싱 운영 방식과 이를 통해 대형 WebAssembly 모듈을 사용하는 애플리케이션의 로딩 속도를 높이는 방법에 대해 설명합니다.