WebAssembly 2.0 First Working Draft(w3.org)

302 pointsby syrusakbary4 anni fa141 comments

https://www.w3.org/TR/wasm-core-2/

141 comments

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?).

infogulch4 anni fa

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.

nagisa4 anni fa

Well, backwards compatibility is really a spectrum and the interpretation of the concept can fall at either end of the spectrum depending on what a person is working on. As far as wasm is concerned, there are at least two known discrepancies that made into this draft as documented here https://github.com/WebAssembly/spec/issues/1439.

Especially the last comment by Alex here seems interesting to me – on one hand the observable result of the execution changes for the same program. On another, who is going to bother writing such programs? Should WebAssembly specification be allowed to assume nobody does and make changes such as these?

Lorin4 anni fa

It's such novel tech, why bother with backwards compat between major versions until more developers use it?

Vinnl4 anni fa

That might be what prevents more developers from using it.

cush4 anni fa

Yeah maybe 6 years ago

saurik4 anni fa

Well like, I'd think there would want to be some consistency in the meaning between WebAssembly 1.0/2.0 and WebGL 1/2?

pjmlp4 anni fa

WebGL vs WebGPU shading languages.

tomcam4 anni fa

PDFs here: https://github.com/jacobmischka/uwm-masters-thesis/releases/...

MuffinFlavored4 anni fa

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_04 anni fa

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

bluejekyll4 anni fa

You may want to look into WASM interface types, which is defining what amounts to an IDL for WASM so that different languages have common calling conventions: https://hacks.mozilla.org/2019/08/webassembly-interface-type...

I don’t know if there’s a better intro article. I believe this is the current iteration of the proposal: https://github.com/WebAssembly/interface-types/blob/main/pro...

tux34 anni fa

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...

richdougherty4 anni fa

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...

dmitriid4 anni fa

So it looks like it's basically slapping a 2.0 on standardized features from the roadmap: https://webassembly.org/roadmap/

richdougherty4 anni fa

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.

dmitriid4 anni fa

Just realised this will make it easier for tools like caniuse. Instead of listing all features, they can just have "webgpu 2.0 availability"

robbiemckinstry4 anni fa

Am I still correct in saying these two features are still missing from Wasm? 1. Native Strings 2. DOM interaction

tomcam4 anni fa

Appreciate this. Can you explain why there appear to be English-looking letters used for terms but with alternate Unicode versions? Makes everything look jumbly but I'm sure there's a good reason.

richdougherty4 anni fa

Are you talking about the MathJax rendering used for instruction names?

tomcam4 anni fa

False alarm. I think it's a font rendering problem on Safari. When I tried Chrome and Firefox it didn't appear. For example, under "External Types" at https://www.w3.org/TR/wasm-core-2/syntax/types.html#external... you see this grammar rule:

    externtype ::= func functype | table tabletype | mem memtype | global globaltype

On Safari, the tokens fun, table, men, and global render with weird font baselines on some letters: c, o, e and a are raised a few points higher than they should be. I just figured these were odd substitutions for ASCII characters from further in the Unicode alphabet, maybe to avoid collisions with other reserved token names or something (vamping here because it was all I could think of). Sorry about that.

cormacrelf4 anni fa

I mean, it is definitely a problem. https://pasteboard.co/xzgTi4TxK326.jpg

tomcam4 anni fa

SEE I’M NOT INSANE!

infogulch4 anni fa

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.

miohtama4 anni fa

No garbage collection integration yet? Or is it done as a separate work?

richdougherty4 anni fa

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

mhoad4 anni fa

Under implementation in Chromium too https://bugs.chromium.org/p/v8/issues/detail?id=7748

markdog124 anni fa

And Dart has an experimental wasm backend that leverages that work in v8 here: https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dar...

gigatexal4 anni fa

Is garbage collection really needed?

colordrops4 anni fa

Only way to get rid of JS as an intermediary for DOM access, yes. GC and the DOM are intimately related.

the_duke4 anni fa

Direct Dom access could already be implemented with reference types. GC integration is not necessary for that.

colordrops4 anni fa

What is blocking it from being implemented in browsers at the moment?

