то есть атомики будут просто игнорироваться, а вот atomic.notify будет выбрасывать исключение если это выполняется в среде не поддерживающей многопоточность или если это выполняется над обычной (не разделяемой) памятью

А почему именно OCaml ?

🤔

по Deno тоже есть

High-level garbage-collected language with ADT and pattern matching plus very decent performance. 🤷‍♀

все еще там, на митинге сказал, что представляет wasmer

блин, вчера ж был interface types митинг 😑

Chrome принялся наконец за ускорение интеропа js <-> wasm:
1) https://bugs.chromium.org/p/chromium/issues/detail?id=1029470

2) https://bugs.chromium.org/p/v8/issues/detail?id=10070&q=&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Component%20Stars

Того что есть достаточно, что бы рисовать в webgl с частотой 60fls

Наконец-то, оно как будто сломано было.

Хорошо, тогда попросим их больше не оптимизировать.

Помните я говорил про 3x если использовать SIMD в новом wasm бэкенде для tfjs? Так вот, это подтверждено практически + небольшой бонус в еще +50% если qfma использовать:
https://twitter.com/nsthorat/status/1208410035639992321

Я кажется понял, почему команда Dart-а не хочет в WebAssembly ссылаясь мол wasm еще нестабилен и вообще нам и так хорошо =) Но настоящая причина в том, что Dart AOT блин медленее чем даже JIT вариант. Иногда аж в 16 раз!

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/dart-dartaot.html

Так это не новость. В особенности - для разработчиков Dart. 😊
Несмотря на обязательную теперь статическую типизацию, Dart - очень динамический язык, поэтому AOT расставляет проверки и прочие механизмы, которые JIT спекулятивно выкидывает. AOT вообще только из-за iOS и сделали.
Я одного не могу понять - при чём тут WASM? 😄

а у wasm-а разве нет инструкций для выполнения сгенерированного кода подобно тому как в js есть Function(..) ? Если нет то wasm это действительно преграда для jit-языков но с другой стороны можно ведь прокинуть интерфейс jit-а через js - со стороны wasm-а будет отсылаться запрос к js и уже через js будет происходить компиляция и выполнение нового wasm-модуля, на выходе будем иметь тот же jit, разве нет?

Пожалуй, только мееееедленно. 😂
Кроме того, зачем, если у JS и так есть JIT?

Особенно интересно в такой схеме выполнять деоптимизации. 😉

Дело в том что очеь многие мечтают и просят Dart компилировать в wasm, особенно разработчики flutter. Но команда не раз выступала с детальным разбором, что wasm нестабилен, и еще довольно много странных и предвзятых немного доводов, но похоже что истинная причина может как раз в том, что пока они не могут нормально скомпилировать в AOT. Ксати нашел даже в их FAQ завуалированное описание:

Code that’s compiled ahead-of-time (AOT) with a compiler such as dart2native has different performance characteristics from code that’s compiled just-in-time (JIT) in the Dart VM. AOT-compiled code is guaranteed to have fast startup and consistent runtime performance, with no latency during early runs. JIT-compiled code is slower at startup, but it can have better peak performance after it runs long enough for runtime optimizations to be applied.