17 ms·

Maybe you don't need Rust and WASM to speed up your JS

600 points by youngtaff 9y ago

FeepingCreature 9y ago
What a well-designed and well-researched article!
lmm 9y ago
I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.
- k__ 9y ago
  What about BuckleScript?
  - lmm 9y ago
    My impression with Scala.js is that it's nice (and maybe the best option going at the moment) but you're still kind of a second-class citizen, which I'm hoping WASM will change. I imagine the experience with BuckleScript would be similar. (Whereas Typescript feels a lot more first-class, but at the cost of having to still be semantically very close to Javascript).
    - maxxxxx 9y ago
      I am looking into TypeScript right now and I think it's just a hard problem to integrate a typed language into a dynamic environment like JavaScript. The transitions between JavaScript and the typed language will always be tricky and error prone.
      - zaphar 9y ago
        Typescript does a better job than most that I've seen.
        maxxxxx 9y ago
        Agreed. Anders Hejlsberg has repeatedly shown excellent taste in programming languages. See C#, Delphi and Turbo Pascal.
        wereHamster 9y ago
        PureScript doesn't do a bad job either. And even Haskell (GHCJS) has good FFI into JavaScript (I'd argue even better than PureScript!). How bad can you make interop between a higher-level language and JS? What are the bad examples?
- Too 9y ago
  What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.
  - wereHamster 9y ago
    Any language that doesn't have first-class support for ADTs is a waste of my time. And I say that as someone who's working with TypeScript all day long, and try to push it in my team, even though it sometimes requires verbose code and boilerplate. But I take that over plain JS any day. It took long enough for my coworkers to recognise the benefit of a type system. Can't push them too hard too far too quickly.
    - alangpierce 9y ago
      When you say ADTs, do you mean algebraic data types or abstract data types? My impression has been that TypeScript is quite good at algebraic data types (i.e. tagged unions). You need to use normal conditionals like if/switch or your own function instead of syntactic support for pattern matching, but IMO the static analysis makes it work out pretty well.
      - catnaroek 9y ago
        It is good at neither. Union types and sum types are veeery different from each other.
        alangpierce 9y ago
        To be clear, I was talking about tagged unions; TypeScript supports both tagged and untagged unions[1]. My understanding is that "tagged unions" and "sum types" are the same thing, and Wikipedia[2] seems to agree. [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://en.wikipedia.org/wiki/Tagged_union https://en.wikipedia.org/wiki/Tagged_union
- faitswulff 9y ago
  One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?
  - ehsanu1 9y ago
    Correctness is typically checked long before code generation happens. This does mean the code generation backend must be trusted, whether the target be x86 or wasm. Just as you have to trust CPUs to not expose processes' memory to each other (oops).
    - eastWestMath 9y ago
      Typed assembly is a thing - it’s mainly to ensure the compiler itself is correct, but it does give stronger guarantees. I think Frank Pfenning at CMU has written a language that’s dependently typed all the way down - so it’s IR and assembly are both dependently typed.
  - perrylaj 9y ago
    edit: I misread the question, my comment was geared toward languages transpiled to JS. It's compile-time safety. Virtually none of the type knowledge exists in the runtime. Still, it's far better than nothing, with the self-documenting nature of typed code being one of the biggest wins IMO.
  - rhaps0dy 9y ago
    >how does correctness transfer? The same way it transfers when the language is compiled to x86 instructions! By adding a pre-written and pre-compiled runtime.
    - skolemtotem 9y ago
      No correctness isn't usually ensured with a runtime in these languages with stronger type systems, it's usually done with static analysis on an intermediate representation at compile-time.
Animats 9y ago
Source maps are a debug tool. Why does the performance matter? (And if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong.)
- tromey 9y ago
  > Source maps are a debug tool. Why does the performance matter? If the source map decoder is slow, then the debugger feels slow.
- orf 9y ago
  Tools like Sentry parse them, and need consistent fast performance in this area. Other debugging tools use them. Your statement in brackets seems very "those damn kids"-ish. You need to "minify" your JS files even if you're shipping a small amount of JS, because loading performance matters and JS minifies very well.
  - masklinn 9y ago
    Browsers also use them do display "expanded" code in the console and debugger.
- bluetwo 9y ago
  > if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong. 100% agree.
  - bluetwo 9y ago
    Make that 101% agree.
    - bluetwo 9y ago
      102%
bitL 9y ago
So much work to achieve what should be default behavior :-/ How did we end up in wasting so much time on trivialities?
- sametmax 9y ago
  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 and Opera were the underdog, spending their resources on more important things. So nobody tried to implement a better existing language. When Google faced the challenge of creating chrome, they had to be compatible. So instead of implementing a better language, they also used JS, and injected millions of dollars into making the V8 so it has decent performances. After that, JS was usable, and so we moved on.
  - kbenson 9y ago
    > apps like gmail made it so mainstream it was impossible to go back to old static pages 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.
  - petre 9y ago
    > 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.
themihai 9y ago
I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages? As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away from this goal(i.e. lack of web APIs/DOM access makes it useless for web dev).
- deleted 9y ago
  [deleted]
- maxxxxx 9y ago
  It seems to that WASM is more suitable for non-browser work like Node.
  - ISV_Damocles 9y ago
    No offense meant, but that couldn't be more wrong. If you're writing for the server, you can already use whichever language best suits the problem at hand. WASM will eventually allow the same choice in the browser. The extent to which WASM could be used in the Node ecosystem would essentially be an indictment of how badly the Node community has bungled FFI. (node-ffi[0] should absolutely be added to Node core, not be independently maintained and always trailing compatibility with newer node releases, right now you have to choose between security or compatibility) [0]: https://github.com/node-ffi/node-ffi https://github.com/node-ffi/node-ffi
    - maxxxxx 9y ago
      No offense taken! I am pretty new to the JS world. "WASM will eventually allow the same choice in the browser." When will that actually be? That's the big question.
      - aschampion 9y ago
        Since November WASM is enabled by default in the major browsers now: https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm
austincheney 9y ago
I thought all the benchmarks indicated that WASM is still slower than JS. That being said the only performance improvements offered by WASM is if it doesn't for garbage collection for consistence execution. WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page.
- madflame991 9y ago
  > WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page. You don't really need wasm for that, do you? Anything compiles to JS nowadays and you'd actually get easier access to the DOM and GC and support for source maps (are those working for wasm yet?)
  - austincheney 9y ago
    Flash has always been better for media and games than JavaScript. WASM fills that niche.
- azakai 9y ago
  > I thought all the benchmarks indicated that WASM is still slower than JS. No, wasm is almost always faster than JS, and that has been the case for a while. Maybe you're thinking about some very specific aspect of performance or benchmark? (For example, wasm->JS calls might be slower than JS->JS calls in some cases.)
hokkos 9y ago
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.
- bcoates 9y ago
  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.
  - kjksf 9y ago
    Given that this contrasts a JavaScript implementation with Rust implementation compiled to WASM: my 5 minute investigation shows that Rust doesn't have optional arguments at all. 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.
    - qarioz 9y ago
      you get creative, passing map, passing Option. it's very trivial to do.
anp 9y ago
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+rust/c++ is interesting in part because you can get so much more predictable performance out of the box. When the performance comes from language features instead of VM-specific optimizations the performance might be easier to maintain across revisions and hopefully will be less subject to regression from VM changes.
- jandem 9y ago
  I work on SpiderMonkey JS performance (and got mentioned in the article for fixing a perf bug!) and this is exactly the point I wanted to make. If you're not a VM engineer, it's much harder to write fast JS. Wasm also gives you much more predictable performance across engines, without requiring (often engine-specific) 'hacks' like function cloning.
  - Jasper_ 9y ago
    From what I can tell, doing basic things like a property get on an object in WASM/host-bindings will require a spill to function, with no chance of specialization: https://github.com/WebAssembly/host-bindings/issues/11#issuecomment-352577514 https://github.com/WebAssembly/host-bindings/issues/11#issue... If you think the assembly in this article is bad, WASM/host-bindings appear to be even worse.
    - luke_wagner 9y ago
      That comment (which I made) explains why probably the best we can expect for wasm accessing normal JS objects is the same level of speed as a modern JS engine's "tier 1"/"baseline" JIT. But the Rust code discussed in the OP wasn't accessing JS objects, it was accessing Rust memory which lives in wasm's "linear memory", so I don't see how my comment really disagrees with what jandem or dikaiosune are saying.
bitdivision 9y ago
I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?
- steveklabnik 9y ago
  A comment upthread did the math: > The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.
  - mraleph 9y ago
    The math is not that obvious because Rust implementation does not match 1-1 what baseline JS version was doing (e.g. it sorts only generatedMappings and not originalMappings). I will do measurements later to compare and update the post.
    - steveklabnik 9y ago
      Sounds good! I enjoyed the article :)
  - jjnoakes 9y ago
    With the caveat that it's apples-to-oranges (algorithmic changes to the JavaScript version (~4x) are not in the Rust version (~5.9x)).