aaaaaaaaata4 anni fa

"No, but it helps."

Opens up the target to an additional subset of devs.

m00dy4 anni fa

isn't it part of the runtime ?

mpolun4 anni fa

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

rlp4 anni fa

Also, WebAssembly can't support most GC runtimes now, because you can't scan the stack for roots. You can keep your own shadow stack on the heap, but that has a bunch of pretty bad performance implications. This actually impacts C/C++/Rust codegen as well, since they can't create references/pointers to anything on the stack, and have to build their own shadow stack (I think this is done in binaryen or LLVM itself?). I understand it's a security thing to disallow direct stack access, but most languages and runtimes expect it.

Anyways, that's why there needs to be support in WebAssembly for GC, because there needs to be a safe way to walk the stack (aside from the obvious JS interop considerations).

kllrnohj4 anni fa

> JS host VMs have very good GCs these days

Aren't all of them single-threaded, though? That is, they only work in a VM with a single thread which the GC shares? Since WASM is supposedly finally bringing real multi threading to the web, how would that work? It seems like you'd need a new GC for WASM rather then just repurposing the JS GC.

titzer4 anni fa

Many JS GCs are internally multi-threaded and can handle multiple allocators. Even though JS isn't itself multi-threaded, the JIT and runtime systems now are, and they can concurrently allocate onto the heap. V8 has had to move towards this ability very gradually because of assumptions from the single-threaded world, but it's much more likely to support multi-threaded Wasm GC, should it be necessary, in the future.

usrn4 anni fa

Is bringing your own GC that hard? I think putting one in the spec would bloat Wasm runtimes which would be more concerning.

titzer4 anni fa

I've done it for Virgil. It's a major pain, because Wasm, by design, does not give access to the value stack. So to find roots you need to spill them into memory into what is called a "shadow stack".

The problem with bringing your own GC isn't just that, though. It's that using linear memory for everything, you're forced to put external references in a table, which roots them. Tables aren't weak...and even if they were, it's possible to set up a cycle between the linear-memory GC references and external references so that leaks happen. This was a problem in other contexts, for example, in V8 embedded into Chromium, and the ultimate result is that you need cooperative garbage collection across two heaps, with queues. While V8 and Chromium trust each other, both not to screw up, and to be fast, it's hard to see how to make that cooperative garbage collection contract work with untrusted Wasm code.

tormeh4 anni fa

Go ships its own GC as part of the binary for non-wasm targets. Why should wasm be special?

astrange4 anni fa

If you share objects between wasm and JS then you want to share garbage collectors so you don’t have to pin them.

pjmlp4 anni fa

Flash, Silverlight, Java, TinyGo and .NET are doing just fine on WebAssembly.

emteycz4 anni fa

In isolation, but no cross-language invocations, reference sharing etc yet.

It'll work as promised when I can import a C# class in my JS code, instantiate it and then pass one of its methods to a Python module and invoke it from there.

Great times are ahead of us.

pjmlp4 anni fa

You mean like using JScript alongside C# and IronPython on the CLR, ah the circles of rediscovery.

emteycz4 anni fa

Exactly like that, but also in a secure sandbox and in the browser. Can CLR do that without Wasm?

pjmlp4 anni fa

In the browser, that is what Silverlight was all about.

Outside of the browser, WebAssembly is still a shadow of CLR capabilities, including sandboxing.

As for the "secure" in WebAssembly, I advise a good read about the security section, specially memory corruption

https://webassembly.org/docs/security

https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf

emteycz4 anni fa

Silverlight never had even the slightest hint of security, and no interop with JS or non-CLR (e.g. JVM) languages.

It was also comically slow and worked only in IE.

I'm well versed in security of Wasm. Much better than anything else available today or in the past, obviously still not perfect.

One of the best features of Wasm is entirely social - seems like everyone has agreed on it, finally. That's enough for me even if it was a 1:1 copy of JVM or CLR.

pjmlp4 anni fa

The new NoSQL and big data hype of bytecode based runtimes.

emteycz4 anni fa

Not really, just finally a real common language runtime.

aykevl4 anni fa

Supporting GC on WebAssembly has been a _major_ pain for TinyGo because WebAssembly doesn't allow access to the stack. It's really slow and I'm still not confident it's bug free. Having a GC integrated in WebAssembly itself should solve these issues.

Unfortunately, the current GC design for WebAssembly doesn't support interior pointers which is going to be difficult to work around (but I don't think it's impossible). Interior pointers are normally required in Go.

eatonphil4 anni fa

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...

josephg4 anni fa

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.

criticaltinker4 anni fa

Adding to this great comment with my own experience at work where we extensively use signal processing and time series compression algorithms to visualize large amounts of biological signals in the browser.

WebAssembly is less than 10%-20% slower than native code in our benchmarks and tests for algorithms like fast wavelet transform and bit packing.

WA allows us to aggressively optimize ahead of time when compiling, and be less sensitive to JS engine performance pitfalls around JIT optimization and garbage collection.

pistachiopro4 anni fa

Throwing in my data: for physics simulation code, WASM vs native was identical, provided the native code was compiled with automatic SIMD optimizations disabled. On the one hand, that speaks well of the idea of web assembly, on the other, disabling SIMD is highly artificial. It's good to see basic SIMD being made standard, though the 256-bit wide SIMD instructions are still being finalized, and those will be necessary to really have a chance at evening out performance vs. native.

alephnan4 anni fa

> 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.

I'm building a text editor right now. I'm just using a giant array with one element for each line. I anticipated that it would get slow, and that potentially I can push this into WebAssembly.

The problem is that you're going to need to get the data back out of WASM eventually, back into JavaScript and then back to the DOM.

I focused on other optimizations and strangely my text editor is able to keep 9 million loC file ( over 500mb ) in memory. The trick is to not render everything to the DOM, just the stuff people are looking at. That's the other bottleneck. V8 is surprisingly smart. Random access for a small section of that 9 million element array is still fast. You'd expect this array to be non linear, too. Moreover, even localized shifts are fast. I'm puzzled. For comparison, VSCode uses a more esoteric data structure called a PieceTree but for me becomes unresponsive at 500k LoC. To be fair, they have other sorts of overhead and processing layers to deal with, namely building an AST with potentially thousands of layer of hierarchical / code folding. Speaking of which, VSCode is built entirely in TypeScript and has a reputation of being a fast and snappy editor.

At any rate, I don't buy the argument that because Rust is fast and WebAssembly is comparably fast, then it makes sense to push your data structure, especially a text buffer, down into WebAssembly. The bottleneck is serializing data back and forth between WebAssembly and JavaScript. For text editors, I'm not sure this overhead is worth it, especially when V8 / Chrome is doing some crazy JS optimization behind the scenes. The appealing bit with WebAssembly is potentially that objects will have a smaller memory footprint, therefore we can push further than this 9 million LoC limit where the Chrome tab just runs out of memory, rather than having algorithmic slowdown.

mejutoco4 anni fa

> The problem is that you're going to need to get the data back out of WASM eventually, back into JavaScript and then back to the DOM.

Could you paint everything in a canvas element to avoid the DOM? That is being my approach in a small project, although it admitedly can complicate things.

josephg4 anni fa

Don't do that. There's all sorts of very complex OS-level UX controls which hook into a text box. If you implement your own text box using canvas, all this stuff will be broken by default.

For example:

- Ctrl+Left / right for moving a word at a time. This is Alt+Left/right on a mac I think. There's another keyboard shortcut to go to the start / end of a line, or the start / end of the input element. These shortcuts are OS-specific and can be overridden in the user's OS level settings - which you don't have access to from javascript. There's a mountain of shortcuts - like Ctrl+A, Ctrl+X/C/V, etc. They all vary per OS. You have to implement them correctly on every operating system.

- International character input methods. Eg, how would you type Japanese / Korean / Chinese characters into your text element?

- Undo/redo support

- Text selection via the mouse, the keyboard and on mobile by touch-dragging to select.

- Accessibility - like voiceover and dictation.

No matter how dedicated you are, I guarantee your custom canvas element will never correctly re-implement all the features already available in a simple HTML text input element.

