Benchmarks #113
Benchmarks #113
Conversation
… a fixed number of limbs
… add tests for gcd
Add random functions from another PR to benchmark with random bigint
There was a problem hiding this comment.
Generally looks good to me! I'm not really fond of benchy, since it only displays numbers in milliseconds, but I don't know of a better alternative. The benchmarking code has a lot of duplication, that could be easily reduced by extracting the benchmarking code into a proc/template. I think we should also bench BigInts with less than 100 limbs, e.g. 10, 2, or 1, since I think those will be more common for casual uses of BigInts.
| # block: | ||
| # randomize() | ||
| # let a: BigInt = initRandomBigInt(33) | ||
| # echo a | ||
|
|
||
| static: main() | ||
|
|
||
| #static: main() |
There was a problem hiding this comment.
I had to comment out the static tests and randomized versions. In the future, I will need to remove these comments and let this file in its initial state.
|
in the past I did some benchmarking (addition and multiplication, inspired by a Js benchmarking suite) during a PR (then removed the code). They were done using library criterion and published results in a generated md file. Maybe it can turn out useful for this PR: #35 (comment) |
I benchmarked multiplication, division, random generation of bigints. Without flags, the operations are slow, with flags, the timings looks correct to me.
The code source quality of benchBigints.nim can be improved with templates to do less copy-paste in the future.
I have also changed some of the examples to import them (by exporting some procedures and using whenIsmainmodule) so that I can benchmark them.
I added some corresponding nimble tasks.
I use
-d:lto -d:danger --opt:speedflags for benchmarks.I consider using benchy for benchmarks is ok, it does not make it a dependency of the full library, it is only required for benchmarks.
This PR might be really useful for easy comparison of our changes to the library.