DEV Community: Dinesh Kumar Gnanasekaran

Benchmarking Claude C Compiler

Dinesh Kumar Gnanasekaran — Tue, 10 Feb 2026 06:41:25 +0000

TL;DR

I conducted a benchmark comparing GCC against Claude's C Compiler (CCC), an AI-generated compiler created by Claude Opus 4.6. Using a non-trivial Turing machine simulator as our test program, I evaluated correctness, execution performance, microarchitectural efficiency, and assembly code quality.

Key Findings:

100% Correctness: CCC produces functionally identical output across all test cases
2.76x Performance Gap: CCC-compiled binaries run slower than GCC -O2 but 12% faster than GCC -O0
3.3x Instruction Overhead: CCC generates significantly more instructions due to limited optimization
Surprisingly High IPC: Despite verbosity, CCC achieves 4.89 instructions per cycle vs GCC's 4.13

Here is the source code for the benchmark.
The results reveal an impressive achievement in compiler correctness combined with clear optimization opportunities.

Introduction

Challenge

Compiler construction is often considered one of the most complex problems in computer science. A production compiler must:

Parse and understand complex C syntax and semantics
Generate correct machine code for all edge cases
Optimize code for modern CPU architectures
Handle intricate ABI and calling conventions

Approach

My test program a Turing machine simulator(TM) exercises:

Dynamic memory allocation (linked lists)
File I/O and parsing
String manipulation
Complex control flow (state machine execution)
Command-line argument processing

The source code of the Turing machine simulator can be found here.
This doesn't represent a very complex C code base, it is simple, but far beyond trivial "hello world" programs.

Methodology

Test Environment