solidsnack9000 9y ago
This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds of thousands Mapping objects, which puts considerable pressure on GC - in reality we don’t really need those objects to be objects... First of all, I changed Mapping from a normal object into a wrapper that points into a gigantic typed array... This suggests to me that we are no longer programming the way one usually does in a dynamically typed, garbage collected language -- and thus it might still be the right decision to move to something like Rust (or Swift or Go) where there is considerably more control over allocation. The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. There are benefits to having all ones code in the same language; but there are also benefits to switching languages to obtain better ergonomics and safety properties.
- vvanders 9y ago
  Yeah, this is also where value types are really awesome and you can get the same results from(assuming no strings). Sadly other than C# most of the mainstream GC'd languages don't include them yet as a feature.
  - kevingadd 9y ago
    There was even a firm proposal for user-defined value types in JS, but asm.js (and now wasm) took all the air out of the room - though I'm not sure it would have ever gotten implemented in all the browsers anyway, since only perf-sensitive developers care about it. EDIT: I noticed it's actually mentioned in a footnote in the article - the Typed Objects API was really nice, I had a chance to use it for a prototype.
- jandem 9y ago
  > The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: https://twitter.com/mraleph/status/965616993310265344 https://twitter.com/mraleph/status/965616993310265344
greenhouse_gas 9y ago
The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back there was a discussion on how programming is hard nowadays. Really, programming is more accessible than ever. What is hard is the "black magic" that's becoming more and more prevalent, most of which is implementation defined, that everyone is expected to know (and really, most don't really know anything. They just repeat rumors they read about online, often years out of date).
- kibwen 9y ago
  The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).
  - abritinthebay 9y ago
    They will diverge about as much as JS does, that will hardly be a surprise
    - kibwen 9y ago
      I doubt it. If further optimizing pre-optimized assembly were that easy (or that valuable), then we'd also expect to see more tools for postprocessing compiled binaries. (Just because WASM is a bytecode format doesn't mean it's comparable to Java bytecode and Java's JITs; javac isn't an optimizing compiler.) I'd be happy if anyone actually working on a WASM interpreter could chime in regarding expected optimization potential.
