Ali's Blog

How to Practice CUDA Locally Without an NVIDIA GPU

2026-07-14T00:00:00+00:00

If you're learning CUDA without access to an NVIDIA GPU, you're no longer blocked. Compiler Explorer can compile and even execute CUDA programs on remote hardware. Just head over to godbolt.org, choose a CUDA compiler, and you're ready to experiment.

This post, however, aims to set up a local CLI development environment. With it, you'll be able to code in the comfort of your favorite terminal and editor. ⊕ The only catch is that there's a few milliseconds of delay between when you run the command and get your outputs, due to the network latency.

This setup is good for practicing CUDA syntax, checking that kernels and memory management compile correctly, and confirming small programs behave as expected, all without installing the CUDA toolkit or owning NVIDIA hardware. It's not a good fit for serious performance benchmarking, since you're sharing remote hardware and timing won't be reliable, or for large, stateful projects, since each run starts fresh.

To set this up locally, we'll use a small CLI that talks to Compiler Explorer and, if needed, a tool to flatten Since Compiler Explorer receives a single source file, projects that rely on local headers need to be flattened first. multi-file projects into a single source file. I picked cexpl and quom, respectively

Set up a virtual environment and install cexpl. If your project spans multiple files, install quom as well.

$ python -m venv venv
$ source venv/bin/activate   # on Windows: venv\Scripts\activate
$ pip install cexpl quom

Next, write your CUDA code in a file, say main.cu.

#include <cstdio>
#include <cuda_runtime.h>

__global__ void hello() {
    printf("Hello from thread %d\n", threadIdx.x);
}

int main() {
    hello<<<1, 8>>>();
    cudaDeviceSynchronize();
    return 0;
}

⊕ This kernel just prints a message from 8 GPU threads. Also, in practice you should check the return value of cudaDeviceSynchronize.

If your code includes local header files, make a combined file using quom.
$ quom main.cu combined.cu

Finally, compile and run it remotely with

$ cexpl --exec --skip-asm --lang cuda main.cu

⊕ --exec runs the compiled program, not just compile it; --skip-asm hides the generated assembly output, so you only see program results; --lang cuda tells Compiler Explorer to treat the file as CUDA code.

After a short delay, you should see something like:

STDOUT:
Hello from thread 0
Hello from thread 1
Hello from thread 2
Hello from thread 3
Hello from thread 4
Hello from thread 5
Hello from thread 6
Hello from thread 7

That output was produced by an NVIDIA GPU running on Compiler Explorer's servers.

Keep in mind that the execution happens in a fresh environment every run.

--exec can sometimes crash instead of showing errors. If your code has a compilation error, cexpl --exec should normally print the compiler errors to stderr and stop there, but depending on your system or network, it sometimes crashes outright instead of showing you anything useful. If that happens, just drop --exec and run:
$ cexpl --skip-asm --lang cuda main.cu
This only compiles the code and prints the compiler output, including any errors, without trying to execute it. Once your code compiles cleanly, add --exec back to actually run it.

That's all there is to it. With that, you can practice and learn CUDA a bit more easily.

Build MPICH from source

2026-07-03T00:00:00+00:00

MPICH The CH part of the name was derived from "Chameleon", which was a portable parallel programming library developed by William Gropp, one of the founders of MPICH. (wikipedia) is one of the most widely used MPI implementations. Package managers often ship an old version, or one built without the options you need, so you might want to build it from source to meet the requirements of your project. This guide covers that as well as setting up your shell so MPICH doesn't clash with other MPI installs like OpenMPI.

The steps should be pretty much the same on Linux, macOS, and BSD. I'll call out the differences where they matter.

Prerequisites

You need a C compiler and make.

Linux: install the usual toolchain, e.g. build-essential (Debian/Ubuntu).
macOS: run xcode-select --install to get clang and make I'm not entirely sure, but I think xcode cli tools provide GNU make, so you should be fine.. Note cc is clang here, not GCC.
BSD: base make is BSD make, not GNU make, which MPICH's build needs. Install GNU make (usually the gmake package) and use gmake instead of make below.

Download and extract

Grab the latest release tarball from the MPICH downloads page, then extract it: ⊕ You could also verify the checksum/signature provided on the downloads index page.

$ curl -LO https://www.mpich.org/static/downloads/4.2.3/mpich-4.2.3.tar.gz
$ tar -xzf mpich-4.2.3.tar.gz # Don't worry, it's not a tarbomb
$ cd mpich-4.2.3

⊕ 💣

Configure

$ ./configure

By default this installs to /usr/local. To keep MPICH separate from other MPI implementations, you could set a custom prefix: ⊕ Prefix is the base directory that everything gets installed into.

$ ./configure --prefix=/opt/mpich

⊕ The rest of this guide uses /opt/mpich as prefix.

You could add any other flags here. You could run ./configure --help to get a full list of all possible flags. Here are some useful ones:

--enable-strict=all or slightly less pedantic --enable-strict=most
--disable-cxx / --disable-fortran: skip C++ or Fortran bindings if you don't need them.
For debug build:
- --enable-g=most, which enables debugging, along with static analyzers, etc.
- --enable-fast=O0. Even with the above debug flag being set, MPICH still uses the second level optimisation, i.e., -O2, in compilation. with this we disable any kind of optimisation.
For optimisation build:
- --enable-g=none,
- --enable-fast=all,O3, which drops debug instrumentation for a production build.
CC=, CXX=, FC=: pick a specific compiler, e.g. CC=gcc-13 ./configure ....

Run ./configure --help for the full list of options and their description. Additionally, read this document in the MPICH repo located at :/doc/wiki/source_code/Building_MPICH_For_Development.md

I usually install the debug and optimisation build in two separate directories of /opt/mpich/{debug,opt}. Then, I use shell functions to set the necessary environment variables to switch to each installation on demand. Something similar to the following:
mpich_debug() {
    export PATH="/opt/mpich/debug/bin:$PATH"
}

mpich_opt() {
    export PATH="/opt/mpich/opt/bin:$PATH"
}

Build

$ make 2>&1 | tee log.make

⊕ Use gmake instead of make on BSD.

Speed things up with make -j$(nproc) on Linux or make -j$(sysctl -n hw.ncpu) on macOS/BSD.

Install

$ sudo make install | tee log.install

⊕ You don't need to use sudo if the current user owns the prefix directory.

You could skip sudo entirely, by giving the user ownership over the prefix directory: sudo mkdir -p /opt/mpich && sudo chown $USER /opt/mpich; then you would re-run make install without sudo.

Verify

$ /opt/mpich/bin/mpichversion
MPICH Version:      5.0.1
MPICH Release date: Fri Apr 10 09:45:31 AM CDT 2026
MPICH ABI:          18:1:6
MPICH Device:       ch4:ofi
MPICH configure:    --prefix=/opt/mpich
MPICH CC:           gcc   -fno-common   -O2
MPICH CXX:          g++   -O2
MPICH F77:          gfortran   -O2
MPICH FC:           gfortran   -O2
MPICH features:     threadcomm

$ /opt/mpich/bin/mpicc -show
gcc -I/opt/mpich/include -L/opt/mpich/lib -lmpi -lpmpi

If both run cleanly, the install is good.

Add it to your shell

The binaries aren't on your PATH yet: ⊕ make install only copies stuff to the prefix directory; it does not tell the OS or the compilers where they could find MPICH binaries and libraries. We need to update certain shell environment variables so that the correct compiler is selected for execution and the correct library for linking.

$ export PATH="/opt/mpich/bin:$PATH"

Putting it first ensures mpicc/mpirun resolve to this build, not another MPI implementation.

Why not just add this to our shell config?

If you switch between MPI implementations often or use mostly an implementation other than MPICH, permanently prepending MPICH to PATH means it silently wins every time, which can cause mismatches between the library your code was built against and the one mpirun launches with.

Instead, treat it like a Python virtual environment: activate it only when needed. Create /opt/mpich/activate.sh:

 1MPICH_OLD_PATH="$PATH"
 2export PATH="/opt/mpich/bin:$PATH"
 3
 4if [ -n "$ZSH_VERSION" ]; then
 5    MPICH_OLD_PROMPT="$PROMPT"
 6    export PROMPT="(mpich) $PROMPT"
 7else
 8    MPICH_OLD_PROMPT="$PS1"
 9    export PS1="(mpich) $PS1"