Component	Specification
CPU	AMD Ryzen 7 5800H with Radeon Graphics
OS	Linux 5.15 (WSL2)
GCC Version	12.2.0
CCC Version	14.2.0 (Claude's C Compiler)

Compiler Configurations

I tested three configurations to establish performance baselines:

GCC -O0 — Unoptimized baseline
GCC -O2 — Production-level optimization (our target standard)
CCC — Claude's compiler (default settings)

Benchmark Workload

The primary performance benchmark uses the Busy Beaver 5 problem, which executes for 47,176,871 Turing machine steps, ultimately writing 4,098 ones to the tape. This workload is ideal for compiler benchmarking because it:

Runs for multiple seconds (enabling stable statistical timing)
Executes billions of CPU instructions (~2.3B for GCC -O2, ~7.5B for CCC)
Performs extensive memory operations (dynamic tape expansion, pointer chasing)
Exercises the entire program (state machine logic, linked list traversal, memory allocation)
Produces deterministic, verifiable output

On average, each Turing machine step translates to approximately 48 x86-64 instructions for GCC -O2 and 159 instructions for CCC, clearly demonstrating the code generation efficiency gap.

Please follow this link to know about Busy Beaver problem.

Metrics Collected

Correctness:

MD5 hash verification across multiple test cases
Output comparison for Busy Beaver 3, 4, 5 and unary addition algorithms

Performance:

Statistical timing via Hyperfine (3 warmups, 5+ runs)
Hardware performance counters via perf stat

Code Quality:

Binary size analysis
Assembly instruction counts
Manual code review of generated assembly

Results: Correctness

The Most Important Finding

All correctness tests passed. CCC produces byte-for-byte identical output compared to GCC across different optimization levels.

Test Case	Description	Steps Executed	Status
Busy Beaver 3	3-state TM	14	✅ PASS
Busy Beaver 4	4-state TM	108	✅ PASS
Busy Beaver 5	5-state TM (benchmark)	47,176,871	✅ PASS
Unary Addition	3+2 arithmetic	9	✅ PASS

The compiler correctly handles:

Pointer arithmetic and dereferencing
Dynamic memory allocation (malloc/free)
Complex control flow with state transitions
File I/O with error handling
String formatting and parsing

Implication: CCC demonstrates a complete understanding of C semantics, type systems, and memory models. This is not merely translating syntax, it's implementing correct program behavior.

Results: Execution Performance

Statistical Timing Analysis

Compiler	Mean Time	Std Dev	Relative Speed
GCC `-O2`	0.1376s	0.0021s	1.00x (baseline)
CCC	0.3799s	0.0030s	2.76x slower
GCC `-O0`	0.4247s	0.0048s	3.09x slower

Key Observations

CCC Outperforms Unoptimized GCC

CCC is 12% faster than GCC's unoptimized output. This indicates the compiler applies some optimizations beyond naive code generation. The performance falls between completely unoptimized and production-optimized code.

Consistent Performance

Low standard deviation (0.003s) demonstrates stable execution characteristics. There are no unexpected performance cliffs or edge cases causing wild variance.

Room for Improvement

The 2.76x gap to GCC -O2 represents the optimization opportunity space. Given that CCC already beats -O0, this gap is primarily optimization passes, not fundamental code generation issues.

Results: Microarchitectural Analysis

Hardware Performance Counters

Performance counters reveal how code executes, not just how long it takes.

Metric	GCC `-O2`	CCC	Ratio
Cycles	549M	1,529M	2.79x
Instructions	2.27B	7.48B	3.30x
IPC	4.13	4.89	1.18x
Cache Miss Rate	1.92%	2.01%	1.05x
Branch Miss Rate	0.00%	0.00%	1.00x

The Instruction Inflation Paradox

CCC executes 3.3x more instructions than GCC, yet performance is only 2.76x slower. How?

To put this in perspective: the Busy Beaver 5 workload executes 47.2 million Turing machine steps. GCC -O2 translates this into 2.27 billion x86-64 instructions (~48 instructions per TM step), while CCC requires 7.48 billion instructions (~159 instructions per TM step). That's a 3.3x code bloat, yet the execution time penalty is only 2.76x.

Higher Instructions Per Cycle (IPC):

CCC achieves an IPC of 4.89 compared to GCC's 4.13. This seemingly counterintuitive result has a straightforward explanation:

Simple Instructions: CCC generates verbose but simple instruction sequences (mov, add, cmp)
Predictable Patterns: Repetitive stack loads/stores are easy for the CPU's front-end to decode
No Complex Dependencies: The lack of optimization means fewer register-register dependencies to track

In contrast, GCC's optimized code uses:

Complex instruction forms (movsbl, setbe, cmov)
Tighter register dependencies
More aggressive instruction reordering

This trades raw IPC for total instruction count, a net win in modern CPUs with deep pipelines and out-of-order execution.

Cache and Branch Prediction

Cache Performance: Nearly identical (1.92% vs 2.01% miss rate). The extra instructions don't significantly impact cache locality for this workload.

Branch Prediction: Both compilers achieve near-perfect branch prediction (<0.01% miss rate). The Turing machine's regular execution pattern is highly predictable.

Results: Code Quality Analysis

Binary Size Comparison

Section	GCC `-O2`	CCC	Overhead
.text (code)	6,768 bytes	11,295 bytes	+67%
.data	664 bytes	512 bytes	-23%
.bss	8 bytes	1 byte	-88%
Total	7,440 bytes	11,808 bytes	+59%

The code section bloat correlates directly with instruction count inflation. Interestingly, CCC produces smaller data sections, possibly due to different constant pooling strategies.

Assembly Code Metrics

Metric	GCC `-O2`	CCC	Ratio
Assembly Lines	1,297	2,500	1.93x
Instructions	720	2,025	2.81x
Avg Frame Size	Small	Large	~10-50x

Deep Dive: Assembly Code Analysis

To understand why CCC generates more code, I performed manual assembly review. The findings reveal fundamental differences in compilation strategy.

Register Allocation: The Core Difference

GCC Strategy: Register-Centric

GCC keeps values in CPU registers as long as possible:

movq    %rdi, %rbp          # arg stays in register
movq    %rbp, %rdi          # reuse later
callq   fopen@PLT
movq    %rax, %r13          # result to callee-saved register

Stack frame for get_cards(): 8 bytes (alignment padding only)

CCC Strategy: Stack-Centric

CCC round-trips nearly every value through stack memory:

movq    %rdi, -8(%rbp)      # store arg to stack
movq    -8(%rbp), %rax      # load back
movq    %rax, %rdi          # move to correct register
callq   fopen
movq    %rax, -16(%rbp)     # store result to stack

Stack frame for get_cards(): 112 bytes

The most extreme case is validate_cards():

GCC: 8 bytes of stack
CCC: 416 bytes of stack (52x larger)

Instruction Selection Quality

GCC: Expert-Level Idioms

Pattern	Example	Benefit
Zero idiom	`xorl %eax, %eax`	2-byte encoding, breaks dependencies
Vector zeroing	`pxor %xmm0, %xmm0; movups`	Zero 16 bytes in 2 instructions
Tail calls	`jmp puts@PLT`	Eliminate call overhead
Branchless	`setbe` (set-if-below-or-equal)	Avoid branch misprediction

CCC: Literal Translation

Pattern	Example	Issue
Redundant moves	`movq $40, %rax; movq %rax, %rdi`	Should be `movl $40, %edi`
Excessive sign-extend	`cltq` after positive loads	Unnecessary for known-positive values
No instruction combining	Separate load/compute/store for each operation	Misses optimization opportunities

String Literal Handling

GCC: Deduplication and Merging

.LC0:
    .string "System out of memory"

One copy, marked for linker merging.

CCC: Raw Bytes with Duplication

.Lstr2:  .byte 83,121,115,116,101,109,32,111,117,116,32,111,102,32,109,101,109,111,114,121,0
.Lstr3:  .byte 83,121,115,116,101,109,32,111,117,116,32,111,102,32,109,101,109,111,114,121,0
.Lstr7:  .byte 83,121,115,116,101,109,32,111,117,116,32,111,102,32,109,101,109,111,114,121,0
...

Seven copies of "System out of memory" exist in the binary. No deduplication, no linker merge hints. This alone accounts for significant .rodata bloat.

Missing Optimizations

Comparing to GCC reveals CCC lacks:

Register allocation — No graph coloring or linear scan
Constant folding — Immediate values go through registers unnecessarily
Dead code elimination — Unused computations remain in output
Peephole optimization — No instruction combining or pattern matching
Loop optimizations — No unrolling, induction variable elimination, or strength reduction
String pooling — No constant deduplication

What CCC Does Well

Despite optimization gaps, CCC demonstrates impressive capabilities:

Correct ABI Implementation

CCC properly implements x86-64 calling conventions:

Arguments passed in correct registers (%rdi, %rsi, %rdx, etc.)
Stack alignment maintained (16-byte boundary)
Callee-saved registers preserved
Return values in %rax

Defensive Code Generation

CCC emits ud2 (undefined instruction trap) after noreturn functions like exit(). This is actually a best practice, prevents execution from continuing if exit() somehow returns.

GCC trusts the noreturn attribute and omits this. CCC's approach is more defensive.

Tail Call Optimization

CCC correctly implements tail calls, converting:

printf(...);
return;

into:

jmp printf    # instead of call + ret

This is a legitimate optimization that many naive compilers miss.

Debug Information

CCC emits .loc directives referencing source files, indicating a working debug info pipeline. This enables debugger support.

Theoretical Implications

Can AI Write Compilers?

The results provide an empirical answer: Yes, with caveats.

What AI Does Well:

Understanding language semantics and type systems
Implementing correct code generation for complex constructs
Handling edge cases and ABI compliance
Producing working, debuggable binaries

What AI Struggles With:

Multi-pass optimization pipelines
Register allocation algorithms (graph coloring, linear scan)
Global analysis and program-wide optimization
Performance tuning and microarchitectural awareness

This aligns with our understanding of LLMs: they excel at pattern matching and local correctness but struggle with global optimization problems requiring graph algorithms and iterative refinement.

The Optimization Gap

The 2.76x performance gap is not a fundamental limitation, it's an optimization pass implementation gap. The core compiler (parser, type checker, code generator) is sound.

With targeted improvements, CCC could likely close this gap significantly:

Low-Hanging Fruit (Est. 30-50% improvement):

Basic register allocation (linear scan)
String literal deduplication
Simple peephole optimization

Medium Effort (Est. 50-80% improvement):

SSA-based optimization passes
Graph-coloring register allocation
Dead code elimination

High Effort (Approach GCC parity):

Loop optimizations
Instruction scheduling
Profile-guided optimization

Conclusion

Summary of Findings

Claude's C Compiler represents a significant achievement in AI-generated software:

Correctness: 100% functional equivalence with GCC across diverse test cases
Performance: 2.76x slower than optimized GCC, 12% faster than unoptimized GCC
Code Quality: Correct but verbose, with 3.3x instruction overhead
Architecture: Sound compiler design lacking optimization passes

The Bigger Picture

This benchmark demonstrates that modern AI can implement complex, specification-heavy software correctly, even for domains traditionally requiring deep expertise.

The gap between CCC and GCC is not one of capability, it's a gap of engineering investment. GCC represents 30+ years of optimization research and implementation. CCC represents an initial, working baseline.

Final Thoughts

The most surprising result isn't that CCC is slower than GCC, it's that CCC works at all. Compiler construction courses span entire semesters; teams of engineers spend careers optimizing code generators.

That an AI model can produce a functionally correct, ABI-compliant C compiler from scratch, one that handles pointers, dynamic memory, and complex control flow, marks a remarkable milestone.

The optimization gap is not a limitation of AI capability. It's a reminder that correctness and performance are separable concerns, and AI has achieved the harder one first.

References

GCC Optimization Manual: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
x86-64 ABI Specification: https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf
Modern Compiler Implementation in C (Appel)
Engineering a Compiler (Cooper & Torczon)

Using Claude Code to solve Advent of Code 2025

Dinesh Kumar Gnanasekaran — Sat, 03 Jan 2026 08:41:25 +0000

Introduction

Let's be honest: with LLMs, the fun of Advent of Code is gone. You can paste any puzzle into ChatGPT or Claude and get a working solution in seconds. So I did it anyway, but to run a different experiment with Advent of Code 2025: what if I didn't write a single line of code? Instead, I gave Claude Code a single instruction file and let it solve the puzzles completely autonomously.

The result: 20 out of 22 challenges solved (91% success rate) with zero human-written code.

Check out my repo for more details

The Setup

I created a single file called INSTRUCTIONS.md with a 12-step process for each day:

Create a folder ./day_xx/
Navigate to the Advent of Code puzzle page
Save the input to ./day_xx/input.txt
Read Part 1, write strategy in ./day_xx/README.md
Write ./day_xx/part1.py
Test with examples
Run against actual input and submit
Write Part 2 strategy in README
Write ./day_xx/part2.py
Test Part 2
Run Part 2
Submit Part 2 answer

Then I ran: claude --chrome --dangerously-skip-permissions

Note: The --dangerously-skip-permissions flag bypasses all safety checks. This is terrible for production use, but necessary for this experiment where the agent needed to navigate websites and submit answers autonomously.

What Happened

Claude Code executed the entire workflow independently:

Used Chrome integration to navigate Advent of Code
Read puzzle descriptions on its own
Developed solution strategies and documented them
Wrote and tested Python code
Submitted answers to the website
Self-corrected when answers were wrong

Zero lines of code written by me. Just the instruction file.

Results

Completed: Days 2-8 (both parts), Day 9 Part 1, Days 10-11 (both parts), Day 12 Part 1

Failed: Day 9 Part 2, Day 12 Part 2

Total: 20/22 challenges = 91% autonomous completion

The repository generated approximately 42 Python files across days 2-12, each with full solution code, test files, and documented reasoning.

Example: Day 2 Strategy

Here's how Claude Code documented its approach for Day 2 (from the auto-generated README):

Part 1: Detect product IDs where "any substring starting from position 0 appears immediately after itself" (exactly twice repetition).

Part 2: Expand to catch IDs where "the entire string can be formed by repeating that substring at least 2 times."

The agent independently reasoned through the problem, identified the algorithmic approach, and implemented it - all without human guidance beyond the instruction template.

Limitations

Even with 91% success, the agent failed on 2 challenges. Looking at the failures:

Day 9 Part 2: Complex disk defragmentation problem that likely needed algorithmic insight the agent couldn't generate
Day 12 Part 2: Blocked by Day 9 Part 2's failure (dependency issue)

Some problems still require human algorithmic intuition and creative problem-solving. The agent excels at execution but can struggle with novel algorithmic insights.

Conclusion

This wasn't about pair programming or AI assistance. This was about autonomous execution from start to finish.

The agent navigated websites, read natural language descriptions, formulated strategies, wrote code, debugged failures, and submitted results - all independently. The only human input was a procedural instruction file.

Are we ready for fully autonomous development? Not quite. That 9% failure rate matters, especially when complex algorithmic thinking is required. But 91% autonomous completion on varied programming challenges suggests we're closer than I expected.

The future isn't AI replacing developers. It's developers orchestrating autonomous agents - providing high-level direction while the agent handles execution, testing, and iteration.

As I watched Claude Code navigate Advent of Code independently, I realized: the question isn't "can AI code?" anymore. It's "what level of abstraction should humans work at when AI handles the implementation?"

Check out the full repository to see all the auto-generated code and conversation transcripts.

Deep Maze Solver

Dinesh Kumar Gnanasekaran — Wed, 31 Dec 2025 07:56:07 +0000

Introduction

A few days ago saw a X Post explaining that diffusion models could be used to solve algorithmic tasks like solving mazes. Intrigued by this post, I was curious to replicate this work at least on a smaller scale. So I began my journey to build a neural network that can solve mazes.

Problem

The aim is to build a convolutional neural network(CNN) that can solve mazes using supervised learning. Given a maze image, the CNN has to find the path from the top left corner of the maze to the bottom right corner. We are using PyTorch for this task.

Dataset

Since creating and solving mazes is deterministic, we have an infinite dataset glitch. We are going to create mazes and solutions on the fly! Yes, we have infinite datasets and we do not want to label them manually, this sounds like a dream!

To create a maze, I’m using the Recursive Division algorithm, and to solve it, I’m using good old Depth-first Search. Maze generation and maze solvers require posts on their own; feel free to go down this rabbit hole. Due to the resource constraints on my end(cough… GPU… cough) the dataset will only contain mazes of sizes from 5x5 to 127x127. Here, nxn means the number of blocks horizontally and vertically. We will resize the mazes to create an image of size 128x128(we can use any size, but we need to wage a war with padding the outputs from the different layers of the network) using nearest neighbor interpolation. The goal is to connect the top left corner of the maze to the bottom right corner of the maze. There is only one path that connects any two points in our maze.

Here is a sample 57x57 maze and its solution.

Pre-processing

The input will be the maze, and the labels will be the solved maze. We can simplify the format of the dataset so the network can learn and predict just the solution and not worry about rendering the borders and other structures.

Here is the same maze with the solution showing only the path.

Finally, we resize them to 128x128 to get the final input and labels

The image gets a little bit distorted due to resizing, but still, it does not modify the structure of the maze, so this shouldn’t be a problem.

The Model

We are going to use a regular U-Net to solve this problem. Nothing fancy.

Training

Here are the hyperparameters

Batch Size - 16
Optimizer - Adam
Loss - Binary Cross Entropy
Learning rate - 10-4
Train dataset - 500,000
Validation dataset - 100,000

When we train the model using the entire train dataset, we call it one epoch. Since we randomly generate mazes epochs don’t mean anything here.

Result

Here is the training loss computed for every 1,000 samples. The validation loss was calculated using 200 samples after training on 1,000 samples.

Here are a few results from the model

The model performs well for the mazes of small and medium sizes, but it struggles a bit to solve a big maze. But I think this can be solved using the same modern techniques companies predominantly use right now(Big model, Big data, Big time training, Big hardware, Big Money)

Conclusion

Well, it has been very interesting working on this project. We know neural networks are being used to solve way more complex problems, but it is fascinating to look at them to solve algorithmic problems like these.

Here is the link to the GitHub repo if you are curious to know behind the scenes.

Also, shoutout to this wonderful repo for providing the U-Net code.

3D Glowsion Ball with Three.js

Dinesh Kumar Gnanasekaran — Sun, 09 Jul 2023 04:53:51 +0000

Introduction

We are going to make a Glowsion Ball in three.js. What is glowsion ball, you may ask? Well, I just came up with this name just because it sounded cool.

TLDR;

What?

three.js is an open-source graphics library in javascript. It uses WebGL API to render graphics and can also utilize GPU. It is used to build 2D and 3D graphic animation on websites. It is not a drop-in replacement for the game engines, but just a simple one that helps us to build beautiful websites.

We are not going to see the basics of computer graphics, we are going to see the basic building blocks just to stitch a cool ball.

Basics

We need just simple HTML and CSS to get started. We need a canvas element in our body and some simple CSS to take care of silly stuff like background color, overflow, ...

Build

Import all the necessary modules. Get the HTML canvas element. Also, store the window sizes in an object, so it makes our life a bit easy.

// Sizes
const sizes = {
  width: window.innerWidth,
  height: window.innerHeight
}

// Canvas
const canvas = document.querySelector('#canvas');

Main Components

There are four main components to render graphics

Scene
Camera
Light source
Renderer

Here we are not going to use a light source, because we are creating a glowing ball.

// Setup
const scene = new THREE.Scene();

// Camera
// https://threejs.org/docs/#api/en/cameras/PerspectiveCamera
const camera = new THREE.PerspectiveCamera(
    75,
    sizes.width / sizes.height,
    0.1,
    100
);
camera.position.set(0, 10, 0); // place the camera at this position
camera.lookAt(0, 0, 0); // point the camera to this position

// Renderer
const renderer = new THREE.WebGLRenderer({canvas: canvas})
renderer.setSize(sizes.width, sizes.height); // size of the canvas
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)); // pixel ratio

