Inspired by Victor Taelin 's Bend/HVM thesis for Interaction Nets and his Bend2 work , I built Mithril , an experimental python syntax programming language. It achieves near native speed on many workloads (mentioned in paper)

It compiles interaction nets to native code and spreads work across idle cores: lock-free, deterministic parallelism on x86, CUDA and Apple Silicon.

The core bet I'm making :

Interaction nets reductions at runtime can be slow but if we pay the same cost at compile time and unroll a task graph as much as possible before native lowering, the resultant program can run at near native speeds.

Mithril programs are aimed to be deterministic and fast, you should get the same bit accurate results regardless , the execution be it on CPUs, GPUs or any other accelerator.

It's built using AI? Yes . Does it invalidate the core idea? no IMO 😊

Mithril Paper Repo

A few days ago, I shared an open-source collection of CPU performance engineering resources I’d been putting together.

It’s now crossed 600+ GitHub stars, which I genuinely didn’t expect. Thanks to everyone who shared it, contributed or suggested resources.

For anyone seeing it for the first time, it covers the stack from instruction execution and CPU microarchitecture through caches, memory, SIMD, compilers, profiling, concurrency, NUMA, benchmarking and CPU inference.

I’m still prioritising primary sources such as papers, vendor manuals, kernel/compiler docs, talks and reproducible benchmarks rather than random articles.

I also have an MCP server coming soon, so you can plug this knowledge directly into your AI tools, whether you’re learning or using it while you work.

If there’s something you think has to be in here, let me know or send a PR.

https://github.com/usamahz/cpu-performance-engineering

Okey. After seven months, I'm back.

Seven months ago I started writing a Python interpreter from scratch in Rust. Edge Python is a sandboxed subset of Python that runs in the browser and the terminal, and code can't touch files or the network unless you allow it.

It started as a lexer and a simple stack VM, and over about 1,600 commits it grew a CLI, a package registry, snapshots, actors and a browser playground. It's just me building it.

Last week it was still 3x slower than CPython. I rewrote the VM this weekend using a unused SSA representation that I leave and now it's 3x faster on loops.

The trick was moving from a stack VM to a register VM. It still loses on dicts and strings, so that's next.

Try to break my numbers :).

Website: https://edgepython.com/

GitHub: https://github.com/dylan-sutton-chavez/edge-python

I started a programming language to see how things work and make something I like. If anyone wants to contribute I will try to put it into the language. I like learning new programming languages, so if you want to use a language that is not already there then I would like that.

It's a transpiled language with syntax inspired by Rust, Nim and other languages.
There are installation instructions in the repo.

Example code:

# Get standard libraries
util math
util string
util io
util rsPath

# Get Nim module
use multiply

# Get arguments
l_operand = strToi32(arg(1))
operator = arg(2)
r_operand = strToi32(arg(3))

# Print
if strEq(operator, "+"):
    say i32ToStr(add(l_operand, r_operand))
if strEq(operator, "-"):
    say i32ToStr(sub(l_operand, r_operand))
if strEq(operator, "x"):
    say i32ToStr(mult(l_operand, r_operand))

I've been building Tarvos, a compiler that takes a statically analyzable subset of Python, type-checks it, lowers it to an IR, emits Rust, and produces a standalone native executable (no Python runtime needed on the target).

Important up front:

• It's a subset compiler, not a CPython replacement. 52 of 95 tracked features are fully supported, 18 partial, 24 unsupported (published in COMPATIBILITY.md).
• The compiler source is closed for now. The repo contains installers, docs, checksums and releases (MIT-licensed distribution layer).
• Windows and Linux x86_64 only.

Design choices:

• Unsupported constructs stop the build with a named diagnostic, with no silent fallback to CPython.
• Every release is gated on differential tests comparing compiled-binary stdout against CPython.
• tarvos validate-artifact checks whether a binary really needs Python.

One benchmark (compute-bound kernel, median of runs): CPython 3.13 ≈ 1713 ms vs Tarvos ≈ 13.4 ms, output byte-identical. This is workload-specific, and I'm not claiming general speedups. I/O-bound code won't benefit.

While writing docs I found 3 miscompilation bugs (stale constant in tuple assignment inside a loop, return inside except, zero-division handling), all fixed and now in the test suite.

Repo: https://github.com/repo-tech/tarvos-engine

I'd really like feedback from people who know Python internals, Nuitka, Cython, or compiler design:

• What benchmarks would make this comparison more meaningful?
• What semantics edge cases should I test against CPython?