mejutoco4 anni fa

I am aware of the tradeoffs and generally I agree. That is what I meant by it can overcomplicate things. It is all tradeoffs, and for some usages it might be a valid one to remove the dependency on the DOM.

I see it as an option for a heavy app in the browser. This is AFAIK similar to what Figma does (or flutter). Also, I am not referring specifically to text editors, although I could imagine something like vim working with this approach in the browser without trying to replicate an HTML text input element.

slight_glitch4 anni fa

Google Docs does that and it works. Not perfect, but good enough.

josephg4 anni fa

> At any rate, I don't buy the argument that because Rust is fast and WebAssembly is comparably fast, then it makes sense to push your data structure, especially a text buffer, down into WebAssembly.

To store a buffer in a plain text editor, with no syntax highlighting? I'm not going to fight you on that. I'm glad pure javascript is fast enough for your needs.

But doing collaborative text editing with a CRDT adds some extra requirements that your text editor's buffer might not have. For example:

- Hydrating the document state on load. To cut down on file size, diamond types files currently just store the entire editing history. When you open them up, we replay the whole editing history into a buffer. And using Wasm + jumprope[1], this is <1ms even for very large documents. The same would not be true in javascript, and I might need to use bigger files.

- Merging concurrent changes. (Like, merging a long lived branch). This currently involves getting fancy with a B-tree. This is fast enough in rust. It would be orders of magnitude slower in javascript.

- Undo support. When you hit undo, you need to ignore any more recent typing from other users and just undo the local user's last change. This is subtle.

- When edits happen, we need to convert between your (line, JS column) tuple and whatever the CRDT uses internally. Diamond types specifies edit positions by counting unicode characters from the start of the document. So we need to convert between (line,col) and unicode offsets whenever local or remote changes happen to broadcast or apply the changes.

Rust + Wasm let me make all of these operations essentially instant. I can do that because I can use an appropriate data structure & algorithm for each operation.

And, sure, Javascript's Array is pretty fast. But if you ever need something more complex than Array, your performance will suffer massively. Personally I feel much better writing this code in rust + wasm.

I'd integrate diamond types with your text editor by just passing edits back and forth across the module boundary. I agree that it probably doesn't make sense to share a text buffer between javascript and wasm.

[1] https://crates.io/crates/jumprope

alephnan4 anni fa

> I'm glad pure javascript is fast enough for your needs.

In this case, the bottleneck at 9 million LoC is not CPU cycles but memory usage. That's where I am considering pushing down into WebAssembly, but whatever function-inlining optimization V8 is doing, it is probably still faster than the overhead of JS<->WebAssembly function call. I have no doubt WebAssembly will edge out again.

> Merging concurrent changes. (Like, merging a long lived branch). This currently involves getting fancy with a B-tree. This is fast enough in rust. It would be orders of magnitude slower in javascript.

I guess my point is why do you need balanced trees? Is this a CRDT specific thing? Can you implement CRDT with just an array of lines / gap buffer?

> Undo support. When you hit undo, you need to ignore any more recent typing from other users and just undo the local user's last change. This is subtle.

From my understanding, the whole point of CDRTs or any command-based design is express changes to the state as the delta. In which case, you only have to stack / remember the set of commands and not have to store the state on every change. I'm not sure if this overlaps with the data structure choice, other than implementation details.

> And, sure, Javascript's Array is pretty fast. But if you ever need something more complex than Array, your performance will suffer massively. Personally I feel much better writing this code in rust + wasm.

I was just looking into TypedArrays. From my understanding, the JS runtime will use a HashMap or DoublyLinkedList if the array elements are homogenous. In the case where the JS runtimes know it is homogenous, they will fallback to those TypedArray / fixed length buffers that are "continuous" in memory. So on the JS side, Arrays can be as fast as TypedArrays thanks to the compiler. Consequently, in some benchmarks they will effectively be the same.

The question is whether the speed of a native array is faster than the speed of a TypedArray such that it pays for the WASM<->JS overhead. And I guess this depends on the application and the access patterns of that interop.

josephg4 anni fa