Now we are going to create the glowsion ball. We need to create a mesh. A mesh is an object you render on the canvas. We need to define two things to create a mesh

Geometry
Material

For the geometry, we are going with sphere, for the material we going to create custom shaders.

Shady

We need two shaders

Vertex Shader (modifies the shape of the geometry)
Fragment Shader (modifies the pixel value, color on the geometry)

Both of them are written in GLSL (OpenGL Shading Language). This is where things get complicated. Learning GLSL is a full-time job on its own. To keep things simple we are skipping this part and voila we have our custom shaders.

// Objects
const glowsion = new THREE.Mesh(
  new THREE.SphereGeometry(1, 64, 64),
  new THREE.ShaderMaterial({
    vertexShader,
    fragmentShader,
    side: THREE.DoubleSide,
    uniforms: {
      uTime: { value: 0 },
      uResolution: { value: new THREE.Vector2() },
      uDisplace: { value: 2 },
      uSpread: { value: 1.2 },
      uNoise: { value: 16 },
    },
  })
);

You can view the vertex shaper here and fragment shader here

Now add the object and camera to the scene

scene.add(glowsion);
scene.add(camera);

Post Processing

Right now the glowsion ball is bland. To add a wow factor we are going to do some post-processing by adding Bloom Pass.

// Post Processing
const composer = new EffectComposer(renderer);
composer.addPass(new RenderPass(scene, camera));