10fi
11
12deactivate_mpich() {
13    export PATH="$MPICH_OLD_PATH"
14
15    if [ -n "$ZSH_VERSION" ]; then
16        export PROMPT="$MPICH_OLD_PROMPT"
17    else
18        export PS1="$MPICH_OLD_PROMPT"
19    fi
20
21    unset MPICH_OLD_PATH
22    unset MPICH_OLD_PROMPT
23    unset -f deactivate_mpich
24}

⊕ zsh uses PROMPT, bash uses PS1; the script checks $ZSH_VERSION to set the right one. You could adapt it if you use fish or any other non-POSIX shells.

Activate it in any shell session with:

$ source /opt/mpich/activate.sh
(mpich) $ type -a mpicc
mpicc is /opt/mpich/bin/mpicc
mpicc is /opt/homebrew/bin/mpicc
(mpich) $ deactivate_mpich
$ type -a mpicc
mpicc is /opt/homebrew/bin/mpicc

⊕ If that's too much typing, you could add an alias to your config, like mpich5. ⊕ deactivate_mpich restores PATH and the prompt to how they were before.

Delete All GitHub Actions Workflow Runs Using GitHub CLI

2026-06-26T00:00:00+00:00

TLDR: Here's the one-liner if you're here to just copy it.
$ gh run list --all --limit 40 --json databaseId | jq '.[].databaseId' | xargs -n1 gh run delete
Change the limit, 40, to the actual number of actions present in your repository.

If you've ever accumulated hundreds (or thousands) of GitHub Actions workflow runs, you've probably wondered how to clean them all up.

To my knowledge, GitHub's web interface provides no interface for this purpose. Unfortunately, there isn't also an obvious builtin GitHub CLI command, like gh run delete --all, that deletes every workflow run in a repository. At best, the gh run delete <run-id> only deletes one workflow run as this command only accepts one argument (or none for an interactive selection before deletion).

If we could find a way to get a list of all runs, we then could wind up a for loop or pipe it to xargs to have them deleted programmatically. For that, the following command

$ gh run list

lists workflow runs in your repository. By default, it only returns 20 workflow runs. We can pass an extra --limit <int> flag to tell it list more. ⊕ You can check how many workflow runs exist by visiting the Actions tab of your GitHub repository in your browser. Additionally, we have pass --all (or -a) to include disabled workflows.

$ gh run list --all --limit 100

Now, we need to extract the id's from the output, but the output format is in a human-readable/friendly way. In other words, there's no fixed format so that we could parse it with awk, for instance. Luckily, there's a --json flag that you can use to request only the fields/columns you need. To see the list of correct field names, run

$ gh run list --json

it will show use the various column names. Among them exists the databaseId, which is what we want. Issuing the following gives us a JSON output: a list of objects with only databaseId as key. ⊕ Simply add more --json pairs to get more columns of data.

$ gh run list --json databaseId
[
  {
    "databaseId": 1234567890
  },
  {
    "databaseId": 1234567891
  }
  ...
]

Now we need to turn that JSON into a plain list of IDs. The easiest tool to pipe the JSON output into jq. ⊕ . refers to the root JSON value; [] iterates over every element in the array; and .databaseId selects the databaseId property from each object.

$ gh run list --json databaseId | jq '.[].databaseId'
1234567890
1234567891
1234567892
...

Finally, we can go ahead and pipe the ids to xargs to get deleted one-by-one. ⊕ The -n1 option tells xargs to invoke gh run delete once for each input line.

$ gh run list --json databaseId | jq '.[].databaseId' | xargs -n1 gh run delete
✓ Request to delete workflow run submitted.
✓ Request to delete workflow run submitted.
✓ Request to delete workflow run submitted.
...

This is yet another example of how powerful Unix philosophy can be.

X86-64 Assembly on ARM64 Mac

2025-05-02T00:00:00+00:00

If you're looking for a way to code and execute x86-64 programs on ARM64 macs, this tutorial is for you. Through Rosetta 2, it is possible to compile and link C and x86-64 assembly programs into x86-64 binary and run it as if it were an ARM64 binary. It even translates AVX and AVX2 instruction, but not AVX512. Here, I'll demonstrate how to write assembly code and call it from a C code.

The entire process is really simple.

Write your assembly code in a .s file. Within it expose By exposing or marking it as global, I mean making it visible to the linker across translation units. a symbol that you later on want to call in a C file.

  .text
  .globl _my_func
_my_func:
   ...

In this particular example, we made the _my_func symbol visible to the linker.

