You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@NMSAzulX thanks for the question! It seems that the .NET Core 2.0 version takes 0 CPU cycles in the first case and 1 CPU cycle in the second case. It's a pretty interesting situation. Could you please share the source code of your benchmark and the full BenchmarkDotNet output (you can find .log file in the BenchmarkDotNet.Artifacts folder) for runs with different rank values.
@NMSAzulX thanks! It seems that this benchmark should always take 0 CPU cycles with all .NET Core versions. However, sometimes we get 1 CPU cycle error (about 0.3ns). Typically, in such cases, we have problems with loop alignment (the actual performance depends on the first line address of the main benchmark loop). We are trying to resolve such problems with the help of UnrollFactor which is 16 by default. My first hypothesis: it's not enough in your case. Could you please rerun the benchmark with --unrollFactor 64 command line switch and show the new logs?
I have just done three tests and the report is as follows:
It seems that the problem is resolved now. Probably, we should increase the default value of the unroll factor. @adamsitnik what do you think?
Is the code too simple to take less than 0.0001 (ns)? : )
Under the summary table, you have the following warnings:
// * Warnings *
ZeroMeasurement
DynamicCallFieldTest.Origin: Runtime=Core, Toolchain=netcoreapp2.2, UnrollFactor=64 -> The method duration is indistinguishable from the empty method duration
DynamicCallFieldTest.Origin: Runtime=Core, Toolchain=netcoreapp2.0, UnrollFactor=64 -> The method duration is indistinguishable from the empty method duration
DynamicCallFieldTest.Origin: Runtime=Core, Toolchain=netcoreapp2.1, UnrollFactor=64 -> The method duration is indistinguishable from the empty method duration
The "The method duration is indistinguishable from the empty method duration" means that your method has the same duration as the following empty method (in the context of benchmarking when we call your method many times in a loop):
However, the result is not very stable, the last three test rankings fluctuated a little bit.
It's just a random noise which always presents in measurements. If you look at the Rank column, you should see 1 for each toolchain. It means that there is no statistically significant difference between results (BenchmarkDotNet performs an honest statistical test)
for (int i = 0; i < length; i++)
Typically, you shouldn't write own loop because BenchmarkDotNet will generate it for you internally.
@AndreyAkinshin I used to stare at “Mean”. Thanks. Got it.
By the way, is there any documentation on the official website that tells us how to analyze these results?
I'm working on such a guide but it's not easy to briefly cover all the important cases. I really want to create a good cheat sheet for BenchmarkDotNet output and include it in the documentation, but it's not ready yet.
By the way, you can find a lot of useful information in my book Pro .NET Benchmarking (It's already available for pre-order; it should be released this summer).
we should increase the default value of the unroll factor. @adamsitnik what do you think?
You are most probably right. We have hit dotnet/performance#511 after update to latest BDN and from the few runs with --unrollFactor 32 I can tell that it makes all the nano-benchmarks much more stable. I will try to find some time and run all the benchmarks from the performance repo and see the difference and let you know.
Activity
AndreyAkinshin commentedon May 25, 2019
@NMSAzulX thanks for the question! It seems that the .NET Core 2.0 version takes 0 CPU cycles in the first case and 1 CPU cycle in the second case. It's a pretty interesting situation. Could you please share the source code of your benchmark and the full BenchmarkDotNet output (you can find .log file in the
BenchmarkDotNet.Artifactsfolder) for runs with different rank values.NMSAzulX commentedon May 25, 2019
@AndreyAkinshin Thank you very much. Here is the Source Project and Log Folder
Content just like this:
Commond:
AndreyAkinshin commentedon May 25, 2019
@NMSAzulX thanks! It seems that this benchmark should always take 0 CPU cycles with all .NET Core versions. However, sometimes we get 1 CPU cycle error (about 0.3ns). Typically, in such cases, we have problems with loop alignment (the actual performance depends on the first line address of the main benchmark loop). We are trying to resolve such problems with the help of UnrollFactor which is 16 by default. My first hypothesis: it's not enough in your case. Could you please rerun the benchmark with
--unrollFactor 64command line switch and show the new logs?NMSAzulX commentedon May 25, 2019
I have just done three tests and the report is as follows:
1 Test
2 Test
3 Test
NMSAzulX commentedon May 25, 2019
Is the code too simple to take less than 0.0001 (ns)? : )
NMSAzulX commentedon May 26, 2019
@AndreyAkinshin Hello, I've uploaded the new test log.
AndreyAkinshin commentedon May 26, 2019
It seems that the problem is resolved now. Probably, we should increase the default value of the unroll factor. @adamsitnik what do you think?
Under the summary table, you have the following warnings:
The "The method duration is indistinguishable from the empty method duration" means that your method has the same duration as the following empty method (in the context of benchmarking when we call your method many times in a loop):
NMSAzulX commentedon May 26, 2019
@AndreyAkinshin Hello~
However, the result is not very stable, the last three test rankings fluctuated a little bit.
Test2:
Test 3:
Can some kind of constraint be used to avoid this problem?
For example:
I used this way for a new round of testing.
NewTest1 、 NewTest2 、 NewTest3
The result was unexpected, but it was much more stable.
With this result, I am confused about the performance of the. Net CORE2.2.
That's amazing.
AndreyAkinshin commentedon May 26, 2019
It's just a random noise which always presents in measurements. If you look at the Rank column, you should see
1for each toolchain. It means that there is no statistically significant difference between results (BenchmarkDotNet performs an honest statistical test)Typically, you shouldn't write own loop because BenchmarkDotNet will generate it for you internally.
NMSAzulX commentedon May 26, 2019
@AndreyAkinshin I used to stare at “Mean”. Thanks. Got it.
By the way, is there any documentation on the official website that tells us how to analyze these results?
AndreyAkinshin commentedon May 26, 2019
I'm working on such a guide but it's not easy to briefly cover all the important cases. I really want to create a good cheat sheet for BenchmarkDotNet output and include it in the documentation, but it's not ready yet.
By the way, you can find a lot of useful information in my book Pro .NET Benchmarking (It's already available for pre-order; it should be released this summer).
NMSAzulX commentedon May 26, 2019
Okay, thank you very much. I already have the motivation to learn.
adamsitnik commentedon May 30, 2019
You are most probably right. We have hit dotnet/performance#511 after update to latest BDN and from the few runs with
--unrollFactor 32I can tell that it makes all the nano-benchmarks much more stable. I will try to find some time and run all the benchmarks from the performance repo and see the difference and let you know.