// Bloom Pass
const bloomPass = new UnrealBloomPass(
new THREE.Vector2(window.innerWidth, window.innerHeight),
  1.4,
  0.0001,
  0.01
);
composer.addPass(bloomPass);

Final Loop

Add things in the loop and we get Glowsion Ball.

// Animate
const clock = new THREE.Clock()
const tick = () => {

    // Update objects
    // You can use any function to move the object
    glowsion.rotation.x = 5 * Math.tan(clock.getElapsedTime() + 0.25);
    glowsion.rotation.y = Math.tan(clock.getElapsedTime() + 1.0);
    glowsion.rotation.z = 5 * Math.tan(clock.getElapsedTime());

    // Render
    renderer.render(scene, camera);
    composer.render();

    // Call tick again on the next frame
    window.requestAnimationFrame(tick);
}

tick();

Conclusion

I hope this article gave you a fun introduction to three.js. There is so much you can do with this library. You can check out the website and see the cool projects. Also, I have created a cool three.js animation of some planets, check it out here. Happy learning!

Vector Databases: Make Your Image Applications a Reality

Dinesh Kumar Gnanasekaran — Wed, 05 Jul 2023 03:38:51 +0000

Introduction

A vector database is a database that stores data as high-dimensional mathematical objects called vectors. We are going to see how this is useful in context with images from one of the projects I worked on.

