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

Aggregates: use non-aggregate count as iteration count. #706

Merged
merged 3 commits into from Oct 18, 2018

Conversation

LebedevRI
Copy link
Collaborator

It is incorrect to say that an aggregate is computed over
run's iterations, because those iterations already got averaged.
Similarly, if there are N repetitions with 1 iterations each,
an aggregate will be computed over N measurements, not 1.
Thus it is best to simply use the count of separate reports.

Fixes #586.

It is incorrect to say that an aggregate is computed over
run's iterations, because those iterations already got averaged.
Similarly, if there are N repetitions with 1 iterations each,
an aggregate will be computed over N measurements, not 1.
Thus it is best to simply use the count of separate reports.

Fixes google#586.
@coveralls
Copy link

coveralls commented Oct 17, 2018

Coverage Status

Coverage remained the same at 89.224% when pulling 769491b on LebedevRI:aggregates-iteration-count into d731697 on google:master.

@AppVeyorBot
Copy link

Build benchmark 1530 completed (commit 1e959e4d75 by @LebedevRI)

@dmah42
Copy link
Member

dmah42 commented Oct 18, 2018

Can you provide a screenshot/link to the resulting output before and after so it's capture in the PR?

@LebedevRI
Copy link
Collaborator Author

The tests convey that i think..
image
image

@LebedevRI
Copy link
Collaborator Author

Hm, that is clearly broken.

This is a rather huge mess. What is worse, the custom counters
are already divided by iteration count by now.

And i'm not sure it is in general correct to compute
the stats over sum(iterations), and then divide the stat by iteration
count.

I think we should cleanup everything to divide by iteration count
as early as possible.
@LebedevRI
Copy link
Collaborator Author

Ok, that was a fun issue :) Test added.
Proper comparison:
image
image

@LebedevRI LebedevRI removed the invalid label Oct 18, 2018
@LebedevRI
Copy link
Collaborator Author

Yay, thank you for the review!

@LebedevRI LebedevRI merged commit 507c06e into google:master Oct 18, 2018
@LebedevRI LebedevRI deleted the aggregates-iteration-count branch October 18, 2018 14:17
EricWF pushed a commit to efcs/benchmark that referenced this pull request Nov 29, 2018
It is incorrect to say that an aggregate is computed over
run's iterations, because those iterations already got averaged.
Similarly, if there are N repetitions with 1 iterations each,
an aggregate will be computed over N measurements, not 1.
Thus it is best to simply use the count of separate reports.

Fixes google#586.
JBakamovic pushed a commit to JBakamovic/benchmark that referenced this pull request Dec 6, 2018
It is incorrect to say that an aggregate is computed over
run's iterations, because those iterations already got averaged.
Similarly, if there are N repetitions with 1 iterations each,
an aggregate will be computed over N measurements, not 1.
Thus it is best to simply use the count of separate reports.

Fixes google#586.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants