3 ms·
I get that the intended meaning is "JS sux", but I can't help being impressed with how performant engines are. The "pixels per ms" count ratio is less than 3:1
by qsort 4y ago
I get that the intended meaning is "JS sux", but I can't help being impressed with how performant engines are. The "pixels per ms" count ratio is less than 3:1 on my machine, in what I imagine is a CPU-heavy task.
- ufo 4y agoOn my phone it's closer to 6:1. 500 jumps to 3000 with WASM
- christophilus 4y agoWhat kind of phone? My iPhone 7 (pretty old) is around 2800 vs 6000 with WASM.
- ufo 4y agoMoto g 7
- crabmusket 4y ago> in what I imagine is a CPU-heavy task. I'd love for someone who knows this problem a little better to chime in, but this doesn't look like that heavy a task to me. I've read through the code very briefly. The core of the attractor logic[1] seems to be a few trig functions with a lot of bookkeeping around it (e.g. measuring performance to know how many iterations will fit within each frame budget, I think?). But each iteration depends on the state of previous iterations anyway (stored in module-globals[2]) so there's a data dependency that a CPU isn't going to have a great time with. I'd be interested to know where most of the time is being spent in this program, but I don't think it's really playing to the strengths of Rust/WASM. [1]: https://github.com/dmaynard/attractor-iterator/blob/b927428988949e7efca8822697b58d721b8ade58/Attractor.js#L110-L114 https://github.com/dmaynard/attractor-iterator/blob/b9274289... [2]: https://github.com/dmaynard/attractor-iterator/blob/b927428988949e7efca8822697b58d721b8ade58/Attractor.js#L2-L3 https://github.com/dmaynard/attractor-iterator/blob/b9274289...