Surprised to see Nim that slow, typically it ranks much higher in benchmarks. But without looking at the code and compiler options its hard to tell if it is simply the problem or the implementation that's to blame.
E.g. the Json interface of the Nim stdlib is not the quickest, but there are some third party libraries, 100% Nim, really fast (jsony). A look a both reveals that the problem is not the Nim compiler, but the algorithm used and intended usage.
I'm surprise to hear that it was so slow on a powerful machine. In my experience throwing more compute at a codebase can make compile times very, very fast, though of course only after the first run. It parallelizes pretty damn well.
I didn't say it's just "slow". I said it's an expected performance hit in comparison with languages like C++. In some cases that hit is tolerable, in others not.
You can't blame this on GMP. People are free to interface with it in better ways from the languages you mention.
As for speed, I'm sure some very specialized applications can do better if they have constraints that allow for specific optimization, but as far as a general library goes I haven't seen better performance than GMP personally.
I'm surprised it was twice as slow. Just this past week I was playing around with WASM, running some pure math calculations and comparing them against a JS version. I was seeing a 10x perf increase, though I was writing WAT directly, not compiling C or anything like that.
It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.
Yeah, really unsatisfying that there was no attempt to explain why it might be slower since it just gives the compiler more information to decide on optimizations which in theory should only make thins faster.
It's a compiled language with a close-to-baremetal type system and implemented as an LLVM frontend. I don't see what would make it slower than e.g. Fortran except for a couple more years of LLVM backend optimizations required (which I still think will happen given LLVM's adoption), but probably I'm missing something here.
The author stated that the benchmarks run in headless mode, so I am not sure that it's SDL that's slowing it down here.
Even if it is SDL slowing it down, Go FFI being slow is still a real disadvantage compared to the other languages, and you can't just pretend like it doesn't exist in this case.
In my own little ad-hoc micro benchmark it is. That's why I suspected that there was copying going on, but there could be so many other reasons for it that it was probably a pointless exercise in the first place.
[Edit] And I mean relatively slow (4x the C++ code), not absysmally slow. Not a big deal.
reply