앱의 자바스크립트에서 핫 경로를 WebAssembly로 대체

Surma

계속 빠릅니다.

이전 도움말에서 WebAssembly를 통해 C/C++ 라이브러리 생태계를 웹에 가져오는 방법에 관해 알아보았습니다. C/C++ 라이브러리를 광범위하게 사용하는 앱 중 하나는 C++에서 WebAssembly로 컴파일된 다양한 코덱으로 이미지를 압축할 수 있는 Google의 웹 앱인 squoosh입니다.

WebAssembly는 .wasm 파일에 저장된 바이트 코드를 실행하는 하위 수준의 가상 머신입니다. 이 바이트 코드는 JavaScript보다 훨씬 빨리 호스트 시스템에 맞게 컴파일되고 최적화될 수 있는 강력한 유형이 지정되고 구조화됩니다. WebAssembly는 처음부터 샌드박싱과 임베딩을 염두에 두고 있던 코드를 실행할 수 있는 환경을 제공합니다.

제 경험에 의하면 웹에서 대부분의 성능 문제는 강제 레이아웃과 과도한 페인트로 인해 발생하지만 때때로 앱에서 계산 비용이 많이 들고 많은 시간이 걸리는 작업을 실행해야 합니다. 여기서 WebAssembly가 도움이 될 수 있습니다

참고: 법적 문제로 인해 이 도움말에서는 브라우저의 이름을 지정하지 않기로 했습니다.

핫 패스

여기서는 이미지 버퍼를 90도의 배수만큼 회전하는 JavaScript 함수를 작성했습니다. 이 경우 OffscreenCanvas가 이상적이겠지만 타겟 브라우저에서 지원되지 않으며 Chrome에서 버그가 발생합니다.

이 함수는 입력 이미지의 모든 픽셀을 반복하고 출력 이미지의 다른 위치에 이를 복사하여 회전합니다. 4094x4096픽셀 이미지 (16메가픽셀)의 경우 '핫 경로'라고 하는 내부 코드 블록을 1, 600만 번 이상 반복해야 합니다. 반복 횟수가 비교적 많음에도 불구하고 테스트한 브라우저 3개 중 2개에서 2초 이내에 작업을 완료합니다. 이 유형의 상호작용에 허용되는 기간입니다.

for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
    for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
    const in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
    outBuffer[i] = inBuffer[in_idx];
    i += 1;
    }
}

하지만 브라우저 하나를 사용하면 8초 이상 걸립니다. 브라우저가 JavaScript를 최적화하는 방법은 매우 복잡하며, 엔진마다 최적화가 다릅니다. 일부는 원시 실행에 맞게 최적화하고 일부는 DOM과의 상호작용에 맞게 최적화합니다. 이 경우 한 브라우저에서 최적화되지 않은 경로가 발생했습니다.

반면에 WebAssembly는 원시 실행 속도를 기반으로 빌드됩니다. 이러한 코드로 여러 브라우저에서 빠르고 예측 가능한 성능을 원하는 경우 WebAssembly가 도움이 될 수 있습니다.

예측 가능한 성능을 위한 WebAssembly

일반적으로 JavaScript와 WebAssembly는 동일한 최대 성능을 달성할 수 있습니다. 하지만 JavaScript의 경우 '빠른 경로'를 통해서만 이 성능에 도달할 수 있으므로 '빠른 경로'를 유지하기가 까다로울 수 있습니다. WebAssembly가 제공하는 중요한 이점은 여러 브라우저에서도 예측 가능한 성능입니다. 엄격한 입력 및 하위 수준 아키텍처를 사용하면 컴파일러가 더 강력한 보장을 할 수 있으므로 WebAssembly 코드가 한 번만 최적화되고 항상 '빠른 경로'를 사용하게 됩니다.

WebAssembly용으로 작성

