Turbocharging Client-Side Processing: Leveraging asm.js
summary
Claims that JavaScript can run near-native speed by compiling hot, numeric code into asm.js and using M scripton to port C/C++ libraries. Performance lands roughly within 2x of native; Unreal Engine 3 becomes ~36 MB -> 17 MB gzip of JS and initial compile time drops from ~30s to ~5s, then to milliseconds with disk-cached async compilation. asm.js uses a single ArrayBuffer heap (no GC), requires manual memory copies, works well on workers, and lets existing libs like OpenCV, Box2D and codecs run inside regular web apps.
AI-written summary · about
chapters (32)
- 0:00Introduction
- 2:30asmjs
- 7:35how to use asmjs
- 12:22how to use existing libraries
- 13:49Script imports
- 14:38Getting data into asmjs
- 17:24Garbage collection
- 18:28Process Image Data
- 19:05Libraries
- 19:41Worker Threads
- 20:27WebSockets
- 23:23Asynchronous Script Loading
- 27:15Image Processing
- 29:05Data Analysis
- 30:17Face Login
- 31:58ImageVideo Codecs
- 34:16Mobile Web Apps
- 34:40Performance
- 35:12Mobile Performance
- 35:28Prerequisites
- 36:08Why use Lua
- 37:02Resources
- 37:34Questions
- 38:11Confidentiality
- 39:15Other demos
- 40:26Luke Wagner
- 41:19asmjs runtime
- 42:11asmjs script
- 43:19asmjs module
- 43:54asmjs type information
- 44:39more questions
- 45:09Firefox WebGL
related talks
30mNative Speed on the Web: JavaScript and asm.js
59mEmscripten and asm.js: C++'s role in the modern web
33mHigh-Performance WebGL Apps with LLJS and asm.js
27mToward a language-neutral browser VM
39mHow much performance can you get out of Javascript?
46mHow much performance can you get out of JavaScript?
33m"Is WebAssembly the killer of JavaScript"
13mTurbocharged Javascript with hand crafted WASM