Skeptical of rewriting JavaScript tools in "faster" languages

Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.

Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.

As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.

> 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.

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.

> 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.

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/...

Couldn't find C vs JS easily with the new benchmarksgame UI.

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?

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.

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.