이전에는 웹에서 해당 기능을 사용하기 위해 C/C++ 라이브러리를 가져와 WebAssembly로 컴파일했습니다. 라이브러리의 코드는 다루지 않았으며, 브라우저와 라이브러리 사이의 브리지를 형성하기 위해 소량의 C/C++ 코드를 작성했을 뿐입니다. 이번에는 동기가 다릅니다. WebAssembly의 이점을 활용할 수 있도록 WebAssembly를 염두에 두고 무언가를 처음부터 작성하려고 합니다.

WebAssembly 아키텍처

WebAssembly for를 작성할 때는 WebAssembly가 실제로 무엇인지 이해하면 도움이 됩니다.

WebAssembly.org를 인용하려면 다음과 같이 하세요.

참고: WebAssembly (약칭 Wasm)는 스택 기반 가상 머신용 바이너리 명령어 형식입니다. Wasm은 C/C++/Rust와 같은 상위 수준 언어를 컴파일하기 위한 이식 가능한 대상으로 설계되어, 클라이언트 및 서버 애플리케이션을 웹에서 배포할 수 있습니다.

C 또는 Rust 코드를 WebAssembly로 컴파일하면 모듈 선언이 포함된 .wasm 파일이 생성됩니다. 이 선언은 모듈이 환경에서 예상하는 '가져오기' 목록, 이 모듈이 호스트에 사용할 수 있는 내보내기 목록 (함수, 상수, 메모리 청크), 물론 내부에 포함된 함수의 실제 바이너리 명령어로 구성됩니다.

이 문제를 조사해 보기 전에는 깨닫지 못했습니다. WebAssembly를 '스택 기반 가상 머신'으로 만드는 스택이 WebAssembly 모듈이 사용하는 메모리 청크에 저장되지 않는다는 것입니다. 스택은 완전히 VM 내부이며 웹 개발자가 액세스할 수 없습니다 (DevTools를 통한 경우 제외). 따라서 추가 메모리가 전혀 필요하지 않고 VM 내부 스택만 사용하는 WebAssembly 모듈을 작성할 수 있습니다.

참고: Emscripten과 같은 컴파일러는 여전히 WebAssembly 메모리를 사용하여 자체 스택을 구현합니다. 이렇게 해야 VM 내부 스택이 허용하지 않는 C의 포인터와 같은 구성을 통해 스택의 모든 위치에 있는 값에 액세스할 수 있습니다. 따라서 WebAssembly를 통해 C를 실행하면 두 스택이 사용되므로 다소 혼란스러울 수 있습니다.

여기서는 추가 메모리를 사용하여 이미지 픽셀에 대한 임의 액세스를 허용하고 이미지의 회전된 버전을 생성해야 합니다. WebAssembly.Memory의 용도는 다음과 같습니다.

메모리 관리

일반적으로 추가 메모리를 사용하면 어떤 식으로든 메모리를 관리해야 할 필요가 있습니다. 메모리의 어느 부분이 사용됩니까? 어떤 것이 무료인가요? 예를 들어 C에는 연속 바이트 n바이트의 메모리 공간을 찾는 malloc(n) 함수가 있습니다. 이러한 종류의 함수를 '할당자'라고도 합니다. 물론 사용 중인 할당자를 구현하면 WebAssembly 모듈에 포함되어야 하므로 파일 크기가 늘어납니다. 이러한 메모리 관리 함수의 크기와 성능은 사용된 알고리즘에 따라 상당히 달라질 수 있습니다. 따라서 많은 언어에서 선택할 수 있는 여러 구현 ('dmalloc', 'emmalloc', 'wee_alloc' 등)을 제공합니다.

여기서는 WebAssembly 모듈을 실행하기 전에 입력 이미지의 크기 (및 출력 이미지의 크기)를 확인합니다. 여기서 기회를 포착했습니다. 이전에는 입력 이미지의 RGBA 버퍼를 WebAssembly 함수에 매개변수로 전달하고 회전된 이미지를 반환 값으로 반환했습니다. 이 반환 값을 생성하려면 할당자를 활용해야 합니다. 하지만 필요한 총 메모리 양 (입력 이미지의 두 배, 입력에 한 번, 출력에 한 번)을 알고 있으므로 JavaScript를 사용하여 WebAssembly 메모리에 입력 이미지를 넣고 WebAssembly 모듈을 실행하여 두 번째 회전된 이미지를 생성한 다음 JavaScript를 사용하여 결과를 다시 읽을 수 있습니다. 메모리 관리를 전혀 사용하지 않고 여기서 나갈 수 있습니다.

