Visual Studio Performance Profiling .Net Core console application shows significant CPU usage by "unwalkable" calls into nvlddmkm.sys

Question

I have a .Net Core console application that is single-threaded and CPU bound, so I'm trying to optimize performance. When I run Visual Studio 2019's Performance Profiler and choose the "CPU usage" tool, I get what you see below.

Why is 22% of all CPU time spent in the "unwalkable" calls to nvlddmkm.sys?

Here's my code:

using System;
using System.Linq;

class Program
{
    static void Main()
    {
        var random = new Random();
        const int length = 250;
        var array = new double[length];
        for (var i = 0; i < length; ++i)
        {
            for (var j = 0; j < length; ++j)
            {
                for (var k = 0; k < length; ++k)
                {
                    var index = i + j * k;
                    index %= length;
                    array[index] = random.NextDouble() + array[length - index - 1];
                    array[index] += array.Sum();
                }
            }
        }
    }
}

I noticed that calls into nvlddmkm.sys didn't happen (or at least didn't take as much time) without the Linq Sum.

I searched for what nvlddmkm.sys is. This page says:

Nvlddmkm.sys is a kernel mode driver for the Windows Longhorn project (a codename for Windows Vista) that adds support for shader models 3.0 and 2.0.

So what would Linq have to do with graphics?

Answer 1

First of all, those stats are dumb. What you want to know is which lines of your program are responsible for the time, and those stats don't come near telling you. Here's how I do it.

OK, if I'm hazarding a guess (and the first rule of performance tuning is - don't guess),
The new double[] call might show up as a major time-taker, because memory allocation is always suspect, but in this context I doubt it.
More likely, the array.Sum() call
Most likely, the random.NextDouble() call
These last two happen 15,625,000 times.
Everything else in your program is pretty trivial.

Answer 2

Did the compiler optimize the code to use matrix operations on the GPU? That could explain the need to talk to a shader DLL.