Optimize C++ loops with std::memory_order_relaxed

Two C++ loops. Same code. Same flags. One: 0.25s Other: 1.25s 👉 Code didn’t change. 👉 CPU behavior did. If: instructions ≈ same cycles ↑ IPC ↓ cache misses ↑ 👉 It’s not compute 👉 It’s memory I wrote a deep dive on using perf to see this clearly. 📖 https://lnkd.in/gjzwJWTP If you’re not measuring, you’re guessing. #CPP #Performance #Systems #LLVM #compilersutra

Quantifying the Cost of the User-Kernel Boundary: A 215x Study in Latency 🐧 In systems programming, we often treat system calls as "slightly slower" function calls. To challenge this abstraction, I designed a micro-benchmark to measure the actual cycle-tax of crossing from user mode (Ring 3) to Kernel Mode (Ring 0). The Result: A 215x latency multiplier between a user-space instruction and a getpid() syscall. To ensure the results weren't skewed, I applied 2 critical constraints. 1. Memory Barriers & Volatility: Used the volatile qualifier to prevent the compiler's optimizer from pruning the loop during dead-code elimination. 2. Monotonic High-Res Timing: Leveraged clock_gettime(CLOCK_MONOTONIC) to avoid non-linearities caused by NTP updates or system time-of-day jumps. THE WHY ? The 215x isn't just code execution; it is the cost of the Hardware Trap. 1. Context Switch: The CPU must save the register state (GPRs) to the kernel stack. 2. Privilege Transition: Transitioning the processor state from User Mode (Ring 3) to Kernel Mode (Ring 0). 3. Interrupt Handling: The kernel must look up the syscall vector, verify permissions, and execute the routine before restoring the user-space context. In high-performance systems engineering, minimizing the "syscall tax" is critical(VERY VERY VERY CRITICAL) Whether optimizing Kubernetes pod lifecycles or building low-latency APIs, understanding the boundary between user-land and the kernel is what separates "code that works" from "code that scales". #SystemsProgramming #LinuxInternals #PerformanceEngineering #Kernel #LowLatency #SoftwareArchitecture

#Post7 In the previous post(https://lnkd.in/d6yT-aqc), we saw different components of process and learnt about thread specific components like: • Stack • Program Counter • Registers Although Stack and Program Counter was explained, but an important concept about Registers is still pending, which we will cover in this post. Now let’s understand something very important How does CPU actually execute multiple threads? A CPU cannot run all threads at the same time. It depends on the number of cores. Example: • 2 CPU cores → only 2 threads can run at a time But in real applications, we often have many more threads than cores. So what happens to the remaining threads? The CPU switches between them. This is called Context Switching. What is Context Switching? When the CPU switches from one thread to another: • It saves the current thread’s state • Loads the next thread’s state • Continues execution Where is this state stored? In registers. Registers store intermediate execution data. So when a thread is paused, its state is preserved, and later resumed from the same point. Important Insight More threads ≠ better performance If there are too many threads: • CPU spends more time switching • Less time doing actual work This leads to performance degradation. Key takeaway Context switching allows multiple threads to share CPU time, but excessive switching can reduce performance. Understanding this is crucial when designing multi-threaded systems. In the next post, we’ll explore how to choose the right number of threads and avoid performance issues. #Java #SoftwareEngineering #Multithreading #BackendDevelopment #Programming

Most developers use computers every day without ever understanding what's actually happening inside them. This week I decided to change that so I built a CPU emulator from scratch in TypeScript. Not a library. Not a tutorial clone. Built from first principles. Here's what it does: → 256 memory cells, each holding 8 bits just like a real machine → 16 general-purpose registers for temporary data storage → A program counter that tracks which instruction to execute next → A full fetch → decode → execute machine cycle → 12 machine language instructions including LOAD, STORE, ADD, OR, AND, XOR, ROTATE, JUMP and HALT → Proper 16-bit instruction encoding split across two memory cells To test it, I wrote a program in raw machine language that loads two values from memory, adds them, and stores the result. The CPU executed it correctly. And here's what surprised me most none of this is magic. Every concept has a clear, logical reason behind it. Why memory addresses are powers of two. Why instructions have op-codes and operands. Why the program counter increments by two. Why bitwise operations are at the heart of everything. Once you understand these foundations, the entire stack from assembly to operating systems to the code you write every day starts making a different kind of sense. You don't need a CS degree to understand how computers work at this level. You just need curiosity and time. #ComputerScience #TypeScript #SoftwareEngineering #FullStack #LearningInPublic #CPUArchitecture

