My friend and I have been taking some performance engineering courses. One thing we’ve come to realize is how important calculating the maximum Floating-point Operations per second (FLOPs) of a CPU is. It turns out this is a little trickier than it looks.

This is a formula I use to calculate this value. The formula is number of cores * peak cpu speed * (max SIMD register size/32) * (fma throughput * 2). Let me break it down.

I’ve encountered several mentions of Wireguard on the net without being curious about its inner workings. I’ve come across multiple mentions of VPNs on the net without (again) ever being curious about their inner workings. This year, I decided to be curious about it. Since Wireguard has been touted as a simple VPN protocol and implementation, it seemed the perfect gateway to finally understand those sorts. Now, I believe that to strongly understand a computer-related topic, you should at least build a simple implementation of it. That is what Steve and I did.

This is a list of things I learned from building the Postgres-redis extension for Postgres in Rust. A retrospective design and implementation article, this is not. It is written here.

Building this extension opened my eyes to some of Postgres’s design details and Rust tricks. The things I learned might be ordinary and widely known, but I learned about them on this project. Here’s what I learned.

In the previous article, I wrote about the Shared Memory IPC mechanism. In this article, I will write about a similar IPC mechanism called Memory Mapped Files.

To fully understand this article, you’d need to understand virtual memory, which I covered in the Shared Memory article. Let’s talk about how mmap IPC works.

In the previous article, we covered the Message Queues IPC mechanism. This article will cover another one called Shared Memory.

Before discussing shared memory and how it can be used for IPC, we must know why such a thing as “Shared Memory” exists since we know that all the processes share the RAM they should be sharing memory. The thing is, they share and don’t share. This admittedly contradictory event is due to the magic of memory addressing. Let’s talk about that for a bit.

In the previous article, we covered Unix Signal and its usage for IPC. An implementation of a popular asynchronous communication pattern will be covered in this article.

In the previous article, we covered Unix Socket and how it can be used for Inter-Process Communication. This article discusses a different and limited form of IPC.

In the IPC mechanisms we’ve looked at and most other mechanisms, when an application process sends a message to another, an action is taken by the receiving process depending on the message received. The message will most likely be a byte or group of bytes. These bytes need to be parsed and checked to determine the appropriate action to take. The action to be taken might be calling a function, or executing a program expression. Sometimes, no action needs to be taken due to the application process receiving a message that’s not intended for it. Yet, the message needs to be parsed to take no action. How about letting the OS do the parsing to determine if our process needs to ignore? Let’s go further; what if we want the OS to execute a function in the application process?

In the previous article, We discussed the Named Pipes mechanism to achieve Inter-Process Communications. This article will cover another one called Unix Domain Sockets.

Sockets are the Unix abstraction of networking. When we think of networking, we imagine communication. The tools that make up the internet are majorly concerned with creating and maintaining communication pipes between computers. Our Operating Systems provide some of these tools. Since these are communication tools, what if we could use a few of these high-quality and reliable tools provided by our Operating Systems to enable processes to chat with each other? Good news! It turns out that it exists, and that’s the subject of this article.

In the previous article, We introduced Inter-Process Communication and its different mechanisms. We’ll start with the first, Named Pipes or FIFO file!

Named pipes are a mechanism that builds upon the structure of anonymous pipes. Your regular Unix pipes are actually Anonymous pipes. To understand named pipes, we need to understand anonymous pipes.

Have you ever thought of how two processes can communicate in one device?