maxgraey
Joined 7 years ago
Karma
90
Submissions
53
Member since
Feb 14
Recent submissions
Comment · 3 years ago
Comment · 4 years ago
> If you don't do frontend stuff, you don't have to use WASM, you know?
WebAssembly is excellent for:
- Game's scripting engine (UE plugin example: https://www.reddit.com/r/unrealengine/comments/na6hfx/integr...)
- Rule engine for ServerLess scenarios (See Lucet)
- For node.js plugins instead native plugins. Webpack uses AS for hash calculations: https://github.com/webpack/webpack/tree/main/assembly/hash
- For smart contracts of blockchain. AssemblyScript uses for Near Protocol, The Graph Protocol, Cosmos and many others
Comment · 4 years ago
TypeScript has completely different goals. It will always just be a semantic checker on top of JS and nothing more. This has been mentioned more than once:
https://github.com/microsoft/TypeScript/issues/9202#issuecom... https://github.com/microsoft/TypeScript/issues/10386#issueco... https://github.com/microsoft/TypeScript/issues/375#issuecomm...
Comment · 4 years ago
The main advantage of using Binaryen directly bypassing LLVM is firstly very fast codegen and optimization (Binaryen architecture perfectly utilizes multithreading as opposed to LLVM). In addition, clean and fast debug builds are not clogged with SSA and mSSA noise. That makes debug/release performance not more than 2-4x slower, unlike LLVM where this ratio is 20x-40x as already mentioned. The Binaryen optimizer is improving all the time. It is already better in many places than the same Go's codegen
Comment · 4 years ago
> It isn't designed for or suitable for large projects.
Why? The compiler itself is written in AssemblyScript and is capable of bootstrapping. The AS code base is quite large. In addition, there are other quite large projects. For example: https://github.com/acutmore/type-off. It's port of "sucrase" project (which functionally equivalent to esbuild or swc)
Comment · 4 years ago
old topic:
https://github.com/WebAssembly/WASI/issues/401#issue-8177488...
The problem with WASI is that it is a some kind of truncated copy of CloudABI and POSIX. With all the goodies like abbreviated error codes like "fbig", "idrm", "srch" and etc. See: https://github.com/WebAssembly/WASI/blob/0ba0c5e2e37625ca5a6...
The main problem of WASI in my opinion is that it's based on a standard which is 30 years old. And yes, the idea was cool, to let you run even C without having to rewrite libc. But the reality is that we can't do this now and it's still a big question whether we can in the near future. Besides, C is probably the only one that needs such a low level api, but everyone has to suffer because of it, essentially reinventing libc based on WASI with their own language runtime on top of it. This is simply a waste of binary space.
Also it lead to fragmentation into the WebAseembly ecosystem. A compiled program in wasm32-wasi cannot run in a browser, only in wasmtime, wasmer or node.js. WASI-polyfill.js is very limited, adds a bunch of kilobytes of glue code and is still not even officially introduced.
Comment · 4 years ago
The article is relatively old. But I have the most complaints about the performance measurements. The WebAssembly should be tested in a way that eliminates the interop time, which is very expensive. That's why sorting and simple multiplication will always be slower if tested outside WebAssembly. Sorting in AssemblyScript is actually faster than in Rust or JavaScript:
https://twitter.com/MaxGraey/status/1414867216676368384
Comment · 4 years ago
> Iraq, Afghanistan, Libya, Syria, all within the very recent history, plus countless more US-backed color revolutions - including the one in your very own country, which realistically is the very reason for the current state of affairs in there.
Oh God! You and your conspiracy theories are annoying. If the U.S. is so powerful, why hasn't it organized a color revolution in Russia or at least in Serbia, maybe in pro-Russian Hungary? I was at both revolutions in Ukraine and I know why they arose, they were supported by the Ukrainian people, self-organized. And it's been like that all through our history. You don't know shit about the political situation in Ukraine and its history, but you think you have it all figured out. I'm sure you don't even know your own history. So don't talk bullshit!
Comment · 5 years ago
> And there's been talk of exposing the JS GC to wasm for a few years. Hopefully when that stuff lands, it'll get easier to marshal objects across the gap.
You don't need a Wasm GC to do this. If you only need js objects to pass on to, say, the host's function or check is null or not, then reference types that are opaque external references: https://github.com/WebAssembly/reference-types/blob/master/p...
You can even do many more things if you export `Reflect` to WebAssembly: https://github.com/AssemblyScript/assemblyscript/blob/main/t...
Reference Types are available almost everywhere already (In Safari will be available after 15.0): https://webassembly.org/roadmap
Comment · 5 years ago
Are you sure UTF-8 is the ideal format? After all, we have grapheme clusters that cannot be rendered as text units using UTF-8. Maybe UTF-8 is already obsolete and never took over the world? I am more than sure that soon we will see the new Unicode format ;)
Comment · 5 years ago
So basically even in UTF8 you can create malformed string. For example ðŸŒ. It miss one byte and may cause to problems in some editors / text viewers which doesn't handle or pre-verify such cases . Valid UTF8 has a specific binary format. If it's a single byte UTF8 character, then it is always of form '0xxxxxxx', where 'x' is any binary digit. If it's a two byte UTF8 character, then it's always of form '110xxxxx10xxxxxx'. Similarly for three and four byte UTF8 characters it starts with '1110xxxx' and '11110xxx' followed by '10xxxxxx' one less times as there are bytes.
So it's not just UTF16 that has problems and can cause security problems. I just wanted to emphasize that
Comment · 5 years ago
Yeah, WebAssembly have i64/u64 types as first class citizens unlike JavaScript which should emulate it or use BigInt which drastically slower than native 64-bit types. That's why crypto algorithms got a lot of speed benefits. AssemblyScript also show this. See this:
https://github.com/FriendlyCaptcha/friendly-pow https://github.com/hugomrdias/rabin-wasm
Comment · 5 years ago
latest benchmarks with wasm3, wasmer, wasmtime, wavm and etc:
https://www.00f.net/2021/02/22/webassembly-runtimes-benchmar...
Comment · 5 years ago
That's true. But wasm also required some extra codegen and optimizations for i64 types for example (also simd and atomics). In addition, wasm will have more specific CFG optimizations for WebAssembly. For example
https://bugs.chromium.org/p/v8/issues/detail?id=11298
Comment · 5 years ago
It's unnecessary with AssemblyScript due to AS is just subset of TypeScript and can transpile to ordinal idiomtic javascript. Also AS already uses binaryen under the hood and can produce asm.js via --jsFile, -j command line.
https://news.ycombinator.com/item?id=32564105