As an anecdote: I had been running a Z80 emulator on my website (http://8bitworkshop.com) and I began to notice persistent 30-second delays on Firefox. It was difficult to track down, but I suspected the Z80 interpreter which had a gigantic switch statement. The optimizer must have been choking on it.
After refactoring each opcode handler into separate functions, it now runs with several subsecond delays on startup (as the various code paths are discovered and optimized, I suppose) and with no delays after a minute or so.
WebAssembly won't have this problem (neither does asm.js, but that's a different story...)
The generalish difference between JS and native code languages like C is about 10X. This varies from around 2X to 50X depending highly on what you're doing.
WASM should run at native speeds minus some special CPU instructions like vector stuff. So about as fast as highly optimized bytecode languages like Java, maybe 20% slower than optimized C.
One of the small things that may impact speed greatly, is that WASM has a real integer type, it isn't a float like JS has.
Some benchmarking has been talked about before [0], the upshot being C->WASM has a slowdown around 16-25ms. That's a hell of a lot faster than JS in a lot of places.
Unfortunately, as soon as you hook into the HTML APIs, like giving JS a result, you're back to JS speeds.
Well, possibly no faster than can currently be achieved by asm.js if the JIT likes you, but I think discussions of raw speed miss the point.
1. Parsing text based JS is much slower than parsing something like WASM.
2. Initialising data required for programs can take significant time in JS as that data is just a program that must be parsed and run.
3. Those first two points, along with better type support should help things get fast quicker, as the parser and JIT have less work to do.
4. In general JS comes with a lot of baggage that it's extremely hard to get rid of at this point, in many ways it's not really a great foundation to build other things on.
Now, WASM seems to provide a pretty good basis for building many things low level things on, but less useful for higher level languages which might want garbage collection or other facilities. I hope we'll end up with a successor or an evolution of it being the primary thing browsers interact with and JS simply being a language supported on it.
> WASM seems to provide a pretty good basis for building many things low level things on, but less useful for higher level languages which might want garbage collection
Would it be possible to implement a garbage collector in WASM? And could it be a concurrent garbage collector, using advanced techniques such as memory barriers?
It would be cool if we could run e.g. Haskell or Go in WASM. Or even C programs which rely on the Boehm collector.
Webscale? I don't know, and I am really unclear as to why people are already writing about webASM, there is hardly an agreed-upon standard so far. In my professional opinion as a Computational Scientist, I believe a LISP-like graphically-enabled DSL for the Web that worked simply and easily with: Web Forms, Graph Query for endpoints, and had a sensible GUI layering would be perfect for the next 200 years of screen.
I think that the issue comes in when people call it WebASM. ASM had different aims in 1960 than in 2017. In 1960 ASM was about minimizing register overlap and utilizing max CPU efficiency reels. Now, you have no idea what hardware your Web-whatever is going to run on, so how could you possibly optimize for CPU? The only real optimization would be optimizing software-engineer/developer attention+visualization and that would only come with an incredibly elegant breakdown of what screens need for a coder to be happy long into the future.
If there were some easy way for manufacturers to add "component" definitions for hardware devices, perhaps WebASM could become something amazing. However, the name ASM is likely to throw off too many would-be devs. At any rate, it's not meant to be assembly for the web, it's meant to be skeletal scaffolding for your amazing, native apps. Why else even bother.
I think you have a different framing of the problem most people excited about WASM have. It is not about talking directly to the hardware, just getting speed gain like you are. So this component idea seems to be coming from out of the blue and indicates to me you haven't paid webassembly much attention until now.
Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't need to match perfectly, it just needs to be similar enough, minimalistic and better than what we have now. The 'simple enough' part makes translation to native machine code easy enough and the minimal makes it easy for standards adoption. As for beating what we have now, you should read the article, because right now its javascript or nothing at all, and anything even vaguely more like a real machine can be optimized better than javascript.
Also, currently Chrome and Firefox support it. Currently Edge and Safari both support it in preview versions of the browsers. I am not sure where you are coming when you say "there is hardly an agreed-upon standard so far" because the four largest browser manufacturers have agreed enough to have 4 different working products or demos. Perhaps you could expand on that to let me know what you or if your information might have been old.
For example, I just googled briefly for the Chrome WASM platform status and to quote directly, "WebAssembly is in the early stages of language and spec design."
Although I would love to have a working model of WASM to play with, the fact is that it is a fresh idea and that any spec you see today will not be around in five years.
Wanting WASM to look like C/C++ is so hilariously misguided that I wonder if any programmers have been paying attention to language evolution in the past 5 decades.
Yes, Javascript is the best we can do at the moment, and that is truly sh. I do not disagree. My latest progress with regards to that is using something that compiles to JS, but there is still the indefatigable issue of having to use Javascript.
To me, WASM is an initiative to redesign the language behind the screen, and anything short would be inadequate because Javascript already does almost everything, just in an incredibly roundabout, piecemeal, poorly evolved way.
So, you are right in assuming I have not been paying attention to the news in the world of Web ASM, but I must also appeal to your logic and say that any of the news you read now is just theoretical debate. Maybe I should take up my issues with the language designers, as that may prove more fruitful.
Last night I tried a web assembly demo of Ogre3d, an open source 3d rendering engine. It worked in Chrome and Firefox. (I will put the link here after work, it is sitting in my personal email)
Whatever you are reading about the spec is not lining up with the reality of progress. We have two implementations now.
I encourage you to read the article, it is a decent primer for someone with your apparent level of knowledge. I assure you web assembly is not an attempt to replace javascript or make javascript look like C/C++, though you imply you believe such when you say things like "Wanting WASM to look like C/C++ is so hilariously misguided". I am not sure how language design factors into, if someone were so inclined they could compile JS to Wasm and have similar performance gains if the compiler optimized well.
Wasm is about nothing more than performance and they have nailed it. It is very fast compared to javascript, though it is slower than the C or C++ compiled to a native executable.
(Yes, I know, it depends. I'm just looking for a rough estimate.)