> In this case, the bottleneck at 9 million LoC is not CPU cycles but memory usage. That's where I am considering pushing down into WebAssembly

How often does this come up in practice? I can't think of many files I've opened which were 9 million lines long. And you say "LoC" (lines of code). Are you doing syntax highlighting on 9 million lines of source code in javascript? Thats impressive!

> I guess my point is why do you need balanced trees? Is this a CRDT specific thing? Can you implement CRDT with just an array of lines / gap buffer?

Of course! Its just going to be slower. I made a simple reference implementation of Yjs, Automerge and Sync9's list types in javascript here[1]. This code is not optimized, and it takes 30 seconds to process an editing trace that diamond types (in native rust) takes 0.01 seconds to process. We could speed that up - yjs does the same thing in 1 second. But I don't think javascript will ever run as fast as optimized rust code.

The b-tree in diamond types is used for merging. If you're merging 2 branches, we need to map insert locations from the incoming branch into positions in the target (merged) branch. As items are inserted, the mapping changes dynamically. The benchmark I've been using for this is how long it takes to replay (and re-merge) all the changes in the most edited file in the nodejs git repository. That file has just shy of 1M single character insert / delete operations. If you're curious, the causal graph of changes looks like this[2].

Currently it takes 250ms to re-merge the entire causal graph. This is much slower than I'd like, but we can cache the merged positions in about 4kb on disk or something so we only need to do it once. I also want to replace the b-tree with a skip list. I think that'll make the code faster and smaller.

A gap buffer in javascript might work ok... if you're keen, I'd love to see that benchmark. The code to port is here: [3]

> Undo support -> In which case, you only have to stack / remember the set of commands and not have to store the state on every change. I'm not sure if this overlaps with the data structure choice, other than implementation details.

Yeah, I basically never store a snapshot of the state. Not on every change. Not really at all. Everything involves sending around patches. But you can't just roll back the changes when you undo.

Eg: I type "aaa" at position 0 (the start of the document). You type "bbb" at the start of the document. The document is now "bbbaaa". I hit undo. What should happen? Surely, we delete the "aaa" - now at position 3.

Translating from position 0 to position 3 is essentially the same algorithm we need to run in order to merge.

> I was just looking into TypedArrays.

I tried optimizing a physics library a few years ago by putting everything in typedarrays and it was weirdly slower than using raw javascript arrays. I have no idea why - but maybe thats fixed now.

TypedArrays are useful, but they're no panacea. You could probably write a custom b-tree on top of a typedarray in javascript if you really want to - assuming your data also fits into typedarrays. But at that point you may as well just use wasm. It'll be way faster and more ergonomic.

[1] https://github.com/josephg/reference-crdts

[2] https://home.seph.codes/public/node_graph.svg

[3] https://github.com/josephg/diamond-types/tree/master/src/lis...

pattrn4 anni fa

What are your thoughts on the Javascript YJS CRDT implementation? I'm admittedly pretty new to the space, so I don't know much about performance comparisons. Haven't noticed any significant performance problems with it (using it for collaborative editing on ~100,000 word documents), but would love hearing what you think.

josephg4 anni fa

