python on Kai Striega

Pointer Chasing

Sun, 26 Jul 2026 11:20:00 +1000

Everyone who writes Python for a living has been handed the same rule: don’t use a list, use an array. It’s a good rule. I’ve given it as advice myself, probably to someone who deserved a better explanation than the one I gave.

Here is the rule being followed, on two million integers:

sum(values) # a plain list 10.0 ms
sum(values) # array('q') 19.2 ms

Swapping the list for a compact array of machine integers made it twice as slow. Nothing was measured wrongly. That is what the machine does.

False Sharing

Sat, 25 Jul 2026 14:01:54 +1000

Part one of this series had one central fact and one piece of advice. The fact was that memory moves in 64 byte cache lines, so the cost of a loop is the number of lines it touches. The advice that fell out of it was to pack your data tightly, because packing more useful bytes into each line means fetching fewer lines.

This post is about a case where packing tightly is the entire bug, and the fix is to deliberately waste 56 bytes out of every 64.

Array of Structs vs Struct of Arrays

Sat, 25 Jul 2026 08:50:30 +1000

I’ve been putting together a talk about the things I don’t worry about, because NumPy does them for me: the performance patterns I kept running into over seven years of reviewing NumPy code written by people far smarter than me. What an array actually is. When reshape quietly copies six gigabytes. What broadcasting promises not to allocate. I did a practice run of it at SydPy recently.

The NumPy-specific parts landed fine. Then I got to a slide which says that a copy isn’t slow because the CPU is busy, it’s slow because the bytes have to physically move; that main memory will only hand them over at something like 20 GB/s; and that while that’s happening your cache is filling up with data you will never look at again.

Curiously Related Words Preprocessing Our Data

Sat, 07 Dec 2024 15:32:41 +1100

Previously I’ve made up the concept of a curiously connected word and a high level plan for finding such words. This post outlines the interesting parts of how I parse EtymDB. For those who are interested in all the code, it is available on my GitHub.

The data we have, and why that’s not enough#

As outlined previously we have two sources of data:

EtymDB a database of words and their etymological relationships
gensim a library of Word2vec models that model the semantic relationship between words

Our goal is to combine these two datasets into something nerdy. But just having data isn’t enough. We need to be able to retrieve, analyse and work with our datasets efficiently. Furthermore, our data isn’t really tabular. What we have are words, with some associated properties, and relationships between them. When you hear “relationships” you may be tempted to think of a relational database. While these are often the right choice, our data is a graph which can be difficult to work with in relational databases ¹. Neo4j provides a database that is specialised on graphs. This seems like the right tool for the job. Plus I want to try a new tool².

Processes, Threads, Oh My!

Sun, 27 Oct 2024 13:51:52 +1100

TLDR#

Processes and threads are an integral part of programming
They are an essential tool in any developer’s toolbox
Processes is how the OS represents a running program.
Threads are how the computer groups together instructions from your program and executes them
You can have multiple processes and threads
At least one thread runs inside each process
Tradeoffs of processes vs threads are:
- Processes are slower to create than threads
- Processes own their memory, threads share memory between them
- It is easy to make very difficult to debug errors with threads

Introduction#

I have a friend who is currently trying to transition into software engineering. She is currently completing her masters in IT. While nerding out together about tech, I mentioned multiprocessing. She said she’d never heard of it. That’s not great, so I tried to explain it, but feel that I didn’t do a great job of it. This blog post will be my attempt to clarify some of the essential concepts that a developer should know about processes and threads, focusing on how they work in Linux. I’ll do this in a couple of parts: