←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 5 comments | 20 Oct 24 21:25 UTC | HN request time: 0.784s | source
Show context
jpalawaga ◴[20 Oct 24 21:53 UTC] No.41898791[source]▶
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.

replies(12): >>41898816 #>>41898879 #>>41898890 #>>41898952 #>>41899000 #>>41899028 #>>41899401 #>>41901158 #>>41901185 #>>41901525 #>>41902030 #>>41904514 #
tightbookkeeper ◴[20 Oct 24 22:08 UTC] No.41898890[source]▶
> 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.

replies(1): >>41898967 #
jampekka ◴[20 Oct 24 22:20 UTC] No.41898967[source]▶
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.
replies(1): >>41899140 #
tightbookkeeper ◴[20 Oct 24 22:52 UTC] No.41899140[source]▶
> 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.

replies(1): >>41899241 #
jampekka ◴[20 Oct 24 23:07 UTC] No.41899241[source]▶
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.

replies(2): >>41899295 #>>41899458 #
tightbookkeeper ◴[20 Oct 24 23:16 UTC] No.41899295[source]▶
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?

replies(1): >>41899418 #
1. jampekka ◴[20 Oct 24 23:33 UTC] No.41899418[source]▶
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.

replies(1): >>41899464 #
2. tightbookkeeper ◴[20 Oct 24 23:42 UTC] No.41899464[source]▶
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.

replies(3): >>41899515 #>>41902122 #>>41905665 #
3. igouy ◴[20 Oct 24 23:54 UTC] No.41899515[source]▶
There are plain C++ programs: n-body C++ g++ #3

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

4. jampekka ◴[21 Oct 24 09:10 UTC] No.41902122[source]▶
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.

5. igouy ◴[21 Oct 24 16:14 UTC] No.41905665[source]▶
> 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?