Eh. Its fine. I think its the best CRDT out there right now (but Kevin had a few years' head start on me!). I haven't done a lot with yjs personally. And I don't agree with a few of Kevin Jahns's design decisions, but none of them are deal-breakers:

- The way deleted data is encoded in yjs is awkward. Versions store a list of which content has been deleted. So versions are bigger than they need to be, and you can't replay the editing history without stored snapshots. I think the knowledge of which elements have been deleted should just be saved into the binary format alongside the inserts.

- For javascript objects, yjs pretends each value is actually a list (with everything after the first element ignored) so it can reuse the logic for list editing. This is overcomplicated compared to Shelf or something like it.

- Yjs's internal structure is a linked list with cached offsets. This works ok in practice because inserts usually appear close to each other, but it means yjs has O(n^2) performance to process n edits rather than O(n log n). Diamond types (via wasm) is about 30x faster as a result - though as you say, yjs is still plenty fast enough in practice for most applications. And this gap will narrow once Yrs is working well.

- Yjs can have an interleaving problem when concurrent items are prepended at the same location in a list.

- The current (new) diamond types file format stores the origin-position + parents information instead of storing left-origin / right-origin fields. This lets DT have a smaller file size while storing more information than yjs stores. And I think this format is easier for applications to encode and work with, and it will make pruning easier when we get to it. We should also be able to load & save faster than yjs - but I'm not benchmarking that yet.

But all of this stuff is pretty minor. Yjs works well in practice, and its quite mature. Performance will only get better with the yrs rust implementation. For diamond types, I had the benefit of being able to copy some fantastic implementation ideas from Yjs. If diamond types is better than yjs, its because I'm standing on its shoulders.

titzer4 anni fa

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...

torginus4 anni fa

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.

titzer4 anni fa

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_samples4 anni fa

Isn't SIMD new in this release of the spec? How can WASM crush JS using SIMD if they only just added support?

titzer4 anni fa

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.

GiorgioG4 anni fa

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.

eatonphil4 anni fa

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?

laszlokorte4 anni fa

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.

eatonphil4 anni fa

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.

laszlokorte4 anni fa

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.

josephg4 anni fa

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...

spiffytech4 anni fa

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.

cercatrova4 anni fa

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#.

mhoad4 anni fa

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

joren-4 anni fa

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...

alephnan4 anni fa

http://iswebassemblyfastyet.com

3np4 anni fa

This post (discussed on HN recently) goes into some of it and provides some further links.

TL;DR: It depends. https://zaplib.com/docs/blog_ts++.html

rektide4 anni fa

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.

the_duke4 anni fa

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

syrusakbary4 anni fa

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

richdougherty4 anni fa

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

jfmc4 anni fa

What about pointer size? Is still only 32-bits? It is impossible to write some C programs when you do not know the size of your data and pointers.

I'm asking that because despite all the hype, wasm binaries are still 32-bit (at least in browsers), while 32-bit OS are being deprecated. 64-bit pointers are really good for some applications, with no performance degradation at all.

Does Wasm 2.0 support branch instructions needed for irreducible control flows? (without the relooper hack)

jsheard4 anni fa

> 64-bit pointers are really good for some applications, with no performance degradation at all.

That probably won't be the case with wasm64 unfortunately. A hidden advantage of wasm using a 32 bit address space while primarily targeting 64 bit platforms is that runtimes can get free implicit bounds checking by carving out a 4GB block of virtual memory for each wasm instance, so out-of-bounds accesses are trapped by the hardware.

That trick won't work for wasm64, so runtimes will have to go back to inserting explicit bounds checks at every memory access, and it'll be a tradeoff where in exchange for being able to access more memory everything will run a bit slower.

legulere4 anni fa

Having 32 bit pointers in WASM does not mean that the JIT emits 32 bit code. 64 bit pointers always are a performance degradation, as they use up more space, it can just be negligible. 64 bit x86 most of the time being faster has nothing to do with pointer width but with more with having more registers, a better calling convention and a minimum of SSE2. This is also the reason why the x32 ABI is faster than regular x86-64.

The only advantage of 64 bit pointers is that you can have a bigger address space than 4GB.

astrange4 anni fa

That’s not the only advantage, you can also store extra data in them which is extremely useful for performance (tagged objects) and security (PAC).

Although an abstract machine could have metadata with each pointer that isn’t part of the official bit size, I suppose.

shadowofneptune4 anni fa

I had some trouble understanding the problem, since I've never had to translate a program that relies on goto into a purely structured one. Does this article cover it well? https://medium.com/leaningtech/solving-the-structured-contro...

jfmc4 anni fa

The requirement for structured programs dates back from the asm.js hack. Both relooper and stackifier are still workarounds. CPUs do not require structure programs at all. Unless there is a really good reason this still looks a hack driven by limitations of the underlying code generation. I understand that some compilation passes are easier/cheaper with structured control. But then... why are not LLVM and GCC enforcing them as well (at least their roadmaps)?

astrange4 anni fa

It’s for security reasons and enabling static code analysis, there’s no particular need to make compilation “easier”.

PNaCL also had a lot of limitations though I don’t remember what they actually were.

[deleted]4 anni fa

faichai4 anni fa

Not yet, a note on the Memory instructions [1] still says: “Future version of WebAssembly might provide memory instructions with 64 bit address ranges.”

[1] https://www.w3.org/TR/wasm-core-2/syntax/instructions.html#m...

jfmc4 anni fa

https://webassembly.org/roadmap/

I fear they will run out of gas before the interesting features there are completed...

emteycz4 anni fa

They haven't for 5 years, why would they now? The work is just getting interesting...

jfmc4 anni fa

Perhaps... but 5 years without progress in some areas is an eternity. Rust in Firefox was super interesting and they run out of funding. It is really hard to explain to a client: "your application would work on WASM, on a browser, with no installation, but it will not scale in time and memory, and there is not a clear roadmap of then things will improve (despite OS and compiler guys know how to fix those things)".

emteycz4 anni fa

There's a lot of progress over the past 5 years, every month there's something new and exciting.

But it's not yet ready for mass adoption, yeah.

dmkolobov4 anni fa

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.

titzer4 anni fa

Tail calls are only blocked on a second production engine implementing them. V8 has been done with tail calls for more than 3 years.

outside12344 anni fa

As an aside, how does one get involved in the WebAssembly community?

For example, if you wanted to get involved in Kubernetes you'd go to KubeCon, and governance of the OSS project is pretty understandable?

What is the equivalent in WebAssembly land?

tlively4 anni fa

The simplest way to get involved is to start attending the biweekly standardization meetings. The agendas are organized here: https://github.com/WebAssembly/meetings

To attend the meetings, first join the W3C WebAssembly Community Group here: https://www.w3.org/groups/cg/webassembly, then email the CG chairs at [email protected] to ask for an invite.

From there you'll get a sense of who folks are so you can pair names with faces when contributing to the various proposal discussions on the many proposal repos listed here: https://github.com/webassembly/proposals.

To get a sense of how things are run and decided, read the process documents here: https://github.com/WebAssembly/meetings/tree/main/process. The TL;DR is that the community group and its subgroups decide everything by consensus via votes during the meetings.

gulbanana4 anni fa

Seek employment at Mozilla, Google or Apple.

simonw4 anni fa

Is there a good summary anywhere of what's new in 2.0 compared to 1.0?

paulsmith4 anni fa

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")

teabee894 anni fa

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...

simonw4 anni fa

This is exactly what I was looking for, thanks very much!

teabee894 anni fa

Here: https://www.w3.org/TR/wasm-core-2/appendix/changes.html

trzeci4 anni fa

Did I miss something, but I don't see any mention about improvements in debugging capabilities. As a game developer that targets iOS/Android/UWP/WASM - WASM will be never a first target to work with, if there will be no debugger connection between IDE and Browser, that understands WASM.

The current solution that works only for Chrome and allows to use DWARF is an improvement but it has lot's of limitations: One of them is the limit of 4GiB (or 2GiB - don't remember) of DWARF file. Secondly - the entire browser tends to crash with that plugin on larger projects.

