completely-unscientific-benchmarks icon indicating copy to clipboard operation
completely-unscientific-benchmarks copied to clipboard

Inconsistent number of loop iterations across languages: review all of them

Open FranklinChen opened this issue 6 years ago • 6 comments

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).

FranklinChen avatar May 15 '18 11:05 FranklinChen

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.

PMunch avatar May 15 '18 13:05 PMunch

We should change all of the solutions to go from 0 to 999999 inclusively, I think.

frol avatar May 15 '18 13:05 frol

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.

johnperry-math avatar May 16 '18 16:05 johnperry-math

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.

frol avatar May 16 '18 16:05 frol

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.

frol avatar May 16 '18 19:05 frol

When I wrote "some", it was off the top of my head, so perhaps there was just that one.

johnperry-math avatar May 16 '18 20:05 johnperry-math