GCC 16.1 has been released today. For me, GCC is not just a compiler. It is one of the great pillars of free software. It is the kind of infrastructure that makes operating systems, programming languages, embedded systems, scientific computing and serious engineering possible. This release brings important work. C++ now defaults to C++20. There is experimental support for more C++26 features, including reflection and contracts. The diagnostics are improving, with better structured error messages and SARIF output. The vectorizer is stronger. OpenMP and OpenACC support keeps moving forward. Fortran gains more Fortran 2018 and 2023 support. GCC also adds an experimental Algol 68 compiler. On the hardware side, there is support for AMD Zen 6, Intel Wildcat Lake and Nova Lake, improvements for AMD GPU offloading, LoongArch32 support and more target specific work. This is the kind of release that reminds me why the GNU toolchain still matters. Compilers are civilisation level software. They are invisible to most people, but without them almost nothing in computing exists. Respect to everyone who keeps GCC alive. Reference: https://lnkd.in/ezPFUgKD

What Really Happens with volatile in Embedded C? When working with Embedded C, I’ve learned that volatile is not just a keyword, it’s a contract with the compiler. A few key points that always matter: • The compiler may store variables in CPU registers instead of RAM. • It assumes values don’t change unless your code modifies them. • It aggressively optimizes away repeated memory accesses. A small but critical detail to consider: int flag = 0; while (flag == 0); At first, it looks like the CPU keeps checking flag in memory but in reality, compiler will • Load flag once into a register • Never read from memory again Even if: • An interrupt updates flag = 1, the loop may never exit. The fix: volatile int flag; Now: • Every loop iteration reads from memory. • The compiler assumes the value can change anytime. • External updates become visible. This is important because, Memory access behavior directly affects whether your system works correctly. This becomes especially critical in: • Embedded systems interacting with hardware registers. • Interrupt-driven designs. • Real-time systems where timing and correctness matter. One important clarification, volatile does not mean the program is thread-safe or immune to race conditions. It only tells the compiler “Do not optimize the memory access, this value may change externally.” #EmbeddedSystems #Firmware #CProgramming #STM32 #LowLevelProgramming #BareMetal #LearningJourney

In C++, traditional error handling can disrupt the most optimized hot paths. The hidden costs of Exceptions are often too high for performance-critical systems. 🔹 The Stack Unwinding Overhead: When an exception is thrown, the CPU must stop its current execution to search for a matching catch block. This process involves complex logic that is impossible to predict accurately, leading to significant latency spikes (Jitter). 🔹 The Binary Bloat: Supporting exceptions requires the compiler to generate extra data structures (exception tables) to track object lifetimes. This increases the binary size and can lead to less efficient Instruction Cache usage, even if an exception is never actually thrown. 🔹 The Alternative: Use patterns like std::expected (C++23) or simple return codes. This keeps the control flow explicit, the stack clean, and the execution time predictable. #CPP #LowLatency #SystemsProgramming #SoftwareEngineering #PerformanceOptimization #HFT #CodingStandard #ModernCpp