Face Recognition

In 2021 I worked with a team to build a face recognition system as an MVP. We used Facenet from Google. I’m not going bore you with the dataset used or the model training techniques of Facenet. We are going to see the overall architecture used to explain the necessity of a vector database.

Tech Stack

This is the stack we used

Front End - Flutter mobile app to get the information and images.
Back End - FastAPI
Database - MongoDB (this was the only option given to us)

Workflow

There are two workflows one for registering users in the database and one for inference(recognition).

Registration

For registration, we get the details and images from the mobile app. The regular processing with the name, date of birth, … were done by another process. We get the image and feed it into the model; the model outputs a 128-dimensional vector/embedding. This vector is a unique signature of your face, like your fingerprint. We store this vector in the database.

Inference

For inference, we get the image from the mobile app and feed it into the network to generate the 128-dimensional vector. Now we compare this vector with all the vectors in the database using a similarity metric (euclidean distance or cosine distance).

Yes! you need to query every single vector in the database. If the database has millions of vectors stored, we cannot fit them in our memory, so we need to do some batch processing. This is super, super slow, consumes a ton of memory, in short, is not scalable.

After this, we choose the vector in the database with the maximum similarity score (say Person A’s vector), and we threshold it. For example, we use cosine similarity(range is from 0, meaning least similar, to 1 meaning most similar) with a threshold value of 0.4. If we get a score of 0.2(<0.4), which is very low, we can declare that the person is not in the system. If we get a score of 0.8(>0.4), we can declare that the person in the image is Person A.

This is known as zero-shot learning, we use the model for prediction without any specific training.

Drawbacks

As you know, neural networks are slow and need a lot of resources, which means you need to set up a system with expensive hardware, parallelize it, implement a queuing system, and more.
During inference, we compare the thousands or maybe even millions of vectors. This means we must parallelize the operations and index the database to get the results fast.

Solution

Enter Vector databases! The figure below shows the rough idea of a vector database.

Basically all the processes are taken care by the vector database. We only need to receive the request from the front end, make corresponding operation with the database, get the results and forward it to the front end.

It is parallelized, indexed for faster inference, and it can be scaled relatively smoothly, solving the drawbacks we saw earlier. We can use different models to generate embeddings/vectors. Also, we can set the similarity metric to compare the vectors.

Conclusion

This is an overview of using vector databases in the context of images. Vector databases are used in many ML applications like semantic searching(NLP), etc… I Hope this article gave you an overall view and use case of vector databases.

Moving metrics in Batch Normalization

Dinesh Kumar Gnanasekaran — Mon, 26 Jun 2023 00:51:57 +0000

Introduction

A loose definition of moving metrics is calculating metrics on the fly. Recently I wrote my own version of Autograd and a neural network library called centigrad, similar to PyTorch and that is where I wandered to this topic.

The thought

If you have used PyTorch to build a neural network, you would have noticed that before training the model you will use this call model.train() and model.eval() for evaluating the model or preparing the model for production. Ever wondered why we use them? There are quite a few of them, but for the sake of this article, we will stick to Batch Normalization layers. This equation gives us the operation of batch normalization

(\frac{x - \mu}{\sqrt{\sigma^2}})*\gamma + \beta

Where $x$ is a single sample from the batch, $μ\mu$ is the mean of the batch and $σ2\sigma^2$ is the variance of the batch. $γ\gamma$ and $β\beta$ are the scale and shift learnable parameters respectively.

During training, we calculate the mean and variance of the entire batch and do the calculations. Also during this phase, we keep track of moving mean and moving variance across the batches. Why? Because we use these moving metrics during the evaluation phase. Why? Because when using the model in production or during evaluation we typically do not have the same batch size(sometimes we just use a single input).

Also, the moving metrics are calculated on the training dataset, which captures the general trend.

Calculation

Now we know the necessity of the moving metrics, let us get into the implementation. Let’s start with a simple solution. To get the moving mean and moving variance, we store the elements in an array and finally calculate the mean and variance of the array. Yes, you are right it is a horrible solution. Why? The solution is linear space complexity. Given the large batch sizes and size of the vectors, we would need ginormous storage to get the moving mean and moving variance.

