4 ms·
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
by 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 agoprobably be an order of magnitude faster than the JS implementation What makes you think so?
- thot_experiment 2y agoOff 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 agoCompiling 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 agoI 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 agoAwesome. I will notice when you reply here, no matter when. I routinely check for new replies even to old comments.
- flohofwoe 2y agoYou 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 agoJavascript 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 agoI 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 agoWhen 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.