선택의 즐거움 제공

WebAssembly-fy를 실행하고자 하는 원래 JavaScript 함수를 보면 이 함수가 JavaScript 전용 API가 없는 순수한 계산 코드임을 알 수 있습니다. 따라서 이 코드를 원하는 언어로 포팅하는 것은 매우 간단해야 합니다. WebAssembly로 컴파일되는 세 가지 언어인 C/C++, Rust, AssemblyScript를 평가했습니다. 각 언어에 대해 답해야 하는 유일한 질문은 메모리 관리 함수를 사용하지 않고 원시 메모리에 어떻게 액세스 하는가입니다.

참고: 코드 샘플에서 '지루한' 부분은 건너뛰고 실제 핫 경로와 메모리 액세스에 중점을 두었습니다. 벤치마크와 함께 각 샘플의 전체 버전은 gist에서 확인할 수 있습니다.

C 및 Emscripten

Emscripten은 WebAssembly 타겟용 C 컴파일러입니다. Emscripten의 목표는 GCC 또는 clang과 같은 잘 알려진 C 컴파일러의 드롭인 대체 기능이며 대부분 플래그 호환입니다. 이는 기존 C 및 C++ 코드를 WebAssembly로 최대한 쉽게 컴파일할 수 있도록 하기 위한 Emscripten의 핵심 목표입니다.

원시 메모리에 액세스하는 것은 C의 본질이며 포인터가 존재하는 바로 그 이유 때문입니다.

uint8_t* ptr = (uint8_t*)0x124;
ptr[0] = 0xFF;

여기서는 숫자 0x124를 부호 없는 8비트 정수 (또는 바이트)를 가리키는 포인터로 바꿉니다. 이렇게 하면 ptr 변수를 메모리 주소 0x124에서 시작되는 배열로 효과적으로 변환하여 다른 배열과 마찬가지로 사용할 수 있으므로 읽기 및 쓰기를 위한 개별 바이트에 액세스할 수 있습니다. 여기서는 회전을 위해 재정렬하려는 이미지의 RGBA 버퍼를 찾습니다. 픽셀을 이동하려면 실제로 한 번에 연속 4바이트(채널당 1바이트: R, G, B, A)를 이동해야 합니다. 이를 더 쉽게 하기 위해 부호 없는 32비트 정수 배열을 만들 수 있습니다. 규칙에 따라 입력 이미지는 주소 4에서 시작하고 출력 이미지는 입력 이미지가 끝난 직후에 시작됩니다.

int bpp = 4;
int imageSize = inputWidth * inputHeight * bpp;
uint32_t* inBuffer = (uint32_t*) 4;
uint32_t* outBuffer = (uint32_t*) (inBuffer + imageSize);

for (int d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
    for (int d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
    int in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
    outBuffer[i] = inBuffer[in_idx];
    i += 1;
    }
}

참고: 0이 아닌 주소 4에서 시작하기로 한 이유는 주소 0이 많은 언어에서 특별한 의미가 있기 때문입니다. 바로 이 주소 0이 두려워하는 null 포인터이기 때문입니다. 기술적으로 0은 완벽하게 유효한 주소이지만, 많은 언어에서는 0을 포인터의 유효한 값으로 제외하고 예외를 발생시키거나 정의되지 않은 동작에 빠지게 됩니다.

전체 자바스크립트 함수를 C로 포팅한 후에는 emcc로 C 파일을 컴파일할 수 있습니다.

$ emcc -O3 -s ALLOW_MEMORY_GROWTH=1 -o c.js rotate.c

항상 그렇듯이 emscripten은 c.js라는 글루 코드 파일과 c.wasm라는 wasm 모듈을 생성합니다. wasm 모듈은 gzip을 최대 260바이트로 하지만 글루 코드는 gzip 후 약 3.5KB입니다. 약간의 수정 후에 글루 코드를 버리고 기본 API를 사용하여 WebAssembly 모듈을 인스턴스화할 수 있었습니다. C 표준 라이브러리에서 아무것도 사용하지 않는 한 Emscripten을 사용하여 이러한 작업을 수행할 수 있는 경우가 많습니다.

참고: Google은 Emscripten팀과 협력하여 글루 코드를 더 작게 만들거나 때로는 존재하지 않게 하는 작업을 진행하고 있습니다.

Rust

참고: 이 도움말의 출시 이후로 WebAssembly용으로 Rust를 최적화하는 방법을 자세히 알아봤습니다. 이 도움말 끝에 있는 업데이트 섹션을 참고하세요.

Rust는 리치 유형 시스템이 있고 런타임이 없으며 메모리 안전과 스레드 안전을 보장하는 소유권 모델을 갖춘 새로운 최신 프로그래밍 언어입니다. Rust는 또한 WebAssembly를 핵심 기능으로 지원하며 Rust팀은 WebAssembly 생태계에 뛰어난 도구를 많이 기여했습니다.

이러한 도구 중 하나는 rustwasm 작업 그룹의 wasm-pack입니다. wasm-pack는 코드를 가져와 webpack과 같은 번들러와 함께 즉시 작동하는 웹 친화적인 모듈로 변환합니다. wasm-pack는 매우 편리한 환경이지만 현재는 Rust에서만 작동합니다. 이 그룹은 다른 WebAssembly 타겟팅 언어에 대한 지원을 추가하는 것을 고려하고 있습니다.

Rust에서 슬라이스는 C에 있는 배열입니다. C에서와 마찬가지로 시작 주소를 사용하는 슬라이스를 만들어야 합니다. 이는 Rust가 적용하는 메모리 안전 모델에 어긋나므로 unsafe 키워드를 사용해야 이 모델을 준수하지 않는 코드를 작성할 수 있습니다.

참고: 이는 권장사항이 아닙니다. Google의 경험에 따르면 일반적으로 Rust가 상위 수준에서 작동하도록 Emscripten의 embind 또는 wasm-bindgen과 같은 결합 메커니즘을 사용하는 것이 좋습니다.

let imageSize = (inputWidth * inputHeight) as usize;
let inBuffer: &mut [u32];
let outBuffer: &mut [u32];
unsafe {
    inBuffer = slice::from_raw_parts_mut::<u32>(4 as *mut u32, imageSize);
    outBuffer = slice::from_raw_parts_mut::<u32>((imageSize * 4 + 4) as *mut u32, imageSize);
}

for d2 in 0..d2Limit {
    for d1 in 0..d1Limit {
    let in_idx = (d1Start + d1 * d1Advance) * d1Multiplier + (d2Start + d2 * d2Advance) * d2Multiplier;
    outBuffer[i as usize] = inBuffer[in_idx as usize];
    i += 1;
    }
}

다음을 사용하여 Rust 파일 컴파일

$ wasm-pack build

약 100바이트의 글루 코드가 포함된 7.6KB wasm 모듈을 생성합니다 (모두 gzip 후).

AssemblyScript

AssemblyScript는 TypeScript-WebAssembly 컴파일러를 목표로 하는 비교적 새로운 프로젝트입니다. 그러나 TypeScript만 사용하지는 않는다는 점에 유의해야 합니다. AssemblyScript는 TypeScript와 동일한 구문을 사용하지만 표준 라이브러리를 자체적으로 바꿉니다. WebAssembly의 표준 라이브러리는 WebAssembly의 기능을 모델링합니다. 즉, WebAssembly에 있는 TypeScript를 그냥 컴파일할 수는 없지만 WebAssembly를 작성하기 위해 새 프로그래밍 언어를 배울 필요가 없습니다.

    for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
      for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
        let in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
        store<u32>(offset + i * 4 + 4, load<u32>(in_idx * 4 + 4));
        i += 1;
      }
    }

