27 ms·

I don't see WASM as a significant step forward. In fact, I question its purpose altogether. Before WASM you could already compile code from other languages int

• pulse7 2y ago
  When computers become faster, WASM will still be twice the speed of JavaScript, because untyped languages limit the optimizations.
• thot_experiment 2y ago
  Bad take. Yes, you can probably optimize a lot of algos in JS such that they are pretty fast, but THAT is cumbersome. I'd much rather write the things I need to go fast in a language that's good at that (I use C for this). I'm currently working on a toolpath optimizer and I'm compiling just the optimizer function to WASM, it's a couple kilobytes and will probably be an order of magnitude faster than the JS implementation while being FAR LESS cumbersome to write. My JS doesn't change at all because i can just call the "native function" from JS, replacing my original JS impl.
  • TekMol 2y ago
    probably be an order of magnitude faster than the JS implementation What makes you think so?
    • thot_experiment 2y ago
      Off the rip because I didn't spend time to make the JS implementation keep all of it's data in a typed array that I manually manage, because it's tedious to do that in JS and it's straightforward in C. Though I'm betting there are other benefits I'll get from -O2 and static analysis.
      • TekMol 2y ago
        Compiling your C to WASM might make it run twice as fast as compiling it to JS. That's all. All other aspects of the workflow are the same.
        • thot_experiment 2y ago
          I will try but I suspect the final score will be 1. WASM 2. JS handwritten for speed 3. C compiled to JS and the gaps will be greater than 2x
          • TekMol 2y ago
            Awesome. I will notice when you reply here, no matter when. I routinely check for new replies even to old comments.
          • flohofwoe 2y ago
            You forgot 'C compiled to the asm.js subset of Javascript', that would be on second place right after WASM (the switch from asm.js to WASM was hardly noticeable in my C/C++ code performance-wise - some browsers had special 'fast paths' for the asm.js subset though).
  • xnorswap 2y ago
    Javascript is incredibly well optimised, I'm surprised if there's an order of magnitude difference between JS and WASM without a fundamental difference in algorithm chosen.
    • thot_experiment 2y ago
      I will likely spend time implementing my solver in several different styles because this is a project I'm tackling largely to make some points about how I think WASM should be used. I'm far from final benchmarks on this but my suspicion is that the gap will be large. Yes javascript is very well optimized, but as someone who's spent a lot of time writing javascript where speed matters, it's not easy, and it's not predictable. You're at the mercy of arcane optimizations in V8 which might not work for your specific situation because you did something weird, and if you're taking a lot of care not to do anything weird, and manually managing your memory with typed arrays, well, then you might as well write C and compile to WASM.
    • consteval 2y ago
      When it comes to GC languages they can often appear very fast for use cases that don't use a lot of memory. If you use an algorithm that near exhausts memory, that's where you'll start seeing that "order of magnitude" difference between JS and something like C++. The same goes for Java and C#. At low memory utilization, the GC can just put off collection, which saves execution time, so the runtime appears fast. But if you're close to the limit, then the GC has no choice but to pause often before continuing. Not very many algorithms will encounter this, but applications might, depending on what they do.
• winternewt 2y ago
  It's difficult or impossible to compile many languages into JavaScript. WASM is more general.
  • TekMol 2y ago
    Theoretically or because of the tooling landscape?
  • swiftcoder 2y ago
    Do you have a source for this? asm.js (the spiritual precursor to WASM) worked pretty much the same, and an awful lot of languages were compiled to it. WASM does provide a more predictable compilation target to be sure, but I don't think it actually opens any new possibilities re what languages can be compiled.
    • winternewt 2y ago
      Multithreading and 64-bit integers come to mind as creating difficulty, and I imagine "raw" memory buffer access having much higher latency to the point where it's completely impractical. For example, a quick search gave me this library [1] that compiles FFMpeg into Asm.js but the author says it is almost a factor 10 slower. Asm.js would also become extremely verbose for any larger code base (imagine compiling a AAA PC game to Asm.js). It may be as you say that there are no new theoretical possibilities being opened by WASM, but to me it is a natural step forward to resolve inefficiencies and ergonomic problems in ASM.js and make it all less painful. And hopefully WASM won't be frozen in time either - the platform needs to keep improving to make more use-case scenarios practical. [1] https://github.com/Kagami/webm.js/ https://github.com/Kagami/webm.js/
