Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
FranklinChen opened this issue May 15, 2018 · 6 comments
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed

Comments

@FranklinChen
Copy link
Contributor

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

@frol frol added bug Something isn't working help wanted Extra attention is needed good first issue Good for newcomers labels May 15, 2018
@PMunch
Copy link
Contributor

PMunch commented May 15, 2018

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.

@frol
Copy link
Owner

frol commented May 15, 2018

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

@johnperry-math
Copy link
Contributor

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.

@frol
Copy link
Owner

frol commented May 16, 2018

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
Copy link
Owner

frol commented May 16, 2018

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.

@johnperry-math
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants
@FranklinChen @frol @PMunch @johnperry-math and others