Then, to compile the C code, before even linking it against the assembly code, we declare the corresponding function with leading underscore removed. ⊕ Note the exposed symbol _add_arrays, which matches a C function with name add_arrays. This convention is part of MacOS's x86-64 ABI. ⊕ Note also that you don't have to specify the extern keyword before the function prototype since functions in C have external linkage by default. However, for readability's sake, I like to keep it there to indicate the function is defined in an assembly file.

// ~~~

extern <return_type> my_func(<params>...);

// ~~~

int main(void)
{...}

Finally, we compile the whole thing by passing both C and assembly files to the compiler as well as the -target x86_64-apple-macos flag.

$ cc -target x86_64-apple-macos main.c my_func.s

C Compilers are able to do cross-compilation and produce binaries that target a specific architecture and ABI. In this case, by passing this flag, we essentially tell it to

assemble into x86-64 instructions

an in doing so use Mac's x86-64 ABI and Mach-o binary file format.

Example: Adding Integer Arrays with SIMD Operations

To make this a bit concrete, let's go through a simple example of adding two arrays using SSE instructions.

Here's the assembly code.

# file: add_simd.s

.text
.globl _add_arrays

# void add_arrays(
#     const int *a,   rdi
#     const int *b,   rsi
#     int *res,       rdx
#     int n           rcx
# )

_add_arrays:
    xorq %r8, %r8

.loop:
    cmpq %rcx, %r8
    jge .done

    # Load four integers from `a` (%rdi)
    movdqu (%rdi,%r8,4), %xmm0

    # Load four integers from `b` (%rsi)
    movdqu (%rsi,%r8,4), %xmm1

    # Add four integers in parallel
    paddd %xmm1, %xmm0

    # Store the result
    movdqu %xmm0, (%rdx,%r8,4)

    addq $4, %r8
    jmp .loop

.done:
    ret

Here, we're assuming n is a multiple of 4. Ideally, we would need to handle remaining elements if n weren't divisible by 4.

In the C code, we declare the add_arrays function at the top of the file.

// file: main.c

#include <stdio.h>
#include <stdint.h>

extern void add_arrays(const int *a, const int *b, int *res, int n);

int main(void)
{
    int a[] = {1, 2, 3, 4, 5, 6, 7, 8};
    int b[] = {10, 20, 30, 40, 50, 60, 70, 80};
    int res[8] = {0};

    add_arrays(a, b, res, 8);

    for (int i = 0; i < 8; i++) {
        printf("%d ", res[i]);
    }

    printf("\n");
}

Now, to compile and check the file format

$ clang -target x86_64-apple-macos main.c add_simd.s
$ file a.out
a.out: Mach-O 64-bit executable x86_64

Running it should gives us:

$ ./a.out
11 22 33 44 55 66 77 88

First Post

2025-03-08T00:00:00+00:00

Epigraphs

The first principle is that you must not fool yourself — and you are the easiest person to fool.

Richard Feynman

It is a capital mistake to theorize before one has data.

I have made this longer than usual because I have not had time to make it shorter.

Blaise Pascal , Lettres Provinciales

Quotes

Graphical excellence is the well-designed presentation of interesting data.

Edward Tufte , The Visual Display of Quantitative Information

This is exactly what Orwell had in mind when he wrote:

Never use a long word where a short one will do.

George Orwell , Politics and the English Language

And that principle applies equally to code.

Side notes and margin notes

This is the simd first post. You can use all your shortcodes here too.

Full-width

Normal code that does not overflow the text width.

int main(void)
{
  std::cout << "Hello, World\n";
}

Full width code that does overflow.

# a wide block that needs more horizontal space
result = some_very_long_function_name(argument_one, argument_two, argument_three)

Alert environments

This is a note with some additional context.

A helpful tip for the reader.

Something the reader really should not miss. This is the simd first post. side note in alert/quote.

A warning about potential pitfalls.

A strong caution about destructive or irreversible actions.

Math support

Various ways to write math $x$:

$$ x^2 \frac{1}{x} 12\,\rm{m}^2 $$

Inline math: $\frac{1}{2}$ $\frac34$

Display math:

\int_0^\infty e^{-x^2} dx = \frac{\sqrt{\pi}}{2} 12\,\rm{m}^2

...

x^2 \frac{1}{x} 12\,\rm{m}^2

...

\int_0^\infty...