jfmc4 anni fa

I have the strange feeling that WASM is reinventing the wheel at each step and that they should have continued with PNaCL technology.

yurymik4 anni fa

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 :(

keithwinstein4 anni fa

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/).

alephnan4 anni fa

Does anyone know why Rust is one of the "de facto" host languages for WebAssembly?

Is it because Rust naturally leant itself to machine code, therefore it was easier to build a compiler?

Is it because the Rust community wants to create more "killer features" for the language and have it stand out?

Are there benefits to using Rust versus TypeScript as the host language?

biztos4 anni fa

I don’t know but I would guess it’s because of the relationship between Rust and Mozilla.

https://news.ycombinator.com/item?id=26067118

There are probably specific advantages to Rust, but it’s also just nice to work in a language you like. I can compile Go to WebAssembly so I’m not going to write TypeScript. Your preferences may differ.

nindalf4 anni fa

Can TypeScript be compiled to WebAssembly? My understanding was that it couldn’t be, although a related language AssemblyScript could be.

amouat4 anni fa

One of the major benefits of Rust is that it isn't garbage collected. I'm not sure of the current status of GC support in WASM, but it used to mean that to compile something like Go to WASM also meant including a full GC implementation in the WASM code, not only bloating it but complicating implementation etc.

journey_161624 anni fa

