Re:Firefox’s new streaming and tiering compiler
by felipellrocha on Wednesday January 17, 2018 @01:33PM
(#16170443)
You don't really write wasm by hand. You use a higher level language that compiles to it. I wouldn't mind using go for the web, for example, if I wanted more performance, and it takes care of all the concerns you mentioned above for you...
Re:Firefox’s new streaming and tiering compiler
by rmrfrmrf on Wednesday January 17, 2018 @07:47PM
(#16173627)
> Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has?
Just wait until the JVM and Flash Runtime are ported to wasm. Downloaded and compiled on every page load :).
Re:Firefox’s new streaming and tiering compiler
by krapp on Wednesday January 17, 2018 @07:56PM
(#16173672)
>Just wait until the JVM and Flash Runtime are ported to wasm. Downloaded and compiled on every page load :).
Why that, instead of caching common components like any other web asset, or even having the browser act as a dependency manager?
There are bound to better solutions than "download and compile on every page load."
Re:Firefox’s new streaming and tiering compiler
by adrianN on Thursday January 18, 2018 @01:20AM
(#16175116)
Users could for example install plugins into their browser.
Re:Firefox’s new streaming and tiering compiler
by pjmlp on Thursday January 18, 2018 @01:25AM
(#16175140)
Re:Firefox’s new streaming and tiering compiler
by xg15 on Thursday January 18, 2018 @08:26AM
(#16176868)
> You really want to return to the days of each project having their own String libraries, because it's all built on top of raw asm?
If C++-to-WASM via clang catches on, I think this is exactly what will happen.
Re:Firefox’s new streaming and tiering compiler
by hateduser2 on Wednesday January 17, 2018 @01:35PM
(#16170458)
They’re adding all those things to wasm. I think you’re mistaken about the future.
Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has? Wasm doesn't even have any notion of Characters or Strings! You really want to return to the days of each project having their own String libraries, because it's all built on top of raw asm?
Webasm is not for JS-style code! You can't have "a little pre-compilation of JS to WebASM", that makes zero sense. We already have the incredibly complex JIT compilation of JS to x64/ARM/etc, which necessarily interacts with the garbage collector, type system, permissions & security, browser debugging/profiling tools, etc, all of which wasm does not have any notion.
Wasm is a raw C-ish sandbox environment for cross-compilation of static languages to expose their behavior to javascript, for straight-line CPU performance in number crunching as in games, software rendering, numerical analysis, compression/decompression, etc.