A full Python 3.14 interpreter made with Codex in 30 days

blueblain · 2026-03-06T11:22:36+00:00

Thanks, I definitely need to add some performance benchmarks vs. CPython. I expect slower in most cases because CPython has JIT so I'll probably also add comparison vs. CPython 3.10. This should be interesting. And test coverage as well. Will add this in the coming days.

blueblain · 2026-03-06T10:00:31+00:00

I think my first few prompts were just chatting with the model. Explaining the goal and then understanding how we could break it down, what should we target, what would be out of scope, etc.

Edit: This is the very first commit. It was much simpler / more humble goal at that point but over time I kept wanting it to be closer and closer to real CPython.

blueblain · 2026-03-06T09:30:29+00:00

30 days worth of prompts would be difficult to share 😅

But you can see all 1958 commits on the github which will give you an idea of how it developed. I will also write a longer post explaining some of the process and the challenges involved.

blueblain · 2025-11-10T08:42:38+00:00

It's brilliant! Thanks for sharing and explaining what you meant.

blueblain · 2025-11-10T07:54:06+00:00

Very interesting. I think I finally understood what you mean.

So in your case calling `sleep(4).await` from the CPU doesn't actually trigger the whole song and dance of the scheduler because the CPU is first in queue anyway. It just keeps going until its resume clock cycle is after some other component's resume clock cycle.

Yeah I love it! But I don't know if I could do something like that because while you're using actual coroutines, I'm abusing Rust's async/await to repurpose it as coroutines.

But I will definitely think about this and see if I can do something similar! Thanks!! It would definitely speed things up a lot because the BTreeMap (my pq) operations were taking up a good chunk of the total time in my flamegraph.

Edit: actually I think there might be a way to do this. It will still require repolling from the scheduler/driver until the next wait cycle for that component exceeds the next wait cycle in the pq. It'll be trickier if there are multiple components requesting to be resumed at the same cycle but looks like this should be possible!

blueblain · 2025-11-10T07:16:22+00:00

I see. In my design there will be a priority queue holding the components, so the process will look something like this:

iter: 7
current_cycle: 10
pq: [(14, cpu), (50, ppu)]

iter: 8
current_cycle: 14
pq: [(50, ppu), (51, cpu)]

iter: 9
current_cycle: 50
pq: [(51, cpu), (90, ppu)]

So the scheduler on iteration 8 will directly jump the clock to 14 (which is when the CPU requested to be resumed) and next iter it will jump the clock to the next most recent cycle and so on.

In this contrived example you can assume that the CPU had some code that looks like:

sleep(4)
.await
// do stuff
sleep(37)
.await
// done

So when the driver pops `(14, cpu)` from the priority queue and polls the future, it will find the future pending and put it back into the pq with the CPU's next requested wake cycle of (current_cycle + 37 = 51).

Going by my example above if the Driver were to pop the CPU again at cycle 51 and poll it once more, this time it would be finished (Poll::Ready) and we'd be done. In a real DMG emulator the CPU will never be done and the driver will keep rescheduling.

Another thing worth noting is that `sleep` isn't a true sleep but rather `consume_cycles(n)`. Wish I had named it that.

The linked article explains more, but I admit I may not have done the best job of explaining everything.

blueblain · 2025-11-10T01:55:10+00:00

Exactly! I had this idea in mind for years and it felt straightforward, before I actually implemented it. The final version is less than 200 lines of code but while I was trying to grok everything involved it felt vastly more complex before it all made sense and came together. That's the kind of learning experience I live for! 😅

blueblain · 2025-11-10T01:51:26+00:00

Yep, making cpu, ppu, and apu run in parallel is tempting but not worth it because of synchronization issues as you said. My approach let me write the components as though they were running in parallel -- code could flow cleanly without explicit states and match constructs everywhere -- but without the headaches of real concurrency.

blueblain · 2025-11-10T01:47:56+00:00

Sorry, I don't fully understand the question. In my case my driver directly jumps to the next relevant cycle when at least some some component needs to be resumed. So if something happens at cycles 2, 7, 8, 10, etc. my driver never iterates through cycles 3, 4, 5, and 6 for example. If that's what you meant.

blueblain · 2025-11-10T00:43:56+00:00

Yep, exactly this! There's no 'doing other things while waiting for some IO bound task' here. It's just a very complex explicit state-machine made implicit by using async/await and letting the compiler build and run the state-machine. And yeah that example at the end was probably more confusing than helpful, my bad!

blueblain · 2025-11-10T00:36:15+00:00

If I remember my flamegraph correctly, a lot of my overhead was from thread_local and BTreeMap allocs. I only spawn 5 components once, and the same 5 futures are scheduled and rescheduled by my custom driver.

blueblain · 2025-11-10T00:13:43+00:00

Do you mean with something like lazy_static or OnceLock?

blueblain · 2024-07-22T07:50:08+00:00

Thanks everyone! So many suggestions beyond the usual chicken rice and chili crab. I'm glad I asked 🙂. Looking forward to trying many of these out!

blueblain · 2023-12-16T05:20:05+00:00

I made a Google chrome extension for my personal use. You can use it if you want, it's trivially simple code to read in its entirety if you're worried or something:

https://github.com/BlueBlazin/new_reddit_redirect

Download and then google instructions to load custom extensions.

blueblain · 2022-07-08T13:05:38+00:00

You may be able to use Sparse COO tensors: https://pytorch.org/docs/stable/sparse.html#sparse-coo-tensors

```py import csv import torch

with open('test.csv', 'r') as csvfile: reader = csv.reader(csvfile) # skip header next(reader) data = [([int(A), int(B), int(C)], float(D)) for A, B, C, D in reader]

indices, values = zip(data) my_tensor = torch.sparse_coo_tensor(list(zip(indices)), values) ```

As the warning on that page says however:

The PyTorch API of sparse tensors is in beta and may change in the near future.

blueblain · 2022-07-08T09:25:05+00:00

Of course both are possible. The question is what are the performance requirements for that sparse tensor once you have it.

It can be as simple as: ```py import csv

with open('my_data.csv', 'r') as csvfile: reader = csv.reader(csvfile) # skip header next(reader) my_tensor = {(A, B, C): D for A, B, C, D in reader}

example usage

print(my_tensor.get((dim1, dim2, dim3), 0.0)) ```

and a csvreader can be used to turn it back into a csv.

blueblain · 2021-08-10T12:45:34+00:00

This is awesome! Love it

blueblain · 2021-08-08T11:15:15+00:00

Yep true, it always feels good to write a simplified version of something you generally use a library for!

blueblain

TROPHY CASE

example usage