3 ms·

> knows that the language doesn’t matter so much as your algorithm. I know what you’re referring to but these problems have also taught me a lot about language

> knows that the language doesn’t matter so much as your algorithm. I know what you’re referring to but these problems have also taught me a lot about language performance. python and JS array access is just 100x slower than C. Some difficult problems become much harder due to this limitation.

jampekka 2y ago
JS array access is a lot faster than Python array access. JS is easily within magnitude of C and can be even about as fast with typed arrays or well JITable code.
- tightbookkeeper 2y ago
  > JS is easily within magnitude of C Typed arrays help a lot, but I’m still doubtful. Maybe it all the processing is restrict to idioms in the asm.js subset? And even then you’re getting bounds checking.
  - jampekka 2y ago
    In benchmarks JS is usually well within magnitude (i.e. under 10x slower). E.g. C++ vs Node.js here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/q6600/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Couldn't find C vs JS easily with the new benchmarksgame UI.
    - tightbookkeeper 2y ago
      I guess so. I clicked on the code for the first one. It’s using a C library to do the computation: > mpzjs. This library wraps around libgmp's integer functions to perform infinite-precision arithmetic And then the “array”: > Buffer.allocUnsafe So is this a good JavaScript benchmark?
      - jampekka 2y ago
        That's the only benchmark on the page that uses such wrapper. Buffer.allocUnsafe just allocates the memory without zero-initializing it, just like e.g. malloc does. Probably usually not worth it, but in a benchmark it's comparable to malloc vs calloc.
        tightbookkeeper 2y ago
        Yeah and using byte buffers isn’t JavaScript array access. But it is for C. The n-body looks most like canonical JS to me. It’s a small array, but’s it’s accessed many times. Unfortunately the c++ version is simd optimized, so I don’t think that’s a fair comparison.
        igouy 2y ago
        There are plain C++ programs: n-body C++ g++ #3 https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
        jampekka 2y ago
        I'd guess using typed arrays or even normal arrays wouldn't slow the code much, and the slowdown will be probably a small constant factor. If the JIT detects the array as homogenous it will compile it to low level array access. JS JITs are very good.
        igouy 2y ago
        > I don’t think that’s a fair comparison Shouldn't simd use make it less likely JS would be within magnitude, so if compared against simd programs and the JS is still less than 10x slower then that strengthens jampekka's point?
    - igouy 2y ago
      > Couldn't find C vs JS easily Try: A) Find JS in the box plot charts https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... or B) Find JS in the detail https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

jampekka 2y ago

JS array access is a lot faster than Python array access. JS is easily within magnitude of C and can be even about as fast with typed arrays or well JITable code.

tightbookkeeper 2y ago
> JS is easily within magnitude of C Typed arrays help a lot, but I’m still doubtful. Maybe it all the processing is restrict to idioms in the asm.js subset? And even then you’re getting bounds checking.
- jampekka 2y ago
  In benchmarks JS is usually well within magnitude (i.e. under 10x slower). E.g. C++ vs Node.js here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/q6600/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Couldn't find C vs JS easily with the new benchmarksgame UI.
  - tightbookkeeper 2y ago
    I guess so. I clicked on the code for the first one. It’s using a C library to do the computation: > mpzjs. This library wraps around libgmp's integer functions to perform infinite-precision arithmetic And then the “array”: > Buffer.allocUnsafe So is this a good JavaScript benchmark?
    - jampekka 2y ago
      That's the only benchmark on the page that uses such wrapper. Buffer.allocUnsafe just allocates the memory without zero-initializing it, just like e.g. malloc does. Probably usually not worth it, but in a benchmark it's comparable to malloc vs calloc.
      - tightbookkeeper 2y ago
        Yeah and using byte buffers isn’t JavaScript array access. But it is for C. The n-body looks most like canonical JS to me. It’s a small array, but’s it’s accessed many times. Unfortunately the c++ version is simd optimized, so I don’t think that’s a fair comparison.
        igouy 2y ago
        There are plain C++ programs: n-body C++ g++ #3 https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
        jampekka 2y ago
        I'd guess using typed arrays or even normal arrays wouldn't slow the code much, and the slowdown will be probably a small constant factor. If the JIT detects the array as homogenous it will compile it to low level array access. JS JITs are very good.
        igouy 2y ago
        > I don’t think that’s a fair comparison Shouldn't simd use make it less likely JS would be within magnitude, so if compared against simd programs and the JS is still less than 10x slower then that strengthens jampekka's point?
  - igouy 2y ago
    > Couldn't find C vs JS easily Try: A) Find JS in the box plot charts https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... or B) Find JS in the detail https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...