Stryker.NET VS kernel_tuner

Bogus - For creating fake data Verify - Snapshot testing for .NET MELT - For testing ILogger usage Stryker - Mutation Testing for .NET TestContainers - run docker programmatically in integration tests

This is called mutation testing btw.

Let's try it on our small example using Stryker.

There are tools that do this automatically, stryker[2] is one of them. When you run stryker, it will create many mutant versions of your production code, and run your tests for each mutant (that's how mutations are called in stryker's' documentation) version of the code. If your tests fail then the mutant is killed. If your tests passed, the mutant survived. Let's have a look at the the result of runnning stryker against reffects-store's code:

Mutation testing is pretty solid. Better than code coverage for sure. Using Stryker personally.

A mutation testing tool (like Stryker) runs your unit tests to verify they all pass then makes a small change (mutation) to your code and reruns the tests. At least one test should fail because the modified code should behave differently.

I haven't tried it yet, but last time I researched it, this is the library that looked most promising: https://stryker-mutator.io/

Website: https://stryker-mutator.io/

I've created Kernel Tuner (https://github.com/KernelTuner/kernel_tuner) as a small software development tool, because I was writing a lot of CUDA and OpenCL kernels at the time. I didn't want to manually figure out what best thread block dimensions and work division among threads were on every GPU over and over again.

The tool evolved quite a bit since the first versions. I'm also using it for testing GPU code, teaching, and it has become one of the main drivers behind a lot of the research that I do.

We have an open science policy, so anyone can use our framework yourself to optimize stuff, if you want! The original paper is linked at the bottom of the GitHub page.

This is a great post for people who are new to optimizing GPU code.

It is interesting to see that the author got this far without interchanging the innermost loop over k to the outermost loop, as is done in CUTLASS (https://github.com/NVIDIA/cutlass).

As you can see in this blog post the code ends up with a lot of compile-time constants (e.g. BLOCKSIZE, BM, BN, BK, TM, TN) one way to optimize this code further is to use an auto-tuner to find the optimal value for all of these parameters for your GPU and problem size, for example Kernel Tuner (https://github.com/KernelTuner/kernel_tuner)