Say we need to train a Convolutional Neural Network(CNN) with 100 batch normalization layers with a total of 1000 batches, with images of size 256x256x3. Also, the vectors in the intermediate layers could have varying dimensions with hundreds of channels. Imagine the space required to calculate the moving metrics. And this is a simple CNN. Imagine the space required for the models like GPT where we have numerous layers with billions of parameters.

Let's do math

So how do we overcome this problem? Math! Well, Math with a simple trick. Let us assume that we need to compute the mean for $n$ batches

\mu_n = \frac{X_1+X_2+X_3+...+X_{n-2}+X_{n-1}+X_n}{n}

Where $X_i$ is a sample from $i^{th}$ batch. We assume that we know the mean for $n - 1$ batches

\mu_{n-1} = \frac{X_1+X_2+X_3+...+X_{n-3}+X_{n-2}+X_{n-1}}{n-1}

Altering the above equation

(n-1)*\mu_{n-1} = X_1+X_2+X_3+...+X_{n-3}+X_{n-2}+X_{n-1}

Substituting this equation in the first one, we get

\mu_n = \frac{(n-1)*\mu_{n-1}+X_n}{n}

The rest of the steps are just rearranging the terms until we get a good form

\mu_n = \frac{n*\mu_{n-1}-\mu_{n-1}+X_n}{n}

\mu_n = \frac{n*\mu_{n-1}}{n}+\frac{X_n-\mu_{n-1}}{n}

\mu_n = \mu_{n-1}+\frac{X_n-\mu_{n-1}}{n}

With this equation, we just need to know the current sample, the current sample size, and the previous mean to calculate the running mean. We can do something similar to calculate the moving variance as well. With this, we have reduced our space complexity to constant. A simple but elegant trick has given us a beautiful solution.

Conclusion

Moving metrics are used in a lot of applications. Especially in real-time applications. For example, a version of this is used to create a moving average filter, which is used to reduce noise in signal in real-time. It is amazing how the frameworks we use on a daily basis have amazing things like these. I found this quite interesting so wanted to share it with you guys.

WSL. A Linux killer?

Dinesh Kumar Gnanasekaran — Sat, 01 Oct 2022 02:39:46 +0000

BackGround

My first laptop at college was a pretty low spec (I had no other option). It had an intel i3 4th gen processor and 4 Gb RAM (Ouch!) with Windows. In the beginning, it was smooth (sort of), but had no trouble. Then as the days passed the machine became very sluggish, like booting it up took a millennium. Then I got into programming and found Linux. I dual-booted my laptop with Ubuntu and it was a breath of fresh air. It was not lagging and it was pretty snappy. As days went on I learned more about Linux and the various distros, then I erased the drive and installed PopOs. Everything was going well.

Renaissance

Then I decided to go for my master's. Finally, I decided to get a new laptop, with better specs. I went for Ryzen 7 5800H, RTX 3050Ti, 16 GB DDR4 RAM, and 512 GB NVMe SSD. As a Linux lover, I wanted to install a new distro on my new machine. I tried distro after distro with the bootable USB drive, and there were always some critical issues. The most crucial issue was I can not find WiFi drivers. I know that somewhere on the internet I can find it, but it takes a lot of time.

Found It!

While I was into researching Linux, I came across WSL (Windows Subsystem for Linux). In a nutshell, WSL allows you to run Linux in Windows! It is in version 2 now. As we all know the heart of Linux is the command line. If you ask me the command line makes Linux, Linux. It took some time to install it, but Microsoft has good installation documentation, and Voila you got Linux in Windows.

Nice

Still, I hate some of the annoyance of Windows, but I don’t miss anything big from Linux. It has good support from a lot of dev tools. VS Code runs well, Docker runs well, and more than that Nvidia drivers work well. People who try to install Nvidia drivers on a Linux machine know the pain of installing Nvidia drivers. After using it for over a year I don’t feel like missing Linux.

Linux In Windows kills Linux?

As we all know developers are the ones who use Linux most of the time. I know devs who dual boot their machine with Windows and Linux because they need some apps like PhotoShop to edit images for their websites. Shut it down and boot Linux to get the dev work done and then find out that the image has the wrong dimension. Again shut it down boot Windows and repeat the process an infinite number of times. WSL completely solves this issue. Yes, there might be some performance issue, but I never noticed it.

Also in the latest major update, you can even run some of the Linux GUI applications as well. What more do you need?

Thoughts

In terms of use, I don’t think there are any significant drawbacks to using WSL. What do you guys think?

Two Symbol Turing Machine

Dinesh Kumar Gnanasekaran — Wed, 27 Oct 2021 19:47:57 +0000

Introduction

A Turing machine is a mathematical model used for computation by using infinitely long tape with symbols and a set of instructions. It was proposed by Alan Turing (remember, The Imitation Game) in 1936.

All the programming languages are Turing complete and all the computer hardware (well almost) are Turing complete, meaning that they can do everything that a Turing machine can do. A two symbol Turing machine is a Turing machine that uses only two symbols (eg. 0’s and 1’s) for computation.

Well!, let's get straight to the point and see what’s a two symbol Turing machine.

The Components

A Turing machine has three components

Infinitely long tape
Read/write head
Set of instructions

The Turing machine uses infinite tape, to read and write symbols using the head on the tape by following a set of instructions.

How does it work?

Let us see the working of our Turing machine through an example of unary addition.

Unary addition is simple stroke addition, say we add three strokes with two strokes we get five strokes

||| + || = |||||

So, let's assume that our Turing machine uses two symbols 0 and 1.

The initial tape is given below, where * represents the read/write head of the machine.

      * 
0 0 0 1 1 1 0 1 1 0 0 0

The instructions are in three cards.

CARD-1
SYMBOL	WRITE	SHIFT	NEXT
0	1	R	2
1	1	R	1