- Pxtl 9y ago
fulafel 9y ago
Next steps: leverage web workers and GLSL?
hitekker 9y ago
Irrelevant and maybe a bit small-minded, but the font of the article is too squished to be pleasantly readable.
- mraleph 9y ago
  Not irrelevant. Question for you, is this more legible: https://twitter.com/mraleph/status/965686742614462466 https://twitter.com/mraleph/status/965686742614462466 I can update CSS if that helps. UPD. Updated CSS to use non monospace fonts for the body.
  - hitekker 9y ago
    This is better by far. I'd be interested if there's a better combination of code + paragraph font, but otherwise the only other minor adjustment I'd make is increasing the padding / margins between text and code. Thanks for taking criticism in a healthy way.
jokoon 9y ago
For me the purpose of wasm would not be just performance, but to let me avoid javascript entirely. Javascript is already very fast, but compiling to javascript feels awkward.
- mraleph 9y ago
  I don't think you can avoid JavaScript even with WASM - and WASM in it's current form is, for some languages, a worse compilation target than JavaScript.
  - jokoon 9y ago
    Well sure it doesn't support the DOM yet, but I think the design goal of WASM is to do just that. Since the beginning of computers, it should be trivial to distribute programs online efficiently. The web is already platform dependent, but it also need to be fast and language independent.
alangpierce 9y ago
For writing high-performance JavaScript, I'm really hoping that AssemblyScript takes off[1]. The project is still a bit in early stages, but theoretically, it can have the same role as Cython: you write JS/TS code, find the slow parts, and get perf improvements by adding stricter types to your code and changing your code to not use dynamic JS features. You can stay pretty much in JS rather than having to switch to a completely new language to get predictable fast performance. [1] https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript
patientplatypus 9y ago
So... I'm a (junior/so-so) react dev. I like the language, I probably could get better at it but I've gotten to the point where I like the sound of my own music. That said, my question is the following. There seems to be a lot of resources on the web of the type "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. However, I don't see a lot of the things that are in libraries like Vue and React that offer me SPA, fast development time and component (OR!) functional pattern design (I won't mention the ability to add npm packages, because yeah, Rust/WASM doesn't have an ecosystem yet, so that might be punching a bit below the belt). Is there anyone out there making a React like or "eco-system builder"-esque platform that would give me a lot of the benefits I'm seeing with React but with increased performance? Also, I've done some low level programming before and think that Rust is very cool for that (yay memory safety! yay error messaging (no seriously yay)!). However, and I may be betraying my ignorance here, if I want to animate a div to fly across the page, am I going to have to write lots of low level code to do that? If that's the case, and development time suffers to eek out that extra bit of performance, I can't see this as having much utility outside of niche fields like game development. I don't mean to be overly critical mind as I'm still (and probably will always be) a bit of a n00b. I'd love it if somebody would point me at some resources that I could burn a weekend on, if I thought the juice was worth the squeeze. I'm just not sure I know enough to know if this is something that I could be productive in (some day).
- steveklabnik 9y ago
  > "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. It is very early days. More to come... > However, I don't see a lot of the things that are in libraries like Vue and React Yes. There's not too many of these yet; there are some though. For example, https://github.com/DenisKolodin/yew https://github.com/DenisKolodin/yew There's also the inverse: 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? I know of at least one major SPA framework that's doing this. Don't want to spill the beans too much, even though it is technically public knowledge. That said, that's how I think wasm will impact the lives of most JS programmers: as technology that underpins the libraries they use to make them better. Unless you want to, or unless you want to write a high-performance library, I wouldn't expect wasm to really change the way most JS programmers operate. It's abut augmenting JS, not replacing it. > if I want to animate a div to fly across the page, am I going to have to write lots of low level code to do that? That depends entirely on the library! > I'd love it if somebody would point me at some resources that I could burn a weekend on They're sorta scattered all over the place right now. Such is life for early adopters. More will come as stuff matures. Don't under-estimate how much this will change as the tooling gets built out, for example.
adamnemecek 9y ago
It's not just speedup it's also about writing backend and front-end in one language. But the speedup is real too.
ef4 9y ago
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 consistent performance every time it runs. It's not that plain Javascript can't be as fast -- it's that plain Javascript has high variance, and maintaining engine-internals-aware optimization in a big team with a long-lived app is impractical.
- seeekr 9y ago
  It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool. Such a tool would give you the benefits you're praising about the WASM compilation workflow: Separately maintained, engine-specific optimizations that can be applied at build-time and don't mess up the maintainability of your source code.
  - ptx 9y ago
    But what if I want to target all the engines, including future ones? The compiler could compile separate versions for each engine, I guess, and you could choose which one to load at runtime based on the UserAgent string ... but even then everyone would have to recompile their websites every time a new browser version comes out. The advantage of WebAssembly is supposed to be (I think) that it's simpler and will give more consistency between browsers, so browser behaviour will be less surprising, and you can thus get away with compiling a single version. And if you take this approach of compiling JavaScript to a simple and consistent subset of JavaScript that can be optimized similarly in all engines, you'd end up more or less targeting asm.js, the predecessor to WebAssembly. :)
  - ef4 9y ago
    You're basically describing asm.js -- a subset of javascript that is known to be easy for engines to turn directly into native code and execute, that you can use as a compilation target. The difference between asm.js and WASM is mostly just that WASM is more compact and easier to parse, while asm.js is a more gradually compatible upgrade story.
