Asm.js와 작별 인사

Source: Hacker News

Details

Axe-time, sword-time, shields are sundered,
Wind-time, wolf-time, ere the world falls.
– Völuspá, Poetic Edda

Firefox 148부터 SpiderMonkey의 asm.js 최적화가 기본적으로 비활성화되며, 향후 릴리스에서 코드를 완전히 제거할 계획입니다.

asm.js를 사용하는 사이트를 운영하고 있다면, 아무 문제도 발생하지 않습니다. asm.js는 일반 JavaScript의 부분 집합에 불과하므로, 코드는 다른 스크립트와 마찬가지로 우리의 일반 JIT를 통해 실행됩니다. 다만, WebAssembly로 다시 컴파일하면 실행 속도가 빨라지고 바이너리 크기도 작아집니다.

History

asm.js는 NaCl 및 PNaCl이 제기한 “웹에서 네이티브 속도로 코드를 실행하려면 어떻게 해야 할까?”라는 질문에 대한 Mozilla의 답변이었습니다.

아이디어는 간단했습니다: 엔진이 실시간으로 인식하고 네이티브 코드로 컴파일할 수 있는 엄격하고 정적 타입이 지정된 JavaScript 부분 집합을 선택하는 것이었습니다. 이를 통해 NaCl/PNaCl과 유사한 성능을 얻으면서도 코드를 웹 콘텐츠 안에 두고 웹 API를 사용할 수 있었습니다(별도의 샌드박스, IPC, 혹은 대체 API 없이).

asm.js는 2013년 Firefox 22에 처음 도입되었으며 큰 성공을 거두었습니다. Unity와 Unreal 같은 프로젝트가 처음으로 C/C++ 코드베이스를 웹에 올릴 수 있게 되었고, 표준 웹 기술만으로 구현되었습니다. Epic Citadel 데모는 단 4일 만에 웹으로 포팅되었습니다. 이는 중요한 성과였으며, 최초 asm.js 팀에게는 소중한 기억으로 남아 있습니다.

asm.js는 웹 기술만으로도 거의 네이티브에 가까운 속도로 코드를 실행할 수 있음을 증명했습니다. 이는 이후 몇 년 뒤 WebAssembly가 등장하는 계기가 되었으며, WebAssembly는 Firefox 52에 포함되었습니다. asm.js가 없었다면 우리는 WebAssembly를 갖지 못했을지도 모릅니다.

Why now?

그렇다면 왜 asm.js를 끄는 걸까요? WebAssembly가 성공을 거두었고, asm.js 사용량은 대부분 이전되었습니다. asm.js 경로를 WebAssembly와 함께 유지하는 것은 유지 보수 비용을 늘리고 VM의 공격 표면을 확대합니다.

asm.js 콘텐츠를 제공하고 있다면, WebAssembly로 다시 컴파일하는 것을 고려해 주세요! 우리의 WebAssembly 파이프라인은 asm.js 파이프라인보다 훨씬 앞선 상태이며, 더 빠른 실행과 더 작은 바이너리를 제공할 것입니다.

Ragnarök

asm.js 컴파일러는 OdinMonkey라고 불립니다. 오래전 예언대로 OdinMonkey는 운명적인 파멸을 맞이해야 합니다. 버그 Ragnarök은 “OdinMonkey의 황혼”을 추적하고 있습니다.

하지만 모든 것이 사라진 것은 아닙니다. OdinMonkey에게서 탄생한 BaldrMonkey, 우리의 WebAssembly 최적화 컴파일러가 있기 때문입니다. OdinMonkey는 늑대 Fenrir에게 삼켜질 수도 있지만, BaldrMonkey는 부활한 세계를 RabaldrMonkey(“소란”)와 함께 다스릴 것입니다. RabaldrMonkey는 우리의 WebAssembly 기본 컴파일러입니다.

이번 Odin의 날(수요일)에 우리는 OdinMonkey에게 13년간의 서비스에 감사를 표합니다. Skål!

Then fields unsowed bear ripened fruit,
all ills grow better, and Baldr comes back;
Baldr and Hoth dwell in Hropt’s battle‑hall.
– Völuspá, Poetic Edda