rotate() 함수의 작은 유형 노출 영역을 고려할 때 이 코드를 AssemblyScript로 포팅하기가 상당히 쉬웠습니다. AssemblyScript에서는 원시 메모리 액세스를 위해 load<T>(ptr: usize) 및 store<T>(ptr: usize, value: T) 함수를 제공합니다. Google AssemblyScript 파일을 컴파일하려면 AssemblyScript/assemblyscript npm 패키지만 설치하고

$ asc rotate.ts -b assemblyscript.wasm --validate -O3

AssemblyScript는 약 300바이트의 wasm 모듈을 제공하며 글루 코드는 없습니다. 이 모듈은 단순히 기본적인 WebAssembly API로 작동합니다.

WebAssembly 포렌식

Rust의 7.6KB는 다른 2개의 언어에 비해 놀라울 정도로 큽니다. WebAssembly 생태계에는 만들어진 언어에 관계없이 WebAssembly 파일을 분석하고 상황을 안내하며 상황을 개선하는 데 도움이 되는 몇 가지 도구가 있습니다.

트위기

Twiggy는 WebAssembly 모듈에서 유용한 데이터를 많이 추출하는 Rust WebAssembly팀의 또 다른 도구입니다. 이 도구는 Rust 전용이 아니며, 이를 사용하면 모듈의 호출 그래프와 같은 항목을 검사하고 사용되지 않거나 불필요한 섹션을 확인하며 모듈의 총 파일 크기에 기여하는 섹션을 파악할 수 있습니다. 후자는 Twiggy의 top 명령어로 실행할 수 있습니다.

$ twiggy top rotate_bg.wasm

이 경우 파일 크기 대부분이 할당자에서 비롯된 것을 확인할 수 있습니다. 코드가 동적 할당을 사용하지 않기 때문에 놀랍습니다. 또 다른 중요한 기여 요소는 '함수 이름' 하위 섹션입니다.

Wasm-스트립

wasm-strip는 WebAssembly 바이너리 툴킷(wabt)에 포함된 도구입니다. 여기에는 WebAssembly 모듈을 검사하고 조작할 수 있는 몇 가지 도구가 포함되어 있습니다. wasm2wat는 바이너리 wasm 모듈을 사람이 읽을 수 있는 형식으로 변환하는 디스어셈블러입니다. Wabt에는 사람이 읽을 수 있는 형식을 바이너리 wasm 모듈로 다시 변환할 수 있는 wat2wasm도 포함되어 있습니다. WebAssembly 파일을 검사하는 데 이 두 가지 보완 도구를 사용했지만 wasm-strip가 가장 유용했습니다. wasm-strip는 WebAssembly 모듈에서 불필요한 섹션과 메타데이터를 삭제합니다.

$ wasm-strip rotate_bg.wasm

이렇게 하면 Rust 모듈의 파일 크기가 7.5KB에서 6.6KB (gzip 후)로 줄어듭니다.

wasm-opt

wasm-opt는 Binaryen의 도구입니다. WebAssembly 모듈을 가져와서 바이트 코드만을 기준으로 크기와 성능을 최적화하려고 시도합니다. Emscripten과 같은 일부 도구는 이미 이 도구를 실행하고 있지만 다른 도구는 그렇지 않습니다. 일반적으로 이러한 도구를 사용하여 추가 바이트를 몇 가지 저장해 보는 것이 좋습니다.

wasm-opt -O3 -o rotate_bg_opt.wasm rotate_bg.wasm

wasm-opt를 사용하면 몇 바이트를 더 줄여 gzip 뒤 총 6.2KB를 남길 수 있습니다.

#![no_std]

약간의 상담과 연구 후 Rust의 표준 라이브러리를 사용하지 않고 #![no_std] 기능을 사용하여 Rust 코드를 다시 작성했습니다. 이렇게 하면 동적 메모리 할당이 모두 사용 중지되고 모듈에서 할당자 코드가 삭제됩니다. 이 Rust 파일 컴파일

$ rustc --target=wasm32-unknown-unknown -C opt-level=3 -o rust.wasm rotate.rs

wasm-opt, wasm-strip 및 gzip 이후에 1.6KB wasm 모듈을 생성했습니다. 여전히 C 및 AssemblyScript에서 생성된 모듈보다 크지만 경량으로 간주할 만큼 충분히 작습니다.

참고: Twiggy에 따르면 파일 크기의 주요 요소는 core::fmt입니다. 이는 데이터를 문자열로 변환하는 모듈 (예: C의 printf())입니다. 이는 사람이 읽을 수 있는 예외 메시지를 생성할 때 예외를 트리거할 수 있는 코드 경로에서 사용합니다. Rust의 WebAssembly팀은 이 사실을 알고 있으며 개선을 위해 적극적으로 노력하고 있습니다.

성능

파일 크기만을 기준으로 결론을 내리기 전에, 우리는 파일 크기가 아니라 성능을 최적화하기 위해 이 여정을 계속했습니다. 그렇다면 성능을 어떻게 측정했고 그 결과는 어땠을까요?

벤치마킹 방법

WebAssembly는 낮은 수준의 바이트 코드 형식이지만 호스트 관련 기계어 코드를 생성하려면 컴파일러를 통해 전송해야 합니다. JavaScript와 마찬가지로 컴파일러는 여러 단계에서 작동합니다. 간단히 말해 첫 번째 단계는 컴파일은 훨씬 빠르지만 코드가 더 느린 경향이 있습니다. 모듈이 실행되기 시작하면 브라우저는 자주 사용되는 부분을 관찰하고 최적화는 더 느리지만 속도가 느린 컴파일러를 통해 전송합니다.

이미지 회전 코드가 한 번 또는 두 번 사용된다는 점에서 사용 사례가 흥미롭습니다. 따라서 대부분의 경우 최적화 컴파일러의 이점을 얻지 못합니다. 이는 벤치마킹 시 염두에 두어야 하는 사항입니다. WebAssembly 모듈을 루프로 10,000회 실행하면 현실적인 결과를 얻을 수 없습니다. 현실적인 수치를 얻으려면 모듈을 한 번 실행하고 이 단일 실행의 숫자를 기반으로 결정을 내려야 합니다.

참고: 페이지를 새로고침하고 모듈을 한 번 실행하고 이 프로세스를 여러 번 실행하는 이 프로세스를 자동화하는 것이 이상적입니다. Google은 이러한 평균 수치를 기반으로 정보에 입각한 결정을 내리기에 몇 번의 수동 실행으로 충분하다고 판단했습니다.

실적 비교

이 두 그래프는 동일한 데이터에 대한 서로 다른 뷰입니다. 첫 번째 그래프에서는 브라우저별로 비교하고, 두 번째 그래프에서는 사용된 언어별로 비교합니다. 저는 로그 시간 척도를 선택했습니다. 또한 동일한 머신에서 실행할 수 없는 한 개의 브라우저를 제외하고 모든 벤치마크가 동일한 16메가픽셀 테스트 이미지와 동일한 호스트 머신을 사용해야 합니다.

이 그래프를 너무 많이 분석하지 않아도 원래 성능 문제를 해결했다는 것을 알 수 있습니다. 모든 WebAssembly 모듈은 500ms 이내로 실행됩니다. 이를 통해 WebAssembly가 예측 가능한 성능을 제공합니다. 어떤 언어를 선택하든 브라우저와 언어 간 차이가 거의 없습니다. 정확하게 말하면 모든 브라우저에서 JavaScript의 표준 편차는 약 400ms이지만 모든 브라우저에서 모든 WebAssembly 모듈의 표준 편차는 80ms입니다.

난이도

또 다른 측정항목은 WebAssembly 모듈을 만들고 일반에 통합하는 데 들인 노력의 정도입니다. 숫자 값을 할당하는 것은 어렵기 때문에 그래프를 만들지는 않겠지만 필자는 몇 가지 주목해야 할 사항이 있습니다.

AssemblyScript는 원활했습니다. TypeScript를 사용하여 WebAssembly를 작성할 수 있어 동료들이 코드 검토를 매우 쉽게 할 수 있을 뿐만 아니라 매우 작으며 적절한 성능으로 글루가 없는 WebAssembly 모듈도 생성됩니다. Prettier 및 tslint와 같은 TypeScript 생태계의 도구가 잘 작동할 가능성이 높습니다.

Rust를 wasm-pack와 함께 사용하는 것도 매우 편리하지만, 더 큰 규모의 WebAssembly 프로젝트에서는 결합이 더 뛰어나고 메모리 관리가 필요합니다. 경쟁력 있는 파일 크기를 달성하기 위해서는 행복 경로에서 약간 벗어날 필요가 있었습니다.

C 및 Emscripten은 아주 작고 성능이 우수한 WebAssembly 모듈을 즉시 만들었지만, 글루 코드로 전환하여 필요한 수준으로 줄일 용기가 없었다면 총 크기 (WebAssembly 모듈 + 글루 코드)가 상당히 커졌습니다.

결론

따라서 JS 핫 경로가 있고 WebAssembly와 더 빠르고 일관성 있는 경로를 만들려면 어떤 언어를 사용해야 합니다. 성능에 관한 질문이 늘 그렇듯이 답은 상황에 따라 다릅니다 그래서 우리는 무엇을 배송했을까요?

참고: 두 축 모두 대수이고 x축은 2,000바이트이고 y축은 최대 10초입니다.

사용한 여러 언어의 모듈 크기 / 성능의 절충점을 비교해 볼 때 최선의 선택은 C 또는 AssemblyScript인 것으로 보입니다. Rust를 제공하기로 결정했습니다. 이 결정에는 여러 가지 이유가 있습니다. 지금까지 Squoosh에서 제공된 모든 코덱이 Emscripten을 사용하여 컴파일되었습니다. WebAssembly 생태계에 대한 지식을 넓히고 프로덕션에서 다른 언어를 사용하고 싶었습니다. AssemblyScript는 강력한 대안이지만 프로젝트가 비교적 최근에 개발되었으며 컴파일러가 Rust 컴파일러만큼 성숙하지 못합니다.

분산 그래프에서 Rust와 다른 언어 간의 파일 크기 차이가 상당히 클 것 같지만 실제로는 그렇게 큰 문제가 아닙니다. 2G를 통해 500B 또는 1.6KB를 로드하는 데 걸리는 시간은 1/10초도 채 걸리지 않습니다. Rust로 조만간 모듈 크기 측면에서 이러한 격차를 줄일 수 있을 것입니다.

런타임 성능 측면에서 Rust는 여러 브라우저에서 AssemblyScript보다 평균이 더 빠릅니다. 특히 규모가 큰 프로젝트에서 Rust는 수동으로 코드를 최적화하지 않고도 더 빠른 코드를 생성할 가능성이 더 높습니다. 그렇다고 해서 가장 익숙한 것을 사용하지 못하는 것은 아닙니다.

다시 말해 AssemblyScript는 훌륭한 발견입니다. 이를 통해 웹 개발자는 새 언어를 배우지 않고도 WebAssembly 모듈을 생성할 수 있습니다. AssemblyScript팀은 빠르게 응답하여 도구 모음을 개선하기 위해 적극적으로 노력하고 있습니다. 앞으로 AssemblyScript를 항상 지켜볼 것입니다.

업데이트: Rust

이 문서를 게시한 후 Rust팀의 닉 피츠제럴드는 파일 크기 최적화에 관한 섹션이 포함된 훌륭한 Rust Wasm 서적을 언급했습니다. 이 안내 (특히 링크 시간 최적화 및 수동 패닉 처리 사용 설정)에 따라 '일반' Rust 코드를 작성하고 파일 크기를 늘리지 않고도 Cargo (Rust의 npm)를 사용할 수 있었습니다. Rust 모듈은 gzip 후 370B로 끝납니다. 자세한 내용은 Squoosh에 공개한 PR을 참고하세요.

이 여정에 도움을 주신 애슐리 윌리엄스, 스티브 클래브니크, 닉 피츠제럴드, 맥스 그레이에게 특히 감사의 인사를 전합니다.