eslaught 9y ago
> Is it better to quick-sort one array with 100K elements or quick-sort 3333 30-element subarrays? > A bit of mathematics can guide us (100000log100000 is 3 times larger than 3333×30log30) You have to be careful doing this kind of analysis. Big-O is explicitly about what happens for large values of N. It is traditional to leave off smaller factors, because they don't matter at the limit of N going to infinity. There is implicitly a constant coefficient on each component, and that might matter more at small N. So e.g. I've seen cases that were O(N^2 + N), and which of course you'd traditionally write as O(N^2), but where the O(N) factor mattered more at small values of N because of constant factors. Depending on whether you cared more about small or large values of N, would guide whether you'd actually want to go after the O(N^2) factor or not. If you just blindly went for the larger factor, you could waste a lot of time and not actually accomplish anything.
NiceGuy_Ty 9y ago
This is a well written article, and I absolutely agree with the idea that profiling and analysis is more important than language choice in order to eke out performance wins. 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.
vortico 9y ago
This is a broad, naive question, but the number of responses and upvotes on this post suggest to me that many people actually need to speed up their JS. I've never once come across this problem in web app development. The bottleneck is always DOM rendering like layout changes, networking, handling large WebGL vertex buffers for video games, etc. In which use cases is JS performance significant?
- acemarke 9y ago
  In this case, the sourcemaps library isn't normally running as part of user application code. It's primarily used by the browser's DevTools, and server-side build tools like Webpack and Gulp. The faster sourcemaps can be parsed and manipulated, the faster the DevTools and build tools will execute.
vanderZwan 9y ago
Tangent: I see that the author focused on improving sorting algorithms, and also at some point switches to a Uint8Array (although not in the sorting part). 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-typed-and-plain-array-1510082514775 https://run.perf.zone/view/radix-sort-uint32-1000-items-type... [1] https://run.perf.zone/view/radix-sort-uint32-1000000-items-typed-and-plain-array-1510082642142 https://run.perf.zone/view/radix-sort-uint32-1000000-items-t... [2] https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs-fill-in-place-1510007933053 https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs-fil...
- spiralx 9y ago
  On my OnePlus 5T the standard sort() was twice as fast as the radix sort for the UInt8 array, but it was only 30% slower for the Float64 and regular arrays, whereas sort() was hundreds of times slower - strange...
z3t4 9y ago
We should be more wary about premature optimizations, like in the article where caching in the original code made it slower! Always measure! Write naive code and measure, the JavaScript engines are very good at optimization, especially V8 and the others are catching up. However when I do optimize JavaScript code I often get 10-100x performance. Usually by writing better algorithms. Eg no "black magic". So the original code in the article is not that bad, considering he "only" got 4x performance. Moving to another programming language / WASM for less then 2x performance is not worth it - unless you hate JavaScript.
- Narishma 9y ago
  > like in the article where caching in the original code made it slower! Caching could have been originally faster, but became slower thanks to the continual improvement of the Javascript VMs.
eximius 9y ago
I'm continually surprised by the Rust -> WASM pressure. I see projects like Redox and Servo and ripgrep and Tokio and, well, native or systems level things being it's true calling. I don't want to write a webapp in Rust. It'll always be second class (though maybe that won't be a problem if the WASM apis get good enough...).
- steveklabnik 9y ago
  Think of it this way: wasm is pretty similar in many ways to an embedded platform. Rust wants to be good at embedded, so making Rust good at wasm fits. A lot of the work is identical.
  - eximius 9y ago
    I think that is a very post-hoc rationalization to justify the silliness that is/has been eating the JS world (emscripten and asm.js show that this sort of thing has been going on for a while), but is an entirely valid reason to indulge it for free interest and experience. +1
    - steveklabnik 9y ago
      I don't think it's a reason that wasm exists, but I do think it's one of the (multiple) reasons for us to invest in making Rust -> wasm an excellent experience.
abritinthebay 9y ago
I’m confused as to why people think this isn’t generally applicable to JS here. Very few of these changes are VM specific or likely to change (or any more so than WASM implementations) - choose your algorithm carefully - make sure you’re paying attention to the data you’re applying the algorithm to is a good fit - pay attention to arity & GC pressure. None of these are hard to do in JS & most of the VM debugging was to help identify problems in existing unoptimized code. The rest are lessons you can take into ANY JS data processing.
staticassertion 9y ago
Awesome. I think it makes a lot of sense to explore new algorithmic approaches before choosing to reimplement in a new language - and thankfully these are not mutually exclusive. To those saying "these are implementation defined optimizations" etc - you do the same exact thing in rust. I know some rust code is 'fast' and some is 'slow' and I have to understand rust and to some extent the state of llvm + rust. This is simply part of writing fast code, no matter the platform or language. Nice writeup!
sehugg 9y ago
I rely heavily on a decent JS performance baseline for http://8bitworkshop.com/ http://8bitworkshop.com/, and I also rely on asm.js / WASM. But I need different things from them. For JS, I need consistency and stability, because I'm dynamically generating code. Usually I'm pretty satisfied, but sometimes after recompiling code I get a huge performance hit for no reason. For WASM, I know I have stability, but I need faster load times. On my Chromebook, for example, it takes 10-20 seconds just to load the WebAssembly. If this problem is solved, I might move everything performance-sensitive over to WASM eventually.

600 points by youngtaff 9y ago

What a well-designed and well-researched article!

lmm 9y ago

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

k__ 9y ago
What about BuckleScript?
- lmm 9y ago
  My impression with Scala.js is that it's nice (and maybe the best option going at the moment) but you're still kind of a second-class citizen, which I'm hoping WASM will change. I imagine the experience with BuckleScript would be similar. (Whereas Typescript feels a lot more first-class, but at the cost of having to still be semantically very close to Javascript).
  - maxxxxx 9y ago
    I am looking into TypeScript right now and I think it's just a hard problem to integrate a typed language into a dynamic environment like JavaScript. The transitions between JavaScript and the typed language will always be tricky and error prone.
    - zaphar 9y ago
      Typescript does a better job than most that I've seen.
      - maxxxxx 9y ago
        Agreed. Anders Hejlsberg has repeatedly shown excellent taste in programming languages. See C#, Delphi and Turbo Pascal.
      - wereHamster 9y ago
        PureScript doesn't do a bad job either. And even Haskell (GHCJS) has good FFI into JavaScript (I'd argue even better than PureScript!). How bad can you make interop between a higher-level language and JS? What are the bad examples?
Too 9y ago
What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.
- wereHamster 9y ago
  Any language that doesn't have first-class support for ADTs is a waste of my time. And I say that as someone who's working with TypeScript all day long, and try to push it in my team, even though it sometimes requires verbose code and boilerplate. But I take that over plain JS any day. It took long enough for my coworkers to recognise the benefit of a type system. Can't push them too hard too far too quickly.
  - alangpierce 9y ago
    When you say ADTs, do you mean algebraic data types or abstract data types? My impression has been that TypeScript is quite good at algebraic data types (i.e. tagged unions). You need to use normal conditionals like if/switch or your own function instead of syntactic support for pattern matching, but IMO the static analysis makes it work out pretty well.
    - catnaroek 9y ago
      It is good at neither. Union types and sum types are veeery different from each other.
      - alangpierce 9y ago
        To be clear, I was talking about tagged unions; TypeScript supports both tagged and untagged unions[1]. My understanding is that "tagged unions" and "sum types" are the same thing, and Wikipedia[2] seems to agree. [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://en.wikipedia.org/wiki/Tagged_union https://en.wikipedia.org/wiki/Tagged_union
faitswulff 9y ago
One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?
- ehsanu1 9y ago
  Correctness is typically checked long before code generation happens. This does mean the code generation backend must be trusted, whether the target be x86 or wasm. Just as you have to trust CPUs to not expose processes' memory to each other (oops).
  - eastWestMath 9y ago
    Typed assembly is a thing - it’s mainly to ensure the compiler itself is correct, but it does give stronger guarantees. I think Frank Pfenning at CMU has written a language that’s dependently typed all the way down - so it’s IR and assembly are both dependently typed.
- perrylaj 9y ago
  edit: I misread the question, my comment was geared toward languages transpiled to JS. It's compile-time safety. Virtually none of the type knowledge exists in the runtime. Still, it's far better than nothing, with the self-documenting nature of typed code being one of the biggest wins IMO.
- rhaps0dy 9y ago
  >how does correctness transfer? The same way it transfers when the language is compiled to x86 instructions! By adding a pre-written and pre-compiled runtime.
  - skolemtotem 9y ago
    No correctness isn't usually ensured with a runtime in these languages with stronger type systems, it's usually done with static analysis on an intermediate representation at compile-time.

Animats 9y ago

Source maps are a debug tool. Why does the performance matter? (And if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong.)

tromey 9y ago
> Source maps are a debug tool. Why does the performance matter? If the source map decoder is slow, then the debugger feels slow.
orf 9y ago
Tools like Sentry parse them, and need consistent fast performance in this area. Other debugging tools use them. Your statement in brackets seems very "those damn kids"-ish. You need to "minify" your JS files even if you're shipping a small amount of JS, because loading performance matters and JS minifies very well.
- masklinn 9y ago
  Browsers also use them do display "expanded" code in the console and debugger.
bluetwo 9y ago
> if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong. 100% agree.
- bluetwo 9y ago
  Make that 101% agree.
  - bluetwo 9y ago
    102%

bitL 9y ago

So much work to achieve what should be default behavior :-/ How did we end up in wasting so much time on trivialities?

sametmax 9y ago
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 and Opera were the underdog, spending their resources on more important things. So nobody tried to implement a better existing language. When Google faced the challenge of creating chrome, they had to be compatible. So instead of implementing a better language, they also used JS, and injected millions of dollars into making the V8 so it has decent performances. After that, JS was usable, and so we moved on.
- kbenson 9y ago
  > apps like gmail made it so mainstream it was impossible to go back to old static pages 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.
- petre 9y ago
  > 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.

themihai 9y ago

I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages? As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away from this goal(i.e. lack of web APIs/DOM access makes it useless for web dev).

deleted 9y ago
[deleted]
maxxxxx 9y ago
It seems to that WASM is more suitable for non-browser work like Node.
- ISV_Damocles 9y ago
  No offense meant, but that couldn't be more wrong. If you're writing for the server, you can already use whichever language best suits the problem at hand. WASM will eventually allow the same choice in the browser. The extent to which WASM could be used in the Node ecosystem would essentially be an indictment of how badly the Node community has bungled FFI. (node-ffi[0] should absolutely be added to Node core, not be independently maintained and always trailing compatibility with newer node releases, right now you have to choose between security or compatibility) [0]: https://github.com/node-ffi/node-ffi https://github.com/node-ffi/node-ffi
  - maxxxxx 9y ago
    No offense taken! I am pretty new to the JS world. "WASM will eventually allow the same choice in the browser." When will that actually be? That's the big question.
    - aschampion 9y ago
      Since November WASM is enabled by default in the major browsers now: https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm

austincheney 9y ago

I thought all the benchmarks indicated that WASM is still slower than JS. That being said the only performance improvements offered by WASM is if it doesn't for garbage collection for consistence execution. WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page.

madflame991 9y ago
> WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page. You don't really need wasm for that, do you? Anything compiles to JS nowadays and you'd actually get easier access to the DOM and GC and support for source maps (are those working for wasm yet?)
- austincheney 9y ago
  Flash has always been better for media and games than JavaScript. WASM fills that niche.
azakai 9y ago
> I thought all the benchmarks indicated that WASM is still slower than JS. No, wasm is almost always faster than JS, and that has been the case for a while. Maybe you're thinking about some very specific aspect of performance or benchmark? (For example, wasm->JS calls might be slower than JS->JS calls in some cases.)

hokkos 9y ago

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.

bcoates 9y ago
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.
- kjksf 9y ago
  Given that this contrasts a JavaScript implementation with Rust implementation compiled to WASM: my 5 minute investigation shows that Rust doesn't have optional arguments at all. 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.
  - qarioz 9y ago
    you get creative, passing map, passing Option. it's very trivial to do.

anp 9y ago

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+rust/c++ is interesting in part because you can get so much more predictable performance out of the box. When the performance comes from language features instead of VM-specific optimizations the performance might be easier to maintain across revisions and hopefully will be less subject to regression from VM changes.

jandem 9y ago
I work on SpiderMonkey JS performance (and got mentioned in the article for fixing a perf bug!) and this is exactly the point I wanted to make. If you're not a VM engineer, it's much harder to write fast JS. Wasm also gives you much more predictable performance across engines, without requiring (often engine-specific) 'hacks' like function cloning.
- Jasper_ 9y ago
  From what I can tell, doing basic things like a property get on an object in WASM/host-bindings will require a spill to function, with no chance of specialization: https://github.com/WebAssembly/host-bindings/issues/11#issuecomment-352577514 https://github.com/WebAssembly/host-bindings/issues/11#issue... If you think the assembly in this article is bad, WASM/host-bindings appear to be even worse.
  - luke_wagner 9y ago
    That comment (which I made) explains why probably the best we can expect for wasm accessing normal JS objects is the same level of speed as a modern JS engine's "tier 1"/"baseline" JIT. But the Rust code discussed in the OP wasn't accessing JS objects, it was accessing Rust memory which lives in wasm's "linear memory", so I don't see how my comment really disagrees with what jandem or dikaiosune are saying.

bitdivision 9y ago

I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?

steveklabnik 9y ago
A comment upthread did the math: > The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.
- mraleph 9y ago
  The math is not that obvious because Rust implementation does not match 1-1 what baseline JS version was doing (e.g. it sorts only generatedMappings and not originalMappings). I will do measurements later to compare and update the post.
  - steveklabnik 9y ago
    Sounds good! I enjoyed the article :)
- jjnoakes 9y ago
  With the caveat that it's apples-to-oranges (algorithmic changes to the JavaScript version (~4x) are not in the Rust version (~5.9x)).

solidsnack9000 9y ago

This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language. At the end of the article, the author wisely chooses to move some objects out of the control of the GC: We are allocating hundreds of thousands Mapping objects, which puts considerable pressure on GC - in reality we don’t really need those objects to be objects... First of all, I changed Mapping from a normal object into a wrapper that points into a gigantic typed array... This suggests to me that we are no longer programming the way one usually does in a dynamically typed, garbage collected language -- and thus it might still be the right decision to move to something like Rust (or Swift or Go) where there is considerably more control over allocation. The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. There are benefits to having all ones code in the same language; but there are also benefits to switching languages to obtain better ergonomics and safety properties.

vvanders 9y ago
Yeah, this is also where value types are really awesome and you can get the same results from(assuming no strings). Sadly other than C# most of the mainstream GC'd languages don't include them yet as a feature.
- kevingadd 9y ago
  There was even a firm proposal for user-defined value types in JS, but asm.js (and now wasm) took all the air out of the room - though I'm not sure it would have ever gotten implemented in all the browsers anyway, since only perf-sensitive developers care about it. EDIT: I noticed it's actually mentioned in a footnote in the article - the Typed Objects API was really nice, I had a chance to use it for a prototype.
jandem 9y ago
> The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: https://twitter.com/mraleph/status/965616993310265344 https://twitter.com/mraleph/status/965616993310265344

greenhouse_gas 9y ago

The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari). So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever. This, honestly, is what I hate with modern dev. A few days back there was a discussion on how programming is hard nowadays. Really, programming is more accessible than ever. What is hard is the "black magic" that's becoming more and more prevalent, most of which is implementation defined, that everyone is expected to know (and really, most don't really know anything. They just repeat rumors they read about online, often years out of date).

kibwen 9y ago
The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).
- abritinthebay 9y ago
  They will diverge about as much as JS does, that will hardly be a surprise
  - kibwen 9y ago
    I doubt it. If further optimizing pre-optimized assembly were that easy (or that valuable), then we'd also expect to see more tools for postprocessing compiled binaries. (Just because WASM is a bytecode format doesn't mean it's comparable to Java bytecode and Java's JITs; javac isn't an optimizing compiler.) I'd be happy if anyone actually working on a WASM interpreter could chime in regarding expected optimization potential.
Pxtl 9y ago

fulafel 9y ago

Next steps: leverage web workers and GLSL?

hitekker 9y ago

Irrelevant and maybe a bit small-minded, but the font of the article is too squished to be pleasantly readable.

mraleph 9y ago
Not irrelevant. Question for you, is this more legible: https://twitter.com/mraleph/status/965686742614462466 https://twitter.com/mraleph/status/965686742614462466 I can update CSS if that helps. UPD. Updated CSS to use non monospace fonts for the body.
- hitekker 9y ago
  This is better by far. I'd be interested if there's a better combination of code + paragraph font, but otherwise the only other minor adjustment I'd make is increasing the padding / margins between text and code. Thanks for taking criticism in a healthy way.

jokoon 9y ago

For me the purpose of wasm would not be just performance, but to let me avoid javascript entirely. Javascript is already very fast, but compiling to javascript feels awkward.

mraleph 9y ago
I don't think you can avoid JavaScript even with WASM - and WASM in it's current form is, for some languages, a worse compilation target than JavaScript.
- jokoon 9y ago
  Well sure it doesn't support the DOM yet, but I think the design goal of WASM is to do just that. Since the beginning of computers, it should be trivial to distribute programs online efficiently. The web is already platform dependent, but it also need to be fast and language independent.

alangpierce 9y ago

For writing high-performance JavaScript, I'm really hoping that AssemblyScript takes off[1]. The project is still a bit in early stages, but theoretically, it can have the same role as Cython: you write JS/TS code, find the slow parts, and get perf improvements by adding stricter types to your code and changing your code to not use dynamic JS features. You can stay pretty much in JS rather than having to switch to a completely new language to get predictable fast performance. [1] https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript

patientplatypus 9y ago

So... I'm a (junior/so-so) react dev. I like the language, I probably could get better at it but I've gotten to the point where I like the sound of my own music. That said, my question is the following. There seems to be a lot of resources on the web of the type "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. However, I don't see a lot of the things that are in libraries like Vue and React that offer me SPA, fast development time and component (OR!) functional pattern design (I won't mention the ability to add npm packages, because yeah, Rust/WASM doesn't have an ecosystem yet, so that might be punching a bit below the belt). Is there anyone out there making a React like or "eco-system builder"-esque platform that would give me a lot of the benefits I'm seeing with React but with increased performance? Also, I've done some low level programming before and think that Rust is very cool for that (yay memory safety! yay error messaging (no seriously yay)!). However, and I may be betraying my ignorance here, if I want to animate a div to fly across the page, am I going to have to write lots of low level code to do that? If that's the case, and development time suffers to eek out that extra bit of performance, I can't see this as having much utility outside of niche fields like game development. I don't mean to be overly critical mind as I'm still (and probably will always be) a bit of a n00b. I'd love it if somebody would point me at some resources that I could burn a weekend on, if I thought the juice was worth the squeeze. I'm just not sure I know enough to know if this is something that I could be productive in (some day).

steveklabnik 9y ago
> "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. It is very early days. More to come... > However, I don't see a lot of the things that are in libraries like Vue and React Yes. There's not too many of these yet; there are some though. For example, https://github.com/DenisKolodin/yew https://github.com/DenisKolodin/yew There's also the inverse: 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? I know of at least one major SPA framework that's doing this. Don't want to spill the beans too much, even though it is technically public knowledge. That said, that's how I think wasm will impact the lives of most JS programmers: as technology that underpins the libraries they use to make them better. Unless you want to, or unless you want to write a high-performance library, I wouldn't expect wasm to really change the way most JS programmers operate. It's abut augmenting JS, not replacing it. > if I want to animate a div to fly across the page, am I going to have to write lots of low level code to do that? That depends entirely on the library! > I'd love it if somebody would point me at some resources that I could burn a weekend on They're sorta scattered all over the place right now. Such is life for early adopters. More will come as stuff matures. Don't under-estimate how much this will change as the tooling gets built out, for example.

adamnemecek 9y ago

It's not just speedup it's also about writing backend and front-end in one language. But the speedup is real too.

ef4 9y ago

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 consistent performance every time it runs. It's not that plain Javascript can't be as fast -- it's that plain Javascript has high variance, and maintaining engine-internals-aware optimization in a big team with a long-lived app is impractical.

seeekr 9y ago
It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool. Such a tool would give you the benefits you're praising about the WASM compilation workflow: Separately maintained, engine-specific optimizations that can be applied at build-time and don't mess up the maintainability of your source code.
- ptx 9y ago
  But what if I want to target all the engines, including future ones? The compiler could compile separate versions for each engine, I guess, and you could choose which one to load at runtime based on the UserAgent string ... but even then everyone would have to recompile their websites every time a new browser version comes out. The advantage of WebAssembly is supposed to be (I think) that it's simpler and will give more consistency between browsers, so browser behaviour will be less surprising, and you can thus get away with compiling a single version. And if you take this approach of compiling JavaScript to a simple and consistent subset of JavaScript that can be optimized similarly in all engines, you'd end up more or less targeting asm.js, the predecessor to WebAssembly. :)
