Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Intro to WebAssembly
Ähnlich wie Intro to WebAssembly (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Intro to WebAssembly
- 1. An Intro toAn Intro to WebAssemblyWebAssembly Daniel BuddenDaniel Budden @danlbudden@danlbudden
- 2. WebAssemblyWebAssembly • The next evolutionary step of asm.js &The next evolutionary step of asm.js & EmscriptenEmscripten • Announced 17Announced 17thth June 2015June 2015 • Being developed by a W3C Community GroupBeing developed by a W3C Community Group involving Chrome, Firefox, Safari and Edgeinvolving Chrome, Firefox, Safari and Edge developersdevelopers
- 3. What is it?What is it? • It's not JavaScriptIt's not JavaScript • A new Abstract Syntax Tree format with aA new Abstract Syntax Tree format with a binary encodingbinary encoding • Designed to run in multiple environments:Designed to run in multiple environments: browser, node.js, and elsewherebrowser, node.js, and elsewhere
- 4. Benefits over asm.jsBenefits over asm.js • Parsing the asm.js code becomes the bottleneckParsing the asm.js code becomes the bottleneck • Binary encoding benefits parsing and transmissionBinary encoding benefits parsing and transmission • WebAssembly will diverge from JavaScript and asm.js, e.g:WebAssembly will diverge from JavaScript and asm.js, e.g: • Shared memory multithreadingShared memory multithreading • call/cccall/cc
- 5. Is it trying to replace JS?Is it trying to replace JS? • The aim is provide a new tool that complimentsThe aim is provide a new tool that compliments JavaScriptJavaScript • Also to remove the burden of JavaScript as aAlso to remove the burden of JavaScript as a cross-compilation target.cross-compilation target.
- 6. Potential ApplicationsPotential Applications • Some potential applications:Some potential applications: • Games,Games, • Audio/Video/Virtual Reality,Audio/Video/Virtual Reality, • Peer-to-peer, e.g. collaborative editing,Peer-to-peer, e.g. collaborative editing, • Encryption,Encryption, • CAD software,CAD software, • Scientific simulation and visualisationScientific simulation and visualisation • Machine LearningMachine Learning
- 7. Writing WebAssemblyWriting WebAssembly • WebAssembly will have a text formatWebAssembly will have a text format • Emscripten will have an option to produceEmscripten will have an option to produce .wasm file instead of asm.js.wasm file instead of asm.js • Other cross-compilers will be developed forOther cross-compilers will be developed for languages other than C/C++languages other than C/C++
- 8. RoadmapRoadmap • Develop polyfillDevelop polyfill • Implement MVPImplement MVP • Post-MVP extensionPost-MVP extension • Diverge from JS/asm.jsDiverge from JS/asm.js
- 9. PolyfillPolyfill • WebAssembly will be:WebAssembly will be: • Backwards compatibleBackwards compatible • No versioningNo versioning • Feature detectionFeature detection
- 10. Prototype PolyfillPrototype Polyfill .wasm file asm.js code Polyfill Execute Promise Web Worker Resolve
- 11. Minimum Viable ProductMinimum Viable Product • Define the binary format, AST structure and textDefine the binary format, AST structure and text formatformat • Support C and C++Support C and C++ • Roughly the same functionality as asm.jsRoughly the same functionality as asm.js
- 12. Post-MVP ExtensionPost-MVP Extension • Extend the MVP implementation by adding:Extend the MVP implementation by adding: • ThreadsThreads • Short SIMDShort SIMD • Zero-cost ExceptionsZero-cost Exceptions
- 13. Future FeaturesFuture Features • Support for other languages:Support for other languages: • E.g. Haskell, Go, Rust, C#E.g. Haskell, Go, Rust, C# • Long SIMDLong SIMD • Dynamic Linking of WebAssembly ModulesDynamic Linking of WebAssembly Modules • Multithreading with shared memoryMultithreading with shared memory • Garbage CollectionGarbage Collection • Integration with DOM and Web APIsIntegration with DOM and Web APIs
- 15. Further ReadingFurther Reading • JSZap - Benefits of compressed AST:JSZap - Benefits of compressed AST: http://research.microsoft.com/apps/pubs/http://research.microsoft.com/apps/pubs/ ?id=120832?id=120832
Hinweis der Redaktion
- My name is Daniel Budden, and tonight I'm going to give an introduction to WebAssembly. This is a very new technology and so it under heavy development but hopefully this presentation will give an overview of what WebAssembly is, and what we can expect from it in the future.
- WebAssembly is the next stage in the cross-compile to browsers, story that began with asm.js and Emscripten. For those who aren't aware of these two technologies, asm.js is a statically typed subset of JavaScript which allows browser engines to generate highly optimised native code compared to normal JavaScript. Emscripten is the compiler that cross-compiles C and C++ code to asm.js WebAssembly was announced recently, and is an initiative involving key developers from all major browsers to create a standard format that will serve as a cross-compile target for running in browsers.
- First of all WebAssembly is not JavaScript, it defines a completely new format. It's also not bytecode which a lot of people are claiming that it is. WebAssembly is an abstract syntax tree format with a binary encoding, that can be compiled to native code in browser engines. Using a binary format has a number of advantages, the main ones being that it can be more efficiently compressed for transmission to the browser, and it is much more quickly decoded that source code is parsed by the compiler.
- The last point is particularly important, because although asm.js is fast to execute the initial parsing of the source code to compile becomes the bottleneck in the system. This is especially important for mobile devices where parsing large amounts of asmjs can easily take up to 20-40 secs just for parsing. Early experiments show decoding WebAssembly is about 23 times faster than parsing asmjs. The output of Emscripten, for those who have not seen it, is highly bloated. You can see this for yourself by compiling a 5 line hello world example in C, which turns into 10,000 lines of asmjs. WebAssembly won't require all of this extra bloat. Also asm.js is limited by the capabilities of the JS language and its syntax. Creating a new standard allows features to be added that will improve performance but would be difficult to add to JS or would have a negative impact. For example features like shared memory threading, or call with concurrent continuation, which have the potential to add security issues are likely to be added to WebAssembly and left out of JS
- The question that everyone started asking when WebAssembly was first announced was 'is WASM trying to replace JavaScript?' No WebAssembly isn't trying to replace JS, and aims to be complimentary to JS. Having a new format for cross-compilation in browsers removes the burden on JavaScript to support cross-compilation. There were two new JS math functions add to JS in ES2015 that were added to specifically support asmjs.
- There have already been some really impressive applications developed and cross-compiled with asmjs, such as physics engines, video decoders and even porting the latest Unreal game engine, Unreal 4. WebAssembly will extend continue to push the boundaries of what applications are possible on the web. Some ways that we will be able to use WebAssembly will include: 1. Entire code base in Web Assembly. 2. Main frame in Web Assembly, but the UI is in JavaScript / HTML. 3. JavaScript/HTML application with embedded WebAssembly libraries eg to offload compute-oriented tasks.
- WebAssembly will have a text format, and that text format will be isomorphic to the binary format. This means dev tools in browsers will be able to show the WebAssembly code in a human readable format. It will also provide opportunity for writing, optimising or debugging WASM by hand. In the near future we will be able produce WASMin a similar way to asm.js, that is compiling C and C++ code to WASM using emscripten. And then as support is added for other languages new compilers will be developed that will cross-compile to WASM.
- The group behind WebAssembly have already begun work, and have set out a roadmap for the implementation of the standard. The first two steps, developing a polyfill and developing the Minimum Viable Product are both already underway. After the implementation of the MVP is complete there will be an additional post MVP extension and then WASM will diverge from asmjs
- Similar to JavaScript, the aim of WebAssembly is to have a backwards compatible standard with no versioning, and abilities like features detection. To facilitate this goal there will be a WebAssembly polyfill that can be used to add WebAssembly support to browsers that do not implement it.
- The prototype polyfill uses a Web Worker which fetches the WebAssembly file, and decodes the WebAssembly into asmjs. The worker inserts the asm.js into the page and resolves the promise that is returned by the polyfill with the decoded asm.js module. The decoder used to decode and transform the WebAssembly has been compiled from C++ using emscripten and so provides fast processing. This polyfill allows us to run the WebAssembly format and benefit from the higher compression rates until native support exists in browsers. It also allows testing the WebAssembly format and measuring its performance. How do we get .wasm file? At the moment the prototype polyfill provides a tool to pack asmjs code into the a prototype version of WebAssembly format for use with the prototype polyfill.
- The short term goals of the WebAssembly group is to get a minimum viable product implemented as standard across all modern browsers. The aim of the MVP is to: Define the binary format, AST structure and text format. Writing of the specifications for these is underway and they currently under discussion. The MVP will just target cross-compilation from C and C++ And it will aim to support roughly the same functionality as asm.js The group is optimistic that the first implementations of the MVP may make it into nightly builds of browsers by the end of the year.
- There are some features that are seen as essential but are not going to be included in the MVP because an efficient polyfill for these features cannot be developed. These features such as threads, short Single Instruction Multiple Data and zero-cost exceptions will all have feature tests so that developers can fall back to other implementations if they are not available in browsers.
- Following the MVP and post-MVP implementations the goal is to implement a range of features to extend the capabilities of WebAssembly beyond that of JS. Support for other programming languages, inluding these ones listed as potential candidates Support for long SIMD with gather/scatter functionality Dynamic linking of WASM modules including support for distribution across Content Delivery Networks Multithreading with shared memory Garbage collection to support compilation from language which feature garbage collection Then also integration with the browsers DOM and other Web APIs. Initially it is likely that WASM will access Web APIs via JS, but this will be temporary until access is added directly from WASM code.
- I'm going to give a quick demo of the prototype polyfill. I want to forewarn that this probably won't be super impressive but hopefully it shows that there is something that you can start experimenting with.
- If you are interested in some of the research behind using compressed AST structures for the web platform, there is a research paper by Microsoft which you can find by googling JSZap.
- If you are interested in getting involved with WebAssembly you can find the specifications, discussion and a lot more detail in the Github repos for the WebAssembly organisation. There is also a W3C community group for WebAssembly which you can join to get involved.
- Hopefully that gives a good insight into the reason behind the development of WASM and idea of what it will bring to the web in the future. Any questions?