• jamil7 2y ago
  You’re assuming a lot of things in this comment, it seems like you believe every software engineer is working with the same constraints, language and platform as yourself.
  • TekMol 2y ago
    No. I say we could build the same dev experience to non-js coders by offering them compile-2-js tools instead of compile-2-wasm tools.
    • jamil7 2y ago
      Not really because then you need a JS environment everywhere you want to run your code. If I write a Rust module I have the possibility to compile to WASM or machine code. This is what I meant in my other comment, your assumption is everyone is making browser apps in Javascript that don't have any performance or resource constraints.
      • TekMol 2y ago
        possibility to compile to WASM or machine code How is this better than "possibility to compile to JS or machine code"?
        • afiori 2y ago
          There are significantly more (and more varied) wasm runtimes than js runtimes.
• IshKebab 2y ago
  The days of computers doubling in speed every 2 years are loooong gone. Look into the history of WASM. They did try compiling everything into JS with asm.js, but then sensibly decided to do things properly. I don't know why anyone would object to proper engineering.
  • pjmlp 2y ago
    Only because Mozilla refused to adopt PNaCL.
• tsimionescu 2y ago
  Debugging a Rust program compiled to Javascript is MUCH harder than debugging one compiled to WASM. That is the whole point. And even making the program work when compiled to JS is iffy, as JS has a few breaking constraints, notably that it is single threaded. Sure, native JS is easier still. But there is a huge wealth of code already written in languages that are not JS. If you want a web app that needs this code, you'll develop it many times faster by compiling the pre-existing code to WASM than by manually rewriting them in JS, and the experience will be significantly better than compiling that code to JS.
  • thot_experiment 2y ago
    ngl I've tried using Rust -> WASM and it's been an awful experience, I'm much much happier with C. Rust generates enormous blobs because you have to include stdlib, and if you don't you don't get any of the benefits of using Rust. I'm probably overrotating on binary size but it sure is nice being able to just read the WASM and make sense of it, which is generally the case for WASM made from C and is absolutely not the case if you're building from Rust.
    • therein 2y ago
      Did you run the output through wasm-opt? The size isn't terribly bad. I have a whole complex GUI with realtime charts, based on egui, under 4MB uncompressed. This includes three fonts and even some images.
      • thot_experiment 2y ago
        Yeah no obviously the size of the stdlib is fixed so as your binary sizes grow it stops mattering. I'm curious why you're taking the approach you describe, I think compiling entire GUI apps to WASM is the absolute worst thing, so clearly you have a different set of constraints on your work.
        • therein 2y ago
          Yeah very much different constraints. I would send a screenshot if I knew I could make it public because the results look spectacular. Rendering at 60 to 120FPS, perfectly smooth navigation, rendering even 10k OHLC candles without a hiccup.
• vbezhenar 2y ago
  You can probably optimize JS to run as fast in most cases. What actually WASM brings is predictable performance. If you're JS wizard, you can shuffle code around, using obscure tricks to make current browser to run it really fast. The problem is: JS wizards are rare and tomorrow browser might actually run the same code much slower if some particular optimization changed. WASM performance is pretty obvious and won't change significantly across versions. And you don't need to be wizard, you just need to know C and write good enough code, plenty of people can do that. Clang will do the rest. I agree that using WASM instead of JS without reasons probably is not very wise. But people will abuse everything and sometimes it works out, so who knows... The whole modern web was born as abuse of simple language made to blink the text.
• flohofwoe 2y ago
  > WASM is much more cumbersome to handle than plain JS when it comes to deployment, execution and debugging. For some of us it's much easier than dealing with Javascript though (for instance debugging C/C++ in Visual Studio is much nicer than debugging JS in Chrome - and that's possible by simply building for a native target, and then just cross-compile to WASM - but even the WASM debugging situation has improved dramatically with https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod...)
• DanielHB 2y ago
  > Before WASM you could already compile code from other languages into JavaScript. And have the same benefits as you have with WASM. If you are referring to asm.js you must be joking. asm.js was basically a proof of concept and is worse in every way compared to WASM. Like parsing time overhead alone makes it a non-option for most large applications. You seem to imply you should just do it in plain JS instead for "deployment, execution and debugging" benefits. Imagine if you could be free to use those python ML libs in any language of your choice, that alone is enough of an argument. No one is going to reimplement them in JS (or any other environemtn) unless there is a huge ecosystem movement around it.