4 ms·
i'm actually quite curious how it would perform relative to the C version. the article shows 1000x particles, but LittleJS has demos with a couple orders of mag
by leeoniya 2y ago
i'm actually quite curious how it would perform relative to the C version. the article shows 1000x particles, but LittleJS has demos with a couple orders of magnitude more than that at 60fps.
e.g. https://killedbyapixel.github.io/LittleJS/examples/stress/ https://killedbyapixel.github.io/LittleJS/examples/stress/
- pjmlp 2y agoNot looked into the code, the correct way would be to move the particles engine into shader code, and the limit would be as much as the graphics card can take. It appears that after all these years, not everyone has bought into shader programming mentality, which is quite understable as only proprietary APIs have good debugging tools for them.
- nine_k 2y agoJS engines like V8 are very good at JIT and optimization based on actual profiling. If we talk about pure CPU modeling, I suspect a good JIT will soon enough produce machine code on par with best AOT compilers. (BTW the same should apply to JVM and CLR languages, and maybe even to LuaJIT to some extent.)
- andai 2y agoFrom my cursory reading of v8 blogs, most of its optimizations revolve around detecting patterns in JS objects and replacing them with C++ classes.
- nine_k 2y agoExactly. Detecting patterns that are typical for human coders and replacing them with stuff that uses the machine efficiently is what most compilers do, even for low-level languages like C. You write a typical `for` loop, the compiler recognizes it and unrolls it, and / or replaces it with a SIMD-based version with many iterations run per clock.