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

Option to Normalize Results by an Additive Baseline #431

Open
danielcrabtree opened this issue Apr 21, 2017 · 3 comments
Open

Option to Normalize Results by an Additive Baseline #431

danielcrabtree opened this issue Apr 21, 2017 · 3 comments

Comments

@danielcrabtree
Copy link

For some operations that you want to benchmark, there is unavoidable overhead involved. For example, extra method calls.

This is particularly problematic in nano-benchmarks, where a single method call of overhead can ruin your results. But can also apply to micro-benchmarks and other situations.

I ran into this when comparing the cost of dynamic variant casting to explicit variant casting. With overhead, dynamic is 2.75x faster, but without overhead, dynamic is 4.85x faster.

I suggest that there be the option to remove overhead from results prior to scaling.

One way to achieve this would be to identify one of the benchmarked methods as a special baseline using an attribute and then to add a new normalized column to the output that is the mean minus the mean of the special baseline. The scaled column would then apply to the normalized results instead of the mean.

I propose calling this special baseline an additive baseline in contrast to the normal baseline, which I'm referring to as a multiplicative baseline. However, it could also be identified as Overhead, Normalizer, or something similar.

The results, with Direct being an additive baseline and NormalCast being the multiplicative baseline (the existing baseline), might look something like this:

                Method |       Mean |    StdDev | Normalized | Scaled |
---------------------- |----------- |---------- |----------- |------- |
                Direct | 16.2276 ns | 0.0310 ns |     0.0 ns |   0.00 |
            NormalCast | 16.5152 ns | 0.0073 ns |  0.2876 ns |   1.00 |
 ExplicitCovariantCast | 80.6373 ns | 0.0351 ns | 64.4097 ns | 223.96 |
  DynamicCovariantCast | 29.4733 ns | 0.1694 ns | 13.2457 ns |  46.06 |
@AndreyAkinshin
Copy link
Member

I like this idea! And it should be easy to implement.
The main point of discussion here is the API and it will be look. If we keep the "Scaled" title, it could confuse people who know that "Scaled" means "Scaled Mean". Now we have column legends, so we will be able to explain new column, but I still think that we should modife the title somehow.

@TriJayDore
Copy link

@AndreyAkinshin @danielcrabtree i like to work on this issue .
Where my understanding is renaming the column Scaled to Scaled Mean.
Please let me know if I need to do other changes.

@postmeback
Copy link

Any update ?

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

No branches or pull requests

4 participants