CARD-2
SYMBOL	WRITE	SHIFT	NEXT
0	0	L	3
1	1	R	2

CARD-3
SYMBOL	WRITE	SHIFT	NEXT
0	0	R	0
1	0	R	0

The machine works as follows,
The machine begins with an initial card
The head reads the symbol on the tape
The head erases and writes the new symbol on the tape according to the symbol read
The head shifts in the direction (left or right) according to the symbol read
The machine follows the next cards according to the symbol read
The machine repeats the steps 2 to 5 until the halt card (CARD -0)

Walk Through

Our machine starts initially with CARD -1, with the initial tape.

INITIAL STATE
      * 
0 0 0 1 1 1 0 1 1 0 0 0

The head encounters symbol 1, so it writes 1 shift to the right and follows the instructions from the next card, CARD -1 itself. The same happens two more times.

STEP 1
        * 
0 0 0 1 1 1 0 1 1 0 0 0

STEP 2
          * 
0 0 0 1 1 1 0 1 1 0 0 0

STEP 3
            * 
0 0 0 1 1 1 0 1 1 0 0 0

At STEP 3 the machine stills follow CARD -1. The head reads the symbol 0, now the head erases 0 and writes 1, shifts to the right, and goes to CARD -2 for the next instructions. Then, the head reads 1, writes 1, and shifts to the right. This repeats again for another step.

STEP 4
              * 
0 0 0 1 1 1 1 1 1 0 0 0

STEP 5
                * 
0 0 0 1 1 1 1 1 1 0 0 0

STEP 6
                  * 
0 0 0 1 1 1 1 1 1 0 0 0

Now, the head reads symbol 0, following the instructions from CARD -2, it writes 0, shifts left and gets the next instructions from CARD-3.

STEP 7
                * 
0 0 0 1 1 1 1 1 1 0 0 0

Now, the head reads symbol 1, it erases and writes 0, shift to the right, and the next card is CARD -0 (HALT)

Conclusion

In this article, we had a brief discussion on what is a Turing machine, especially a two symbol Turing machine. We went through the working of two symbols Turing machine through an example of unary addition.

I have implemented the two-state Turing machine in C and you can access through this link.

You can create your own Turing machine with the flexibility of adding custom instructions and tape, with step-by-step visualization. I have added some interesting tapes and cards for you to implement.

We have just touched the tip of the iceberg. There are very interesting puzzles which we can play with the Turing machine. One such puzzle is the Busy Beaver problem, a truly fascinating one. If interested just take a peek at it. The GitHub link contains some busy beaver cards and tapes as well.

Is Progress bar (tqdm) killing your code?

Dinesh Kumar Gnanasekaran — Wed, 13 Oct 2021 04:53:41 +0000

Introduction

Everyone familiar with Python knows that the quick and effective way to implement a progress bar is to use the tqdm package. A simple pip install will get you going. I have been using tqdm for a long time may it be for fun side projects or production code.

The Task

Recently I was implementing a fully connected neural network using just the NumPy library and comparing its performance with popular deep learning frameworks TensorFlow and PyTorch. Check out this link if you are interested in this project.

It is important to monitor the loss of the model as it is training and the best way according to me is to implement a progress bar that can track the amount of training completed and the loss at that point.

TensorFlow comes with this feature out of the box, which is very good. On the other hand in PyTorch we have to implement the training loop and a progress bar if we need it. Also, I wanted a progress bar for my NumPy implementation. So I used tqdm to implement it.

What!!!

I implemented a progress bar such that I update it for every iteration. With this implementation, for the same dataset with the same number of epochs and with the same parameters, my custom implementation and PyTorch implementation ran 10 epochs for around 60 minutes, while the TensorFlow implementation finished the same task in just 25 minutes. What!!!

I thought it was because Tensorflow may be utilizing some optimization to run faster. So out of curiosity, I started to dig deep, and, finally I found out that the progress bar was the culprit. Then I modified the progress bar to be updated after 500 iterations and tada!, both PyTorch and custom implementation ran under 10 minutes!!!

This also raised a question in my mind, What if the update cycle of the progress bar in TensorFlow is affecting its performance? Well, it could be.

Example

Let's look at an example to make things clear

from time import time
from tqdm import tqdm

LOOP = 50000

def task(update_cycle):
    pbar = tqdm(total=LOOP)
    for i, _ in enumerate(range(LOOP)):
        for _ in range(LOOP):
            pass

        if i % update_cycle == 0:
            pbar.update(update_cycle)

    pbar.close()

tic = time()
print(f'Update cycle: {1}')
task(1)
toc = time()
print(f'Time elapsed: {toc-tic:0.2f} seconds\n')

tic = time()
print(f'Update cycle: {500}')
task(500)
toc = time()
print(f'Time elapsed: {toc-tic:0.2f} seconds')

The output of the code

As we can see when the update cycle is big the task completes faster. I know it is a dumb example, but it gives the gist of the problem.

Conclusion

tqdm is a fantastic package to implement progress bars. We can get a usable progress bar with just a single line of code and also it gives a wide range of customization. But next time when you implement a progress bar just make sure that it does not affect the performance.

Game of Life in Rust

Dinesh Kumar Gnanasekaran — Sat, 09 Oct 2021 03:32:28 +0000

Introduction

Rust is an uprising programming language that is loved by the community. The main reason for the upsurge of Rust in recent times is that the language is built for performance and concurrency with safety in mind. At present, the popular use case of Rust is WebAssembly.

So, I wanted to get a gist of the language. The best way(according to me) to learn is to recreate something in the new programming language, which you have already done in a familiar programming language. Hence, I went on to program a simple version of Conway’s Game of Life.

Conway’s Game of Life

Game of Life is a cellular automaton proposed by the mathematician John Horton Conway. The universe of Game of Life is an infinitely large plane with square cells, which are either in two states alive, or dead, bound by certain rules.

