Power management about benchmarkdotnet HOT 8 CLOSED

Hi,
@adamsitnik, @AndreyAkinshin, can I work on this issue as my first one? I performed two simple benchmark tests on my laptop. Below you can see, it is a significant difference between power plans.

        private readonly Dictionary<string, string> Guids = new Dictionary<string, string>()
        {
            { "HighPerformance", "8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c" },
            { "Balanced", "381b4222-f694-41f0-9685-ff5bb260df2e" },
            { "PowerSaver", "e22fd527-0c09-43ad-83d6-ba300affc27d" }
        };

        [Params("HighPerformance", "Balanced", "PowerSaver")]
        public string PerfPlan { get; set; }

        [IterationSetup]
        public void InitGuid()
        {
            var planGuid = Guids[PerfPlan];
            var guid = new Guid(planGuid);
            PowerManagment.Set(guid);
        }

        [Benchmark]
        public int SplitJoin()
            => string.Join(",", new string[1000]).Split(',').Length;

        [Benchmark]
        public int IterationTest()
        {
            int j = 0;
            for (int i=0; i < short.MaxValue; ++i)
            {
                j = i;
            }

            return j;
        }

What I suggest that we can use helper class similar to that proposed by @omariom with two methods. The first one will check if the system is windows, save current power plan and eventually set performance to the HighPerf. Then we perform all benchmarks, and after that, we use the second method. The second method will restore the previous user power plan. Both of the methods will execute in the BenchmarkRunner class. What is your opinion about that?

Points to consider:
If someone shutdown system or kill benchmark process, unfortunately, a user will stay with a new performance plan as the side effect of benchmarking. Of course, we can log some information to the user that we changed his power plan.

from benchmarkdotnet.

It is a very good idea, I like it. Another good links about the subject:
https://msdn.microsoft.com/en-us/library/system.windows.forms.systeminformation.aspx
https://msdn.microsoft.com/en-us/library/hxkc1kwd.aspx
http://thoughtso.org/wp-content/uploads/2007/11/cpower.txt
http://stackoverflow.com/questions/16023978/how-to-use-power-management-functions-powerenuimerate-to-get-power-settings
http://www.fsmpi.uni-bayreuth.de/~dun3/archives/programmatically-change-power-options-using-cshar/519.html

from benchmarkdotnet.

Agree, that's a great idea, I've used Vance Morrison's MeasureIt before, but I never realised that it forced the power mode like that.

from benchmarkdotnet.

Some more related info (from a comment on Scott Hanselman's Blog Post "Benchmarking .NET code"):

We benchmark our code all the time. For serialization we have done this: SERBENCH here are some charts: Typical Person Serialization.
What is interesting is that the most benchmarks provided by software makers are very skewed, i.e. serializers depend greatly on payload type, as our test indicated. Some things taken for granted like "Protobuff" is the fastest are not true in some test cases you see unexpected results. That's is why it is important to execute the same suite of test cases against different vendors. Sometimes benchmarking something is more work than writing the component, for example SpinLock class has many surprises.

Another thing that 90% of people I talk to disregard: SpeedStep. Try to disable it via control panel and dont be surprised that you get 25% perf boost EVEN IF you ran your tests for minutes. SpeedStep does magic tricks, it lowers you CPU clock even if the CPU is swamped, but not on all cores. Running tests from within VS(with debugger attached) can slow things down by good 45-70%.

So I would say:

1. Test different work patterns
2. Build with Optimize
3. Run standalone (CTRL+f5)
4. Disable "Power Saver"/SpeedStep
5. Run for a reasonable time (not 2 seconds)
6. For multi-threaded perf dont forget to set GS SERVER MODE, otherwise your "new" will be 10-40% slower than it could
7. Profilers sometimes lie! They don't guarantee nothing. Great tools but sometimes they don't show whats happening and may be source of Heisenbugs

from benchmarkdotnet.

there was no progress for 8 months, so I made it up for grabs again

from benchmarkdotnet.

@MarekM25,

can I work on this issue as my first one?

Sure!

from benchmarkdotnet.

What I suggest that we can use helper class similar to that proposed by @omariom with two methods. The first one will check if the system is windows, save current power plan and eventually set performance to the HighPerf. Then we perform all benchmarks, and after that, we use the second method. The second method will restore the previous user power plan. Both of the methods will execute in the BenchmarkRunner class. What is your opinion about that?

Looks good to me.
Also, we need an option in Config which allows disabling this behavior.

from benchmarkdotnet.

Fixed in #952

from benchmarkdotnet.