🚀 𝗠𝗼𝗱𝗲𝗿𝗻 𝗖++ 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗦𝗲𝗿𝗶𝗲𝘀 (𝗣𝗮𝗿𝘁 𝟵/𝟭𝟱) Even the fastest CPU can spend unnecessary cycles on tiny function calls. 🔥 𝗣𝗮𝗿𝘁 𝟵: 𝗘𝗻𝗮𝗯𝗹𝗲 𝗖𝗼𝗺𝗽𝗶𝗹𝗲𝗿 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝘀 & 𝗜𝗻𝗹𝗶𝗻𝗲 𝗛𝗼𝘁 𝗖𝗼𝗱𝗲 Every function call in C++ involves: • Pushing arguments onto the stack • Jumping to the function code • Returning to the caller ✅ Modern CPUs handle this quickly, but in hot loops, millions of calls can add up. 💡 𝗧𝗵𝗲 𝗙𝗶𝘅: 𝗜𝗻𝗹𝗶𝗻𝗲 𝗦𝗺𝗮𝗹𝗹, 𝗛𝗼𝘁 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀 inline tells the compiler: “Consider inserting this function here instead of calling it.” inline int add(int a, int b) { return a + b; } for (int i = 0; i < n; ++i) {   sum += add(x[i], y[i]); // likely inlined → no call overhead } • Best for tiny, frequently-called functions • Compilers may inline automatically even without the keyword • Avoid over-inlining → bloated binaries ⚡ 𝗘𝗻𝗮𝗯𝗹𝗲 𝗖𝗼𝗺𝗽𝗶𝗹𝗲𝗿 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝘀 Most performance gains come from letting the compiler do its job. GCC / Clang: -O2 # general optimization (inlining, dead code elimination, loop unrolling) -O3 # aggressive optimization (more inlining, vectorization, function cloning) MSVC: Use Release mode → /O2 or /O3 💡 Tip: Always profile in optimized builds, not Debug builds. 🚀 𝗥𝗲𝗮𝗹 𝗜𝗺𝗽𝗮𝗰𝘁 Benefit: inline small functions: Reduces call overhead in tight loops Compiler optimizations (-O2/-O3): Dead code elimination, loop unrolling, vectorization Trust compiler: Often smarter than manual tweaks 💡 𝗞𝗲𝘆 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Focus on algorithms, memory access, and cache efficiency first. Let the compiler handle the function-call overhead. Manual inlining rarely beats well-optimized builds. ← Previous: [https://lnkd.in/eFsVTjqs] → Next: [https://lnkd.in/e46JzD7k] 📌 Full Series Index: [https://lnkd.in/eHP6fJCX] #cpp #performance #moderncpp #compileroptimizations #systemsprogramming

For the past few days, I have been studying low-level OS concepts. T here I have wondered how the computer works so fast with multiple cores and how does it get optimised. For that I have been studying about openMP (Open Multi-Processing). It is the de facto standard for shared memory parallel programming. Normally a program runs sequentially : Task 1 → Task 2 → Task 3 → Task 4 But with the modern CPUs have multiple cores, openMP allows you to spilt that task into multiple threads, so it would look like this: Core1: Task1 Core2: Task2 Core3: Task3 Core4: Task4 This can significantly reduce the execution time for compute-heavy programs. OpenMP originally works on “The Fork Join Method”. So when the program starts there is only one main thread, but after the parallel region in the code, it forks into multiple threads, and once the once the heavy-lifting is done it joins back into that main single thread. Here is how it works compared to the normal code: Normal Code: #include <stdio.h> int main() {   for(int i = 0; i < 5; i++) {     printf("Iteration %d\n", i);   }   return 0; } Output: Iteration 0 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Code with OpenMP: #include <stdio.h> #include <omp.h> int main() {   #pragma omp parallel   {     int id = omp_get_thread_num();     printf("Hello from thread %d\n", id);   }   return 0; } Output: Hello from thread 2 Hello from thread 4 Hello from thread 3 Hello from thread 5 Hello from thread 1 Hello from thread 8 Hello from thread 6 Hello from thread 7 Hello from thread 0 Hello from thread 9 Here just by including #pragma omp parallel, we can work multiple threads to this task, where each thread executes the block.The magic of OpenMP lies in compiler directives (#pragma omp). It’s fascinating how you can take existing, sequential C code and incrementally parallelize a massive for loop with just a single line of text, without needing to rewrite your entire architecture. In distributed systems, we worry about network partitions and message delivery. In shared-memory space, our biggest enemy is the race condition. Getting hands-on with clauses like shared, private, and reduction to strictly control which thread owns or modifies which piece of data has given me a profound appreciation for compiler-level synchronization. Moving from the single-threaded asynchronous nature of Node.js to manually managing thread execution and shared memory boundaries has been challenging, but it is deeply rewarding. It strips away the abstractions and forces you to think about how the CPU actually processes your loops. I am currently exploring this area I never looked at and I will be sharing my learnings. If anyone else is exploring this area and want to add something I’d love to connect. Image from NERSC Documentation

While exploring ARM architecture, I discovered something that completely changed how I think about compilers. I wrote a simple C program. Compiled it twice — same code, same GCC, just a different target. The assembly output was unrecognizable between the two. Here's what I mean: ▸ gcc transpose.c -o output_x86 Registers: rax, rbx, rsp — instructions: mov, call, ret ▸ arm-linux-gnueabihf-gcc transpose.c -o output_arm Registers: r0, r1, r2, lr, pc — instructions: ldr, str, bl, pop Same C code. Completely different machine language. Because GCC doesn't just compile — it translates your logic into the native dialect of the target CPU. This is cross-compilation. And it runs through 4 distinct stages: ① Preprocessor — expands #include and #define ② Compiler — translates C into architecture-specific assembly ③ Assembler — converts assembly into binary object code ④ Linker — combines everything into a final executable Change the target architecture at step ②, and everything downstream changes with it. And then there's the static vs dynamic linking question: → Static (-static flag): all libraries baked in — ~870 KB, runs anywhere, zero dependencies → Dynamic (default): tiny binary ~16 KB, but requires the right libraries present at runtime For embedded targets? Static wins every time. The compiler isn't a black box. It's 4 precise steps — and understanding each one gives you real control over what runs on your hardware. . . . . . . . #GCC #ARM #CrossCompilation #EmbeddedSystems #Linux #LowLevelProgramming #C #SystemsProgramming #EmbeddedLinux #SoftwareEngineering