3 ms·

now rewrite it back to JS with https://github.com/KilledByAPixel/LittleJS https://github.com/KilledByAPixel/LittleJS j/k :D

deleted 2y ago
[deleted]
nine_k 2y ago
Why, from C to Zig, from Zig to Rust. Compile the Rust version to WASM to finally make it runnable in the browser.
- Defletter 2y ago
  Doesn't Zig compile to WASM too?
  - flohofwoe 2y ago
    Yes, for instance this is mixed Zig/C project (the C part are the sokol headers for the platform-glue code): https://floooh.github.io/pacman.zig/pacman.html https://floooh.github.io/pacman.zig/pacman.html The Git repo is here: https://github.com/floooh/pacman.zig https://github.com/floooh/pacman.zig ...in this specific project, the Emscripten SDK is used for the link step (while compilation to WASM is handled by the Zig compiler, both for the Zig and C sources). The Emscripten linker enables the 'embedded Javascript' EM_JS magic used by the C headers, and it also does additional WASM optimizations via Binaryen, and creating the .html and .js shim file needed for running WASM in browsers. It's also possible to create WASM apps running in browsers using only the Zig toolchain, but this requires solving those same problems in a different way.
  - nine_k 2y ago
    Yes, but the point of the joke was to make the loop longer, while keeping it somehow logical. I wish I managed to insert Purescript, Elixir, Pony and ATS somehow.
- 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 ago
    Not 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 ago
    JS 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 ago
      From 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 ago
        Exactly. 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.

deleted 2y ago

[deleted]

nine_k 2y ago

Why, from C to Zig, from Zig to Rust. Compile the Rust version to WASM to finally make it runnable in the browser.

Defletter 2y ago
Doesn't Zig compile to WASM too?
- flohofwoe 2y ago
  Yes, for instance this is mixed Zig/C project (the C part are the sokol headers for the platform-glue code): https://floooh.github.io/pacman.zig/pacman.html https://floooh.github.io/pacman.zig/pacman.html The Git repo is here: https://github.com/floooh/pacman.zig https://github.com/floooh/pacman.zig ...in this specific project, the Emscripten SDK is used for the link step (while compilation to WASM is handled by the Zig compiler, both for the Zig and C sources). The Emscripten linker enables the 'embedded Javascript' EM_JS magic used by the C headers, and it also does additional WASM optimizations via Binaryen, and creating the .html and .js shim file needed for running WASM in browsers. It's also possible to create WASM apps running in browsers using only the Zig toolchain, but this requires solving those same problems in a different way.
- nine_k 2y ago
  Yes, but the point of the joke was to make the loop longer, while keeping it somehow logical. I wish I managed to insert Purescript, Elixir, Pony and ATS somehow.
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 ago
  Not 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 ago
  JS 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 ago
    From 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 ago
      Exactly. 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.