3 ms·
Their fannkuch benchmark seems to be a bit dishonest. They claim an enormous perf delta on https://exaloop.io/benchmarks.html https://exaloop.io/benchmarks.html
by tekknolagi 3y ago
Their fannkuch benchmark seems to be a bit dishonest. They claim an enormous perf delta on https://exaloop.io/benchmarks.html https://exaloop.io/benchmarks.html but fannkuch uses factorial a lot and they define factorial with a very small (n=20) table: https://github.com/exaloop/codon/blob/fb461371613049539654c11aa52eedeefd2b9a60/stdlib/math.codon#L19 https://github.com/exaloop/codon/blob/fb461371613049539654c1...
Disclaimer: I've worked on several Python runtimes and compilers, but I'm not by any means out to get Codon. Just happened across this by accident while looking at their inline LLVM, which is neat.
- Atlas22 3y agoCan you elaborate on why using the lookup table makes this objectionable/dishonest? Factorial of 20 is the largest factorial that fits in 64-bit integer. The factorial function you linked is only defined on codon's int type (64-bit signed) so it encompasses the full range of the output datatype.
- regularfry 3y agoIt's a targeted micro-optimisation that doesn't say anything about codon's more general-case numeric performance. Unless the other implementations are using the same algorithm it's not comparing like with like.
- tialaramex 3y agoIt's not that targeted. Factorial is a reasonable thing to do, optimising for the values that fit in a 64-bit integer is a reasonable thing to do. If I read this in some code, I wouldn't think "Huh, that's a specialised feature, I bet it's attacking a specific benchmark" I would think, "Oh, that makes sense".
- Atlas22 3y agoLooks like cpython does the same thing if for small n. https://github.com/python/cpython/blob/a9c6e0618f26270e2591b3d99ffeef55eea02a33/Modules/mathmodule.c#L2017 https://github.com/python/cpython/blob/a9c6e0618f26270e2591b...