A live cell with less than two live neighbors dies.
A live cell with more than three live neighbors dies.
A dead cell with exactly three neighbors becomes alive.
A live cell with two or three neighbors continues to live.

For more information on Game of Life visit this link. To visualize and play with Game of Life you can visit my web application.

Getting Rust

The first step is to install Rust, which you can do by visiting the official Rust site.

You can create your Rust project by entering the following command in your terminal.

cargo new game_of_life

Get into the directory using the command

cd game_of_life

Inside this main directory, you will see a main.rs file inside the src folder. This main.rs is the main file that will be built and executed.

Rusting Game of Life

In this example, we going to recreate a blinker, an interesting pattern in Game of Life.

In our example, the universe of Game of Life is a two-dimensional vector in Rust, which we will call it a grid, with 1 representing a live cell and 0 representing a dead cell.
The code is given below.

// function to compute the next generation
fn gol(grid: &Vec<Vec<i8>>) -> Vec<Vec<i8>> {

    // get the number of rows
    let n = grid.len();

    // get the number of columns
    let m = grid[0].len();

    // create an empty grid to compute the future generation
    let mut future: Vec<Vec<i8>> = vec![vec![0; n]; m];

    // iterate through each and every cell
    for i in 0..n {
        for j in 0..m {

            // the current state of the cell (alive / dead)
            let cell_state = grid[i][j];

            // variable to track the number of alive neighbors
            let mut live_neighbors = 0;

            // iterate through every neighbors including the current cell
            for x in -1i8..=1 {
                for y in -1i8..=1 {

                    // position of one of the neighbors (new_x, new_y)
                    let new_x = (i as i8) + x;
                    let new_y = (j as i8) + y;

                    // make sure the position is within the bounds of the grid
                    if new_x > 0 && new_y > 0 && new_x < n as i8 && new_y < m as i8 {
                        live_neighbors += grid[new_x as usize][new_y as usize];
                    }
                }
            }

            // substract the state of the current cell to get the number of alive neighbors
            live_neighbors -= cell_state;

            // applying the rules of game of life to get the future generation
            if cell_state == 1 && live_neighbors < 2 {
                future[i][j] = 0;
            } else if cell_state == 1 && live_neighbors > 3 {
                future[i][j] = 0;
            } else if cell_state == 0 && live_neighbors == 3 {
                future[i][j] = 1;
            } else {
                future[i][j] = cell_state;
            }
        }
    }

    // return the future generation
    future
}

// main function
fn main() {

    // set the number of rows and columns of the grid
    let (rows, cols) = (5, 5);

    // create the grid
    let mut grid: Vec<Vec<i8>> = vec![vec![0; cols]; rows];

    // set the initial state of the grid (blinker)
    grid[1][2] = 1;
    grid[2][2] = 1;
    grid[3][2] = 1;

    // print the initial state of the grid;
    println!("Initial grid:");
    grid.iter().for_each(|i| {
        println!("{:?}", i);
    });

    println!("");

    // Number of generations
    const ITR: u8 = 5;

    // compute and print the next generation
    for i in 0..ITR {
        grid = gol(&grid);

        println!("Generation {}:", i+1);
        grid.iter().for_each(|i| {
            println!("{:?}", i);
        });
        println!("");
    }
}

Then run the command given below to build and execute the file.

cargo run

The output of the code is given below. As you can see from the output, the oscillating structure blinker in the middle of the grid.

Initial grid:
[0, 0, 0, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 0, 0, 0]
Generation 1:
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]
[0, 1, 1, 1, 0]
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]
Generation 2:
[0, 0, 0, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 0, 0, 0]
Generation 3:
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]
[0, 1, 1, 1, 0]
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]
Generation 4:
[0, 0, 0, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 0, 0, 0]
Generation 5:
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]
[0, 1, 1, 1, 0]
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]

Observations

At a first glance, the Rust code looks similar to any C styled language, but there are some interesting, distinct points to note.

At line 33 shown below

live_neighbours += grid[new_x as usize][new_y as usize]

We need to cast the type of the variables new_x and new_y to usize. Suppose if the variable used to index an element of a vector is an integer, then we might get into overflow conditions like using negative numbers. The Rust compiler gives us an error if we index a vector with any other types except unsigned types.

Suppose we want to access the variables of unsigned type with signed type in calculations, then we need to cast the variables to one common type. Like at lines 28 and 29 shown below

let new_x = (i as i8) + x;
let new_y = (j as i8) + y;

We need to cast the type of the variables i and j to i8 because the variables new_x, new_y, x, and y are of type i8 whereas i and j are of type usize because the variables n and m are of type usize. Also, if our code leads to some negative values of the variable of type usize, the compiler will panic, stopping the execution.

If we want our variables to be mutable, we must make sure to tell that to the compiler by using the keyword mut. As shown in lines 11 and 65.

let mut future: Vec<Vec<i8>> = vec![vec![0; n]; m];
let mut grid: Vec<Vec<i8>> = vec![vec![0; cols]; rows];

Conclusion

I had a fun time implementing Game of Life in Rust. The development time of the program took a bit of time because the Rust compiler kept on complaining, but the execution was smooth. Whereas for other languages, we write the program, and we might run into errors at runtime, then come again to debug the code.

The Rust compiler also gives us suggestions for the errors and warnings which beat compilers of other programming languages. Often I was in doubt while checking the output because the program(in Rust) gave the output that is desired in the very first trial. This shows the power of the Rust compiler; once the code compiles then there is a high chance that the program might work.

The observations we saw coincides with the safety that Rust promises. This is just the tip of the iceberg, Rust also provides a lot of other features like borrowers, concurrency, and so on. The future of Rust while looking at the current state is bright, but will it stand the test of time; only time will tell the tale.