91–100 of 186 posts
Earlier quoted context omitted.
> Can we re-write parts of libraries like Vue or React in something that compiles to wasm, so that you get better performance as the user? For React, we would love to do this although it's not clear what parts of React would benefit from being moved to wasm right now.
Yeah, that's what I've been hearing through the grapevine. We'll see! I'd love to see it.
That being said, some of these optimization techniques completely took me by surprise. Defining the sort function as a cache lookup that converts the sorting template to a string and then builds an anonymous function out of that string which is finally used as the exported function seems, to me, like an extremely roundabout way to achieve inlining the comparator. And the argument-count adapter having such high overhead on V8 seems like something that should generate a warning for the developer.
The cache analysis and algorithmic improvements seemed fairly straight forward, but when you're at the point of having to manually implement memory buffers to alleviate GC pressure, you're diving below the level of abstraction that the language itself provides you. At that point, I think the argument to switch to a language designed to operate at that level of abstraction holds some sway.
The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…
Once it tries to start inlining on the client side, that will open the floodgates to other optimizations.
Earlier quoted context omitted.
> So instead of implementing a better language, they also used JS They did implement a better language, Dart. But it was too late, like you said. Maybe we'll have a change of using it for mobile apps with Flutter.
Dart came way, way later. And it was a new language, while they could have just used an existing one. They could have implemented lua, ruby, Python, anything with a good track record. With the millions spent on V8 with those geniuses working on it, can you imagine how fast one of those language would have become ? The tooling it would have had ?
They failed miserably.
And several other projects failed miserably at the same thing as well.
Either way, speed was not the main reason they created Dart.
Dart was designed for writing large web apps.
Dart's top design constraints was good interop with JavaScript meaning transpilation of Dart to decent JavaScript and consumption of existing JavaScript libraries from Dart.
I repeat: top design goal.
You can't take a language (be it Python, Ruby or Lua) that was not design with that constraint in mind and magically make it work.
There are transpilers from those languages to JavaScript but they are toys.
You just can't reconcile Python semantics with JavaScript semantics in a reasonable way.
So they did the next best thing: they designed a better Java/C# while keeping JavaScript interop as a priority.
Now Dart is morphing because the top design goal is to make it the best language for cross-platform mobile (i.e. iOS and Android) apps, which requires different trade-offs.
Maybe there should be a tool from linters or VMs to warn against arguments adaptation, monomorphisation. For the rest it is a lot of know how is JS that is for free in with more performance minded languages. At the end with the optimized JS is is 4 times faster, but still 6 times faster in WASM it seems.
It's only necessary in edge cases of super-hot code, avoiding argument adaptation "because performance" is a bad idea. It's also a v8 specific weakness, it's not hard to imagine a small fix getting rid of the performance penalty.
So in Rust you would be forced to write it the way you consider to be "bad idea".
Many people think that default function arguments are a bad idea and languages like Rust or C or Go or Java don't even have them.
So much work to achieve what should be default behavior :-/ How did we end up in wasting so much time on trivialities?
When JS came out, it was poorly designed, but nobody cared because we used it only to make snowflakes appear on the web page. Then MS gave us AJAX and 37 signals made it popular, until apps like gmail made it so mainstream it was impossible to go back to old static pages. But it was too late. The shitty language we had was the only one available everywhere to do dynamic web pages now. IE would not move, and Firefox a…
Google maps. When Google maps first came out as a beta/preview and I first loaded it up, it was magic. Not magic as in the "this is wonderful" sense (it was) but in the "any sufficiently advanced technology is indistinguishable from magic" sense. I truly didn't understand how what they were doing was possible for the first few minutes. I'm pretty sure the feeling was the same with all the other programmers and sysadmins at the ISP I worked at.
Gmail might have clued a lot of people in as to how you could make webpages more dynamic, but Maps truly showed us how you could make a web application every bit as fluid and usable (if not more so) than a local one in the right circumstances.
I recently discovered that a JavaScript implementation of radix sort up to four times faster than the the built-in sorting algorithms for TypedArrays[0][1][2]. Imagine how much faster a good WASM implementation could be!
It also makes me wonder why browsers don't make use of the guaranteed memory layout of typed arrays to use faster native algorithms. Sure, Typed Arrays have to support the sorting API, which is comparison based and works with closures. But why not detect when someone calls sort() without any further arguments, and make that very common case use faster native code?
Because for me, this difference in performance made a difference: I am animating plots where I need to sort more than 100k elements each frame, and sort eating up 5ms or 20ms is the difference between choppy and smooth animations.
[0] https://run.perf.zone/view/radix-sort-uint32-1000-items-type...
[1] https://run.perf.zone/view/radix-sort-uint32-1000000-items-t...
[2] https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs-fil...
The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…
Wasm will turn into an optimizing jit. Or it will run slow or deliver massive binaries if it is the equivalent of statically linked. I don't really see a way around that. Once it tries to start inlining on the client side, that will open the floodgates to other optimizations.
The compiler would then spit out eighteen different versions and the right one would be downloaded by the user.
I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+ru…
Yes. I wrote about this in some detail 2 years ago, Jitterdämmerung: