[HN Gopher] WebAssembly 2.0 First Working Draft
___________________________________________________________________
WebAssembly 2.0 First Working Draft
Author : syrusakbary
Score : 125 points
Date : 2022-04-19 17:36 UTC (5 hours ago)
(HTM) web link (www.w3.org)
(TXT) w3m dump (www.w3.org)
| The_rationalist wrote:
| crudbug wrote:
| No DOM API ?
|
| No GC API ?
| TheCycoONE wrote:
| It appears to include the currently standardized extensions. GC
| is a proposal in phase 2, and I'm not even aware or a proposal
| for DOM access yet but it would require several other proposals
| to go through first.
| pwdisswordfish9 wrote:
| Are there any actual incompatibilities or is the version number
| just a marketing gimmick?
| eatonphil wrote:
| There isn't a law saying all legit software must use semver. :)
|
| Python makes breaking changes whenever they want in minor
| version changes.
| singularity2001 wrote:
| Only forward incompatibilities, that is: Wasm 1.0 engines can't
| handle 2.0 opcodes etc
| AgentME wrote:
| The web tries very hard to avoid backwards incompatibilities. I
| don't expect the WASM standard to ever directly get any
| backwards incompatibilities, unless they're opt-in (like how
| using JS modules stops you from using with-statements).
| dmkolobov wrote:
| Looking at this it seems tail-calls are still not part of the
| spec? Has there been any news regarding return_call?
|
| Would be cool to see it for more efficient implementation of
| functional languages.
| titzer wrote:
| Tail calls are only blocked on a second production engine
| implementing them. V8 has been done with tail calls for more
| than 3 years.
| slaymaker1907 wrote:
| There is some really exciting stuff
| "https://github.com/WebAssembly/proposals" I'm particularly
| excited about stack switching.
| yurymik wrote:
| I still can't find any mentions of external memory mapping
| without copying it into the heap. _Very_ disappointing as it
| makes yet another version of WASM completely unusable for many
| high-performance applications :(
| keithwinstein wrote:
| The multi-memory proposal is your best bet for this:
| https://github.com/WebAssembly/multi-memory
|
| It's supported in Wasmtime, WAVM, and WABT and wasm2c, and not
| much else so far (https://webassembly.org/roadmap/).
| miolini wrote:
| Looking for memory shrink instruction.
| eatonphil wrote:
| Is WebAssembly faster than JavaScript? Any good benchmarks you
| can link me to?
|
| I found one of Daniel Lemire's [0] from 2018 which seems to
| suggest it's basically not much faster. 2018 is long enough away
| from now though that this post may not be relevant. I don't know.
|
| It's odd to me how WebAssembly seemed to be started as a way to
| get performance improvements by working with cached instructions
| (and maybe also explicit memory management and integer types) but
| I don't hear much about performance these days.
|
| Maybe I'm not paying attention.
|
| Instead I hear more about it as a universal platform or a way you
| can run C/C++ code in the browser (like tree-sitter and CPython
| and Ruby, etc.). Or about people using it in edge compute or as
| the engine for smart contracts. In those ways you could just as
| well have used the JVM though.
|
| [0] https://lemire.me/blog/2018/10/23/is-webassembly-faster-
| than...
| josephg wrote:
| The big thing that makes javascript slow (that the optimizer
| can't really fix) is complex data structures.
|
| For example, if you want to implement an editable string, you
| have to do so using an array of smaller strings and hope the
| optimizer can figure it out, or slice() and re-join a single
| "immutable" string. Either way, your javascript code will be
| slower than the C/rust equivalent because the language is less
| expressive. Javascript has the same problem with b-trees, skip
| lists, ropes, gap buffers, AABB trees, and so on. You can
| implement all of this stuff in javascript - you just end up
| with much more memory indirection than you want. And for trees
| with different internal nodes and leaves, your code will give
| the optimizer indigestion.
|
| In my experience, basically any of these data structures will
| run about 10-200x slower than their native counterparts. (If
| both are well optimized). To me this is the big performance
| advantage wasm has - that we can make high performance data
| structures.
|
| I'm working on a CRDT in Rust. The fastest JS implementation I
| know of takes about 1 second to replay an editing trace from a
| user. In rust I can replay the same trace in 0.01 seconds (100x
| faster), by using a skip list. In wasm I can do it in about
| 0.03 seconds.
| titzer wrote:
| I think Lemire's measurements are unacceptably lazy.
| WebAssembly is faster than JavaScript on the right things;
| there are many measurements showing this. Typically,
| measurements that show JS on par or beating Wasm either end up
| falling into microbenchmarking traps (one small, hot loop,
| something gets deadcode-eliminated), or they end up relying on
| a particular type of dynamic optimization that Wasm engines
| don't yet do (inlining, escape analysis).
|
| With SIMD and threads, Wasm can absolutely crush JS
| performance.
|
| https://www.infoq.com/articles/webassembly-simd-multithreadi...
| torginus wrote:
| Why would Wasm engines need to do inlining and dead code
| elimination? My impression was that Wasm is basically native
| level-code, save for register allocation, and some arch-
| specific peephole optimizations. Dead code elimination is the
| job of the C++ compiler.
| titzer wrote:
| Generally, I don't disagree, but not all producers are
| LLVM. And JS inlining is driven by dynamic heuristics,
| speculatively inlining likely candidates, whereas
| statically-compiled C++ code generally doesn't have
| speculative inlining. So a Wasm call_indirect will not get
| dynamically optimized into a guarded inline.
| native_samples wrote:
| Isn't SIMD new in this release of the spec? How can WASM
| crush JS using SIMD if they only just added support?
| titzer wrote:
| It's been implemented in browsers for longer than the spec
| has been out. In fact, one condition of a proposal being
| merged into the spec is that two production engines must
| have implemented it.
| joren- wrote:
| I do see some improvements for FFT workloads. The SIMD
| webassembly version is quite a bit faster. Try it yourself:
| https://0110.be/posts/pffft.wasm%3A_an_FFT_library_for_the_w...
| GiorgioG wrote:
| I don't care if it's faster, the same or even slightly slower.
| The sooner I can start working on large applications with a
| strongly typed language (that isn't just transpiled to JS) -
| the better.
| eatonphil wrote:
| My point is that compilation targets are somewhat arbitrary.
| Non-JavaScript languages have been compiling to JavaScript
| for a long time.
|
| What difference does it make for you as a user of a language
| that it compiles to webassembly than to JavaScript or any
| other VM?
| spiffytech wrote:
| Compile-to-JS is a leaky abstraction that gets messy when
| JavaScript's type system and built-ins collide with your
| language's. Some languages also need specialized tooling
| for their compile-to-JS stuff, rather than treating it as
| just another compile target.
|
| I usually find it causes more problems than it solves, but
| I'm hopeful that someday WebAssembly can make compile-for-
| Web transparent enough that non-JS languages really feel
| like a great experience in the browser.
| laszlokorte wrote:
| JavaScript being garbage-collected, having a rather complex
| runtime, not having proper integers etc... makes it a
| rather unfortunate compile target. Yes you can do it and it
| is done but js idiosyncrasies leak into the source langues
| pretty easily.
| eatonphil wrote:
| That's a good argument but more of a maintainer argument
| than a user argument.
|
| From a user it should be transparent except for
| performance and FFIs.
| laszlokorte wrote:
| Well the user perspective is: suddenly there a compilers
| for all kind of languages targetting the browser because
| wasm makes it easier for the maintainers to build them.
|
| Sure you could have implemented unsigned integer
| semantics on top of bool-arrays in javascript years ago
| but if the result is too slow you have gained because the
| compiled c++ code does not run fast enough to be usable.
| josephg wrote:
| Regarding numbers, Javascript supports bigints now -
| which makes the situation a little bit better. (But maybe
| a lot more complex).
|
| I wish they were somehow better supported by JSON.parse
| though.
|
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| cercatrova wrote:
| You could use Dart I guess, Flutter is similar to WASM apps
| like Figma in that they manipulate a canvas, not the DOM
| directly. I'd assume most WASM apps in the future will look
| more like that than true DOM manipulation.
|
| There are others however, such as Yew written in Rust, or
| Blazor in C#.
| mhoad wrote:
| Interestingly enough Dart is also pretty deep into adding
| WASM as a compile target to act as an alternative to the
| current compile to optimised JS approach they do currently
| in the browser.
|
| You are right though they are going to be the first big
| WASM / Canvas and WebGPU framework as opposed to the
| generations of JS / DOM. It will be interesting to see
| where they land with it, I'm quietly hopeful especially
| once you get AOM sorted in the browser too.
|
| I think the real test is going to be when they decide to
| migrate over the multiple billion dollars of revenue
| project that Google Ads is from JS based Dart to WASM based
| Dart.
|
| Work going on here but not much to look at now just source
| and no docs https://github.com/dart-
| lang/sdk/tree/main/pkg/dart2wasm
| jacobmischka wrote:
| Neat, a few of these accepted proposals were the topic of my
| Master's thesis a couple years ago:
| https://github.com/jacobmischka/uwm-masters-thesis
|
| Exciting to see a major release, though admittedly it seems a
| little arbitrary if there aren't any breaking changes (and very
| problematic if there are?).
| MuffinFlavored wrote:
| As somebody familiar with WebAssembly, how would you do FFI?
|
| like say you wanted to make a J2534 DLL
| http://www.drewtech.com/support/passthru.html
|
| How would you export these DLL functions or even call functions
| from other DLLs (dlopen/dlsym, etc.)
| gary_0 wrote:
| You can import host functions and data to a WASM VM much like
| you would with, say, an embedded Python VM. The exact API
| depends on which VM implementation and host language you're
| using.
|
| dlopen/dlsym support is still in the works (for example, see
| [0]). You can't call function pointers directly from WASM,
| naturally, but it is possible to wrap dlsym so you can use it
| from a WASM program. There just isn't a standardized/pre-made
| way to do it yet, so you'd have to write the glue code
| yourself.
|
| [edit] The Emscripten WASM toolchain seems to support
| dlopen/dlsym, see: https://github.com/WebAssembly/tool-
| conventions/blob/main/Dy...
|
| [0] https://github.com/wasmerio/wasmer/issues/1995
| infogulch wrote:
| WA will likely never publish anything backwards-incompatible,
| this is the web after all. If WA's worst versioning sin is
| 'abusing' the major version to collect a number of currently
| implemented proposals under a canonical name, I'll live. And
| pray that nobody from the USB or HDMI standards committees get
| anywhere near.
| simonw wrote:
| Is there a good summary anywhere of what's new in 2.0 compared to
| 1.0?
| paulsmith wrote:
| tl;dr SIMD
|
| - new: vector types - 128-bit width FP and integer types and
| values for SIMD, with related instructions (and validation
| thereof) plus memory instructions for wide loads, and support
| in the runtime for wide values (consts, etc.), and in the text
| and binary formats
|
| - value types (i32, i64, f32, f64) are now called number types
|
| - new: reference types - basically function pointers and
| pointers to objects in the host, values of which can be stored
| in tables, with related instructions for accessing them and
| checking for null
|
| - new: table instructions - get, set, size, grow, fill, copy,
| etc.
|
| - element and data segments - not new but expanded definition
| and given more runtime support (added to the store, can be
| referenced by address like other runtime objects), plus new
| indices for referencing segments and their modes (basically,
| how they are initialized during instantiation)
|
| - limited form of subtyping allowed when importing external
| values
|
| - result types can be a sequence of values (i.e., multiple
| return values from functions)
|
| - new instructions to avoid trapping on floating-point to
| integer conversions ("saturation")
| teabee89 wrote:
| There's also: Multiple values[1]
|
| "Generalized the result type of blocks and functions to allow
| for multiple values; in addition, introduced the ability to
| have block parameters:
|
| - Function types allow more than one result
|
| - Block types can be arbitrary function types"
|
| [1] https://www.w3.org/TR/wasm-
| core-2/appendix/changes.html#mult...
| simonw wrote:
| This is exactly what I was looking for, thanks very much!
| teabee89 wrote:
| Here: https://www.w3.org/TR/wasm-core-2/appendix/changes.html
| lxgr wrote:
| Are there any improvements in there that would allow for more
| efficient bytecode interpreters in WASM?
|
| As far as I understand, something like e.g. a high-performance
| JVM would be hard to do in WASM due to its machine's Harvard-like
| architecture.
| encryptluks2 wrote:
| If you want sandboxes then use Flatpak or force Microsoft and
| Apple to implement a standards compliant sandboxing API. The web
| browser is not the place to do it and people should be looking at
| how this will be used to run binary blobs anytime you visit a
| site.
| kaba0 wrote:
| How is the litany of minimized js used as a compile target not
| binary blobs already?
| encryptluks2 wrote:
| There is a difference between obfuscated JS and minimized.
| Minimized can be unminimized. Also, two wrongs don't make a
| right.
| tux3 wrote:
| I assume this page describes what changed since 1.0:
| Since the original release 1.0 of the WebAssembly specification,
| a number of proposals for extensions have been integrated. The
| following sections provide an overview of what has changed.
|
| https://webassembly.github.io/spec/core/appendix/changes.htm...
| richdougherty wrote:
| Thanks! Here's a quick summary from there, with links to the
| implemented proposals.
|
| Multiple values: Generalized the result type of blocks and
| functions to allow for multiple values; in addition, introduced
| the ability to have block parameters
|
| https://github.com/WebAssembly/spec/blob/main/proposals/mult...
|
| Reference types: Added and as new value types and respective
| instructions
|
| Table instructions: Added instructions to directly access and
| modify tables
|
| Multiple tables: Added the ability to use multiple tables per
| module
|
| Bulk memory and table instructions: Added instructions that
| modify ranges of memory or table entries
|
| https://github.com/WebAssembly/spec/blob/main/proposals/refe...
|
| https://github.com/WebAssembly/spec/blob/main/proposals/bulk...
|
| Vector instructions: Added vector type and instructions that
| manipulate multiple numeric values in parallel (also known as
| SIMD, single instruction multiple data)
|
| https://github.com/WebAssembly/spec/tree/main/proposals/simd...
|
| Sign extension instructions: Added new numeric instructions for
| performing sign extension within integer representations.
|
| https://github.com/WebAssembly/spec/blob/main/proposals/sign...
|
| Non-trapping float-to-int conversions: Added new conversion
| instructions that avoid trapping when converting a floating-
| point number to an integer
|
| https://github.com/WebAssembly/spec/blob/main/proposals/nont...
| dmitriid wrote:
| So it looks like it's basically slapping a 2.0 on
| standardized features from the roadmap:
| https://webassembly.org/roadmap/
| richdougherty wrote:
| I think that's the process, yes. Features get proposed,
| discussed, implemented, then eventually when they're done
| they're moved into the spec and tagged with a version.
| infogulch wrote:
| The additions that look interesting to me are multiple return
| values for functions, and table manipulations.
|
| IIRC tables are used to communicate things like function
| pointers with the host executor, maybe like a vtable but more
| general.
| miohtama wrote:
| No garbage collection integration yet? Or is it done as a
| separate work?
| richdougherty wrote:
| It looks like garbage collection is at the 'proposal' stage,
| one step before it would start to be implemented.
|
| "During this phase: "One or more
| implementations proceed on prototyping the feature to the
| point that a comprehensive set of tests can be added.
| "A test suite is added. These tests need not pass the
| reference interpreter at this point, but should pass on some
| implementation."
|
| https://github.com/WebAssembly/proposals
|
| https://github.com/WebAssembly/meetings/blob/main/process/ph.
| ..
|
| Here's the proposal:
|
| https://github.com/WebAssembly/gc
|
| And you can see it's being actively worked on:
|
| https://github.com/WebAssembly/gc/commits/main
| mhoad wrote:
| Under implementation in Chromium too
| https://bugs.chromium.org/p/v8/issues/detail?id=7748
| gigatexal wrote:
| Is garbage collection really needed?
| m00dy wrote:
| isn't it part of the runtime ?
| mpolun wrote:
| It's for proper integration of garbage collected languages
| -- otherwise you need to embed your GC too, which bloats
| the wasm. JS host VMs have very good GCs these days, so
| hooking into them allows for better integration by e.g. go,
| Java, C#, etc.
|
| Right now wasm is really designed for C/C++/rust
| aaaaaaaaata wrote:
| "No, but it helps."
|
| Opens up the target to an additional subset of devs.
| rektide wrote:
| Are subprojects intended to eventually make it into the main spec
| or do they remain standalone? GC, threads, atomics, component-
| model, interface-types... Im not sure what to expect to
| eventually make it into this spec & what will continue
| developmemt semi-independently.
|
| Personally https://github.com/WebAssembly/component-model/pull/23
| feels like it marks the start of webassembly's first full era. We
| need interoperation, webassembly needs to really be embeddable, &
| only then can we really understand & explore what webassembly
| means to the world.
|
| (Rust got an early start with wasm-bindgen, doing all the lifting
| on their side, but it's not reasonable & only semi-interoperable
| having each language rebuild that bindgen system & abingor
| itself... hence canonical abi & component-model.)
|
| Edit: tux3 has a good comment linking the changelog, noting that
| indeed numberous specs have been integrated.
| https://news.ycombinator.com/item?id=31087610
|
| Really excited for multiple table per module support! The idea of
| a capabilities based sort of system, where a module is handed a
| couple working sets of data as SharedArrayBuffers to work g
| communicate with, is quite compelling.
| richdougherty wrote:
| The whole list of proposals and where they're at is here:
|
| https://github.com/WebAssembly/proposals
|
| You can see that "interface types" is at "Phase 1 - Feature
| Proposal (CG)", so still early days.
|
| And there's a link to the proposal here, for people like me who
| don't know about it: https://github.com/WebAssembly/interface-
| types
| the_duke wrote:
| Also take a look at wit-bindgen [1], which is basically a
| prototype for interface types and supports multiple languages.
|
| I agree we that interface types/components will be a game
| changer.
|
| And also that progress on all the important proposals (GC,
| interface types, linking, stack control, threads) has been
| painfully slow.
|
| [1] https://github.com/bytecodealliance/wit-bindgen
| syrusakbary wrote:
| wit-bingen is great. For those that want to use wit-bindgen
| with Wasmer (tl;dr I work at Wasmer) here's the repo:
|
| https://github.com/wasmerio/wit-bindgen
___________________________________________________________________
(page generated 2022-04-19 23:00 UTC)