- ef4 9y ago
  You're basically describing asm.js -- a subset of javascript that is known to be easy for engines to turn directly into native code and execute, that you can use as a compilation target. The difference between asm.js and WASM is mostly just that WASM is more compact and easier to parse, while asm.js is a more gradually compatible upgrade story.

eslaught 9y ago

> Is it better to quick-sort one array with 100K elements or quick-sort 3333 30-element subarrays? > A bit of mathematics can guide us (100000log100000 is 3 times larger than 3333×30log30) You have to be careful doing this kind of analysis. Big-O is explicitly about what happens for large values of N. It is traditional to leave off smaller factors, because they don't matter at the limit of N going to infinity. There is implicitly a constant coefficient on each component, and that might matter more at small N. So e.g. I've seen cases that were O(N^2 + N), and which of course you'd traditionally write as O(N^2), but where the O(N) factor mattered more at small values of N because of constant factors. Depending on whether you cared more about small or large values of N, would guide whether you'd actually want to go after the O(N^2) factor or not. If you just blindly went for the larger factor, you could waste a lot of time and not actually accomplish anything.

NiceGuy_Ty 9y ago

This is a well written article, and I absolutely agree with the idea that profiling and analysis is more important than language choice in order to eke out performance wins. 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.

vortico 9y ago

This is a broad, naive question, but the number of responses and upvotes on this post suggest to me that many people actually need to speed up their JS. I've never once come across this problem in web app development. The bottleneck is always DOM rendering like layout changes, networking, handling large WebGL vertex buffers for video games, etc. In which use cases is JS performance significant?

acemarke 9y ago
In this case, the sourcemaps library isn't normally running as part of user application code. It's primarily used by the browser's DevTools, and server-side build tools like Webpack and Gulp. The faster sourcemaps can be parsed and manipulated, the faster the DevTools and build tools will execute.

vanderZwan 9y ago

Tangent: I see that the author focused on improving sorting algorithms, and also at some point switches to a Uint8Array (although not in the sorting part). 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-typed-and-plain-array-1510082514775 https://run.perf.zone/view/radix-sort-uint32-1000-items-type... [1] https://run.perf.zone/view/radix-sort-uint32-1000000-items-typed-and-plain-array-1510082642142 https://run.perf.zone/view/radix-sort-uint32-1000000-items-t... [2] https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs-fill-in-place-1510007933053 https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs-fil...

spiralx 9y ago
On my OnePlus 5T the standard sort() was twice as fast as the radix sort for the UInt8 array, but it was only 30% slower for the Float64 and regular arrays, whereas sort() was hundreds of times slower - strange...

z3t4 9y ago

We should be more wary about premature optimizations, like in the article where caching in the original code made it slower! Always measure! Write naive code and measure, the JavaScript engines are very good at optimization, especially V8 and the others are catching up. However when I do optimize JavaScript code I often get 10-100x performance. Usually by writing better algorithms. Eg no "black magic". So the original code in the article is not that bad, considering he "only" got 4x performance. Moving to another programming language / WASM for less then 2x performance is not worth it - unless you hate JavaScript.

Narishma 9y ago
> like in the article where caching in the original code made it slower! Caching could have been originally faster, but became slower thanks to the continual improvement of the Javascript VMs.

eximius 9y ago

I'm continually surprised by the Rust -> WASM pressure. I see projects like Redox and Servo and ripgrep and Tokio and, well, native or systems level things being it's true calling. I don't want to write a webapp in Rust. It'll always be second class (though maybe that won't be a problem if the WASM apis get good enough...).

steveklabnik 9y ago
Think of it this way: wasm is pretty similar in many ways to an embedded platform. Rust wants to be good at embedded, so making Rust good at wasm fits. A lot of the work is identical.
- eximius 9y ago
  I think that is a very post-hoc rationalization to justify the silliness that is/has been eating the JS world (emscripten and asm.js show that this sort of thing has been going on for a while), but is an entirely valid reason to indulge it for free interest and experience. +1
  - steveklabnik 9y ago
    I don't think it's a reason that wasm exists, but I do think it's one of the (multiple) reasons for us to invest in making Rust -> wasm an excellent experience.

abritinthebay 9y ago

I’m confused as to why people think this isn’t generally applicable to JS here. Very few of these changes are VM specific or likely to change (or any more so than WASM implementations) - choose your algorithm carefully - make sure you’re paying attention to the data you’re applying the algorithm to is a good fit - pay attention to arity & GC pressure. None of these are hard to do in JS & most of the VM debugging was to help identify problems in existing unoptimized code. The rest are lessons you can take into ANY JS data processing.

staticassertion 9y ago

Awesome. I think it makes a lot of sense to explore new algorithmic approaches before choosing to reimplement in a new language - and thankfully these are not mutually exclusive. To those saying "these are implementation defined optimizations" etc - you do the same exact thing in rust. I know some rust code is 'fast' and some is 'slow' and I have to understand rust and to some extent the state of llvm + rust. This is simply part of writing fast code, no matter the platform or language. Nice writeup!

sehugg 9y ago

I rely heavily on a decent JS performance baseline for http://8bitworkshop.com/ http://8bitworkshop.com/, and I also rely on asm.js / WASM. But I need different things from them. For JS, I need consistency and stability, because I'm dynamically generating code. Usually I'm pretty satisfied, but sometimes after recompiling code I get a huge performance hit for no reason. For WASM, I know I have stability, but I need faster load times. On my Chromebook, for example, it takes 10-20 seconds just to load the WebAssembly. If this problem is solved, I might move everything performance-sensitive over to WASM eventually.