Since JS is already quite fast nowadays, how much faster will WASM typically be?
(Yes, I know, it depends. I'm just looking for a rough estimate.)
(Yes, I know, it depends. I'm just looking for a rough estimate.)
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...)
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.
Edit: an even longer list of proposed features. http://webassembly.org/docs/future-features/
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.
One big benefit will be being able to compile from an array of languages down to WebAssembly and maintain performance.
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.
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.
Its single-threaded performance is essentially native, but I don't have the numbers.
edit: /s
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.
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.
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.
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.
and sorry I forgot the link, I am writing a note to myself on real dead tree so I can forget it easily.
Space to jump, WADS to move, Q to draw and put away swords.