Fixing my classes with NDepend Graph View

NDepend's 2020 release has a new Dependency Graph view. I am keen to try it out, and I just have the prefect project for the test. In this post I will use the Dependency Graph view on one of my most 'messy' projects. The project is started as a Proof Of Concept (POC), then I based 3 other Proof Of Concept apps on it.

This made all namespaces, dependencies and responsibilities mixed. The Visual Studio solution consists of three projects. An ASP.NET Core project of the chatbot implementation, an Azure Functions project for managing IoT devices and a shared library project common types.

NDepend has a VS Extension, which streamlines work a lot, but at the same time it also has standalone executable, which does not require installation. I like these apps, because I can just drop them to my \tools folder and use them as needed. Once I notice that I use an app extensively for a period of time, I can install the VS Extension.

Dependency Graph First View

Find out more

Distributed Tracing with gRPC and OpenTelemetry

This blog post demonstrates distributed tracing for gRPC calls using OpenTelemetry. Application Insights and Zipkin exporters and services are used for visualizing spans.

gRPC is http based protocol. The client uses HttpClient to send requests, while the ASP.NET Core service is using standard HTTP pipeline to process requests and return responses. Both HttpClient and the HTTP pipeline are instrumented with System.Daignostics.DiagnosticListener. DiagnosticListener enables to subscribe to emitted events and activities. While events indicate a point in time notification, activities can describe a time interval. Both may use additional metadata attributes to describe the event or the time span.

For the collection of these events, I am going to use OpenTelemetry's C# client, version 0.2.0-alpha.179 at the time of writing this post.

In this post, I will have a .net core console application as the client and an ASP.NET Core 3.1 service as the server.

Find out more

False Cache Sharing with Spans


False cache sharing is a leaky abstraction of the CPU cache. CPUs cache memory in cache lines. Typically a cache line is 64 bytes long. That means when a single byte is required from the memory, the CPU rather brings in a full cache line, 64 bytes of data. This is beneficial from spatial/temporal locality principals. CPU cache is usually hierarchical, it has L1, L2 and L3 levels, each different size and speed. L1 and L2 is owned by the actual processor core, while L3 is a shared cache among all CPU cores.

You can find more details on CPU caching and false sharing in Pro .Net Memory Management by Konrak Kokosa.

Lower cache level being owned by the actual CPU cores means that when a data is modified in a cache line, it has to synchronize with other cores sharing the same cache line. This can have a negative performance effect: even in a synchronization free (at application code level) multithreaded application, the CPU cache might become a bottleneck by keeping their cache lines up-to-date.

Find out more

Even or Odd


One of the typical interview questions is deciding about a number if it is even or odd. The task usually goes by given a integer (or array of integers), return a bool (or array of bools) indicating if the number is odd or even.

A typical solution to the problem is using integer remainder operator:

public bool IntegerRemainder(int i) => i % 2 != 0;

Find out more

The Knapsack Problem with Hardware Intrinsics


I would like to thank Kristof for reviewing this post. He gave me great ideas to further discover the problem and to have a better understanding on AVX. Thank you, Kristof.

Introduction to the Problem

The Knapsack problem is an optimization task: given a set of items, each with a weight and a value, create a subset of these items so that their total weight is less than or equal to a given limit, and their total value is maximized.

Find out more