[논문 리뷰] Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

Abhinav Jangda, Bobby Powers외 2명|arXiv (Cornell University)|2019. 01. 25.

Security and Verification in Computing참고 문헌 19인용 수 47

한 줄 요약

이 논문은 Browsix-Wasm 및 Browsix-SPEC를 구축하여 수정 없이 Unix/WebAssembly 앱을 브라우저에서 실행하고, 대규모 SPEC CPU 벤치마크 평가를 수행하여 WebAssembly가 Chrome에서 네이티브보다 1.55배 느리고 Firefox에서 1.45배 느리며, 상당한 격차와 여러 효율성 이슈를 확인했다.

ABSTRACT

All major web browsers now support WebAssembly, a low-level bytecode intended to serve as a compilation target for code written in languages like C and C++. A key goal of WebAssembly is performance parity with native code; previous work reports near parity, with many applications compiled to WebAssembly running on average 10% slower than native code. However, this evaluation was limited to a suite of scientific kernels, each consisting of roughly 100 lines of code. Running more substantial applications was not possible because compiling code to WebAssembly is only part of the puzzle: standard Unix APIs are not available in the web browser environment. To address this challenge, we build Browsix-Wasm, a significant extension to Browsix that, for the first time, makes it possible to run unmodified WebAssembly-compiled Unix applications directly inside the browser. We then use Browsix-Wasm to conduct the first large-scale evaluation of the performance of WebAssembly vs. native. Across the SPEC CPU suite of benchmarks, we find a substantial performance gap: applications compiled to WebAssembly run slower by an average of 45% (Firefox) to 55% (Chrome), with peak slowdowns of 2.08x (Firefox) and 2.5x (Chrome). We identify the causes of this performance degradation, some of which are due to missing optimizations and code generation issues, while others are inherent to the WebAssembly platform.

연구 동기 및 목표

• 브라우저에서 수정 없이 Unix 애플리케이션을 사용한 WebAssembly의 대규모, 공정 벤치마킹을 동기 부여하고 가능하게 한다.
• 브라우즈윅-왐(Browsix-Wasm)을 개발하여 WebAssembly로 컴파일된 Unix 프로그램을 브라우저에서 최소한의 오버헤드로 실행한다.
• 브라우즈윅-스펙(Browsix-SPEC)을 만들어 SPEC CPU2006/2017 및 PolyBenchC 벤치마킹을 브라우저에서 자동화하고 상세한 타이밍 및 하드웨어 카운터 데이터를 수집한다.
• WebAssembly를 네이티브와 정량적으로 비교하고 성능 격차의 근본 원인을 분석한다.
• 구현자에게 WebAssembly 성능 격차를 줄이기 위한 실행 가능한 지침을 제공한다.

제안 방법

• 수정되지 않은 WebAssembly Unix 프로그램을 브라우저에서 최적화된 커널 통합으로 실행하기 위해 Browsix를 Browsix-Wasm으로 확장한다.
• 브라우즈윅-스펙(Browsix-SPEC)을 개발하여 브라우저 인스턴스, 벤치마크 자원 및 SPEC와 PolyBenchC 브라우저 내 벤치마크의 퍼포먼스 카운터 수집을 조정한다.
• 벤치마크를 네이티브(Clang)와 WebAssembly(Browsix-Wasm)로 컴파일하고 브라우저 코드를 수정하지 않으면서 Chrome과 Firefox에서 측정한다.
• 성능 카운터를 사용하여 WebAssembly 느려짐의 원인을 분석하고, 레지스터 압력, 명령어 구성, 분기 동작 등을 포함한다.
• asm.js 대비 WebAssembly의 상대적 개선을 정량화하고 asm.js 대비 속도 향상 주장에 대한 타당성을 검증한다.
• WebAssembly 백엔드 최적화를 안내하기 위한 실행 시간 매트릭스와 카운터 기반 설명을 제공한다.

실험 결과

연구 질문

• RQ1 브라우저에서 WebAssembly의 성능이 SPEC CPU2006/2017 및 PolyBenchC와 같은 대규모 실제 벤치마크에서 네이티브 코드와 어떻게 비교되는가?
• RQ2 관찰된 WebAssembly 느려짐의 지배적 기여 요소는 무엇인가(예: 레지스터 할당, 명령 수, 분기, 메모리 동작)?
• RQ3 Browsix-Wasm/Browsix-SPEC 인프라 자체의 오버헤드는 어느 정도이며, 성능 결론의 타당성을 훼손하는가?
• RQ4 WebAssembly가 Chrome과 Firefox에서 서로 계속 asm.js보다 앞서는가, 그리고 그 차이는 어느 정도인가?
• RQ5 WebAssembly-Native 성능 격차를 줄이기 위해 구현자들에게 어떤 실용적 지침을 제공할 수 있는가?

주요 결과

Benchmark	Native	Google Chrome	Mozilla Firefox
401.bzip2	370 ± 0.6	864 ± 6.4	730 ± 1.3
429.mcf	221 ± 0.1	180 ± 0.9	184 ± 0.6
433.milc	375 ± 2.6	369 ± 0.5	378 ± 0.6
444.namd	271 ± 0.8	369 ± 9.1	373 ± 1.8
445.gobmk	352 ± 2.1	537 ± 0.8	549 ± 3.3
450.soplex	179 ± 3.7	265 ± 1.2	238 ± 0.5
453.povray	110 ± 1.9	275 ± 1.3	229 ± 1.5
458.sjeng	358 ± 1.4	602 ± 2.5	580 ± 2.0
462.libquantum	330 ± 0.8	444 ± 0.2	385 ± 0.8
464.h264ref	389 ± 0.7	807 ± 11.0	733 ± 2.4
470.lbm	209 ± 1.1	248 ± 0.3	249 ± 0.5
473.astar	299 ± 0.5	474 ± 3.5	408 ± 1.0
482.sphinx3	381 ± 7.1	834 ± 1.8	713 ± 3.6
641.leela_s	466 ± 2.7	825 ± 4.6	717 ± 1.2
644.nab_s	2476 ± 11	3639 ± 5.6	3829 ± 6.7

• Chrome에서 WebAssembly가 네이티브보다 평균 1.55배 느리고 Firefox에서 1.45배 느리며, SPEC 벤치마크에서 최고 느려짐은 Chrome에서 2.5x, Firefox에서 2.08x이다.
• Chrome에서 15개 SPEC 벤치마크 중 7개는 네이티브에 1.5x 이내로 도달하고, Firefox에서도 7개가 그 범위에 들어간다.
• Chrome에서 WebAssembly는 asm.js 대비 평균 1.54x의 속도 향상, Firefox에서는 1.39x의 속도 향상을 보이며, 최적의 WebAssembly 대 최적의 asm.js의 경우 약 1.3x의 속도 향상이 나타난다.
• 네이티브에 비해 WebAssembly는 로드/저장 증가(Chrome: 로드 2.02x, 저장 2.30x; Firefox: 로드 1.92x, 저장 2.16x), 더 많은 분기 및 더 많은 명령 캐시 미스 등으로 실행이 느려진다.
• 행렬 곱셈에서 WebAssembly는 네이티브보다 2x–3.4x 느려지며, 코드 생성 및 레지스터 사용의 비효율성을 강조한다.
• 퍼포먼스 카운터 분석은 증가된 레지스터 압력, 열악한 레지스터 할당(Chrome/Firefox는 Clang의 그리디 그래프-컬러링 방식이 아님), x86 어드레싱 모드의 활용 저하를 주요 저하 요인으로 밝혀낸다.