My dream for WebAssembly is direct filesystem / local database access in Electron apps and mobile apps powered by a WebView. So you could have for instance, a Rust binary that does almost everything and is able to use DOM for rendering. Currently if I understand it correctly the only way to do that is without WASM actually. A separate binary communicating via IPC with JavaScript in the renderer process - I'm not sure if the latency is good enough to put any front-end logic in that binary.

Edit: Actually it's quite viable as it is and I'm not sure how I did not think of it sooner. Just run everything in WASM and make requests to the database like WASM -> JavaScript -> IPC and latency is not a problem here.

slaymaker19074 anni fa

There is some really exciting stuff "https://github.com/WebAssembly/proposals" I'm particularly excited about stack switching.

crudbug4 anni fa

No DOM API ?

No GC API ?

TheCycoONE4 anni fa

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.

trzeci4 anni fa

DOM API? Why? This can be added by any third party library. Wasm should not care about DOM

lxgr4 anni fa

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.

miolini4 anni fa

Looking for memory shrink instruction.

ramesh314 anni fa

Any higher level developments in WASM land? What about garbage collection?

tlively4 anni fa

The GC proposal recently moved to phase 2 and has a lot of momentum. Teams working on compiling Java, Kotlin, and Dart to Wasm are closely involved in the standardization effort and implementations are under way in V8 and other Web engines. Right now the bulk of the effort on the standardization side is in tweaking the instruction set to simplify it and improve performance and on the implementation side the focus is heavily on optimizations, both offline and in the engines.

zacharycohn4 anni fa

Typo in the Abstract paragraph. "WebAseembly Core"

alephnan4 anni fa

What are examples of real applications / businesses using WebAssembly?

wiqar4 anni fa

Disclosure: I work for Wasmer, a WebAssembly company.

1. Figma uses Wasm extensively in the browser. 2. Unity ships their game engine to the browser using WebAssembly 3. Amazon Prime uses WebAssembly as a part of their OTT stack 4. A lot of Blockchain companies user WebAssembly to process smart contracts. 5. There are new start-ups lile Hotg.ai that use WebAssembly to deploy ML solutions to connected or semi-connected devices. (Hotg.ai uses Wasmer) 6. Shopify uses AssemblyScript and WebAssembly for their plugin system.

The_rationalist4 anni fa

pwdisswordfish94 anni fa

Are there any actual incompatibilities or is the version number just a marketing gimmick?

eatonphil4 anni fa

There isn't a law saying all legit software must use semver. :)

Python makes breaking changes whenever they want in minor version changes.

kibwen4 anni fa

Technically, even semver doesn't strictly require you to not update the major version when there haven't been incompatible changes (I swear, a triple negative is the easiest way to parse this sentence :P ).

sinsterizme4 anni fa

How about: You can bump the major version with no incompatible changes and still be semver compliant

AgentME4 anni fa

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).

tester894 anni fa

This https://github.com/WebAssembly/spec/issues/1439

singularity20014 anni fa

Only forward incompatibilities, that is: Wasm 1.0 engines can't handle 2.0 opcodes etc

encryptluks24 anni fa

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.

kaba04 anni fa

How is the litany of minimized js used as a compile target not binary blobs already?

encryptluks24 anni fa

There is a difference between obfuscated JS and minimized. Minimized can be unminimized. Also, two wrongs don't make a right.

autoexec4 anni fa

I know folks are excited about webassembly but it's a security nightmare. JS alone is bad enough with most exploits I see that can get you infected just by visiting a page requiring it even when the issue doesn't lie in JS directly. The idea of letting any random website you visit run code on your machines should give anyone pause, but it seems like everybody is just too excited about the powerful web applications they could make to worry about the malicious web apps that will be created as well.

For now I've got webassembly disabled, and I don't see that changing