benchmarks
benchmarks copied to clipboard
add nim primes
Add nim primes to benchmark
❯ nim c -d:release --opt:speed src/main.nim && time src/main
Hint: used config file '/Users/lantos/.choosenim/toolchains/nim-1.6.6/config/nim.cfg' [Conf]
Hint: used config file '/Users/lantos/.choosenim/toolchains/nim-1.6.6/config/config.nims' [Conf]
.....................................................................................................
CC: stdlib_dollars.nim
CC: stdlib_system.nim
CC: stdlib_tables.nim
CC: stdlib_deques.nim
CC: main.nim
Hint: [Link]
Hint: gc: refc; opt: speed; options: -d:release
59684 lines; 1.141s; 75.52MiB peakmem; proj: /Users/lantos/Desktop/primes/src/main.nim; out: /Users/lantos/Desktop/primes/src/main [SuccessX]
@[323381, 323383, 3233863, 3233873, 3233887, 3233803, 3233809, 3233897, 3233851]
src/main 0.36s user 0.10s system 60% cpu 0.763 tot
compiles
Is there an automatic runner to see if this merge will work?
Sorry, there is no automatic runner as the docker image is quite big. I'll run the code on the server, and will apply any changes if required. Please address my comments first though. Nothing critical, but I'd like the code to be consistent.
The results will be published a little bit later, within the maintenance update.
hmmm, this was way less performant than I thought it would be. Will have a look into this.
I've looked into it, apparently Nim's implementation of OrderedTable may be not efficient enough. I've changed to use it instead of Table for children for consistency of results, but that introduced the performance penalty. That seems like the implementation specific (for example, C++ unordered_map could actually be a little bit slower than map).
Unfortunately, we can't have one (unordered) or another (ordered) tables only, as, for example, modern Python 3 has ordered dictionaries only, and Lua has unordered tables only. I may look into it a little bit further, but please note that it's just 50% performance change, I won't say it's too critical.
I've changed the tests to use unordered hashmaps (#426), and you could see that Nim numbers are better. Ideally, each test should have the custom map/dictionary container too as even hash functions could differ (like Rust using crypto-strong one thus making its results slower). However, not sure about that as almost nobody use custom maps. I guess we won't be able to avoid debates about that in the future, but for now, please take a look into the PR, and I'll merge it if it's all fine.