completely-unscientific-benchmarks
completely-unscientific-benchmarks copied to clipboard
Inconsistent number of loop iterations across languages: review all of them
I noticed that there's a variety of differences in loop iterations across languages. Kotlin has 1..1000000
which means going 1_000_000 times, from 1 through 1_000_000 inclusive. Some of the other implementations seem to be off from that by 1 in some direction or other, e.g., the Java version actually executes from 1 to 999_999. Obviously missing one iteration doesn't make any difference to any benchmarks, but still, it seems the code for each language should be equivalent unless otherwise noted (especially memory management styles).
I checked this in Nim, it was originally doing 0 .. 1_000_000
which is inclusive. Changed it to 0 ..< 1_000_000
so it should be fine.
We should change all of the solutions to go from 0 to 999999 inclusively, I think.
I had based the Ada and Modula-2 versions off the C++ version, which has
for(int i = 1; i < 1000000; i++)
That goes from 1 to 999999, inclusive, which is how I set up their for
loops. It would be easy to modify; I just wanted to make sure this was the case.
As an aside, if someone supplies an implementation and doesn't pay attention to that sort of thing, then there is no doubt that this is a "Completely Unscientific Benchmark." ;-)
More seriously, it becomes a little worrisome what else might be going on. I noticed that some implementations, perhaps in an attempt to make the time look better, allocate a memory pool and grab & return memory to that, perhaps (probably?) to avoid the hit from a garbage collector or the run-time or the system. I think that defeats the purpose of this benchmark, however unscientific it may be. Perhaps some ground rules should be laid down on what tricks are allowed.
I think that defeats the purpose of this benchmark, however unscientific it may be. Perhaps some ground rules should be laid down on what tricks are allowed.
You are right. I will try to come up with the rules.
I noticed that some implementations, perhaps in an attempt to make the time look better, allocate a memory pool and grab & return memory to that
By the way, which solutions do you refer to? I have marked Object Pascal "no-heap" solution as cheating, but I don't see if there are any more such solutions.
When I wrote "some", it was off the top of my head, so perhaps there was just that one.