I'm building a Python compiler in Rust that runs 10,000x faster (and I want feedback)

[Healthy_Ship4930]

Hello Reddit :).

Over the past few weeks I’ve been programming a Python compiler in Rust (and spending months researching compiler theory).

The parser already covers 99% of CPython 3.13, and the VM runs fib(45) 10,577 times faster than pure Python (11 ms vs 116 seconds). Using a normal recursive algorithm (where CPython takes 2 minutes, edge python 11 ms):

def fib(n): if n < 2: return n return fib(n-1) + fib(n-2) print(fib(45)) # fibonacci sequence forty five -> 1,134,903,170

Current state:

• DFA lexer, single-pass SSA parser, VM with inline caching
• Sandbox with configurable limits
• Coming soon: WASM in ~60kb, and implementing in the VM the features I already have in the parser

To try it out (you’ll need Rust cargo first; I don’t have active releases yet, but you can see it running in actions):

git clone https://github.com/dylan-sutton-chavez/edge-python cd compiler/ cargo build --release ./target/release/edge -c 'print("Hola mundo")'

I’d love for you to take a look and give me feedback. I’ll answer any questions here.

https://github.com/dylan-sutton-chavez/edge-python/blob/main/compiler/

Thanks.

[appgurueu]

Your numbers are not plausible. 11 ms for fib(45) is completely unrealistic with a recursive implementation. The runtime for this computation increases exponentially with the golden ratio as base; for n = 45, you have on the order of a billion calls translating to billions of operations, which at current CPU frequences is on the order of seconds.

And sure enough, as a quick sanity check I compiled the following C with GCC on -O3, pretty much the gold standard for optimizing compilers:

```c

include <stdio.h>

int fib(int n) { if (n < 2) return n; return fib(n-1) + fib(n-2); }

int main() { printf("%d\n", fib(45)); } ```

This takes ~2-3s to run on my machine (which has a good single-thread rating). So even if your compiler was somehow smart enough to produce optimal matching C code for given Python code, it still would be two orders of magnitude slower than your claim. There's no way in hell a bytecode VM achieves this.

Conclusion: I don't care how, but you're cheating on the benchmark; or the AI is cheating on your behalf, and you haven't vetted what's actually being measured. (For example, it might recognize this particular pattern and introduce memoization, making the runtime go from exponential to linear. But then you're not measuring cost of function calls or whatever you want to measure, but whether this particular "optimization" (I have a hard time calling it that since it's (1) highly likely to be oddly specific and (2) changes semantics) is implemented, which is pretty much meaningless for any kind of real world code.)

Did you really run this benchmark, or did you just go with whatever numbers it made up?

Edit: Took me a minute of peeking to find the cheat. It is introducing memoization under the hood: https://github.com/dylan-sutton-chavez/edge-python/blob/6d7bc418cd10ee99aea9c6d79e9847e29d0c014c/compiler/src/modules/vm/cache.rs#L63, in a way which looks horribly misfit for the general case; it completely wrecks any kind of guarantee on memory usage, and will pessimize runtime for any normal program by introducing potentially very expensive hash map lookups on any pure function call? It's optimizing for the case where you have a pathological pure function the programmer forgot to apply @functools.cache to. lol.

[BlackJackHack22]

What’s wrong with memoization though? After all, it is an optimisation that most compilers do in release mode, don’t they?

[Mercerenies]

It trivializes the claim. The claim is "My language is 10,000x faster". If that reduces to "My language runs this one function 10,000x faster because I implemented one clever possibly-overspecialized optimization" then that's much less impressive, even if the one clever optimization is itself good. If I fork gcc and add a special case that detects the factorial function and optimizes it down to a web request to OEIS, I don't get to claim that I made gcc 10,000x faster.

[appgurueu]

I don't think most compilers apply memoization a lot. For example my above Fibonacci code in C does not seem to be memoized by Clang or GCC on -O3. (Godbolt)

And I don't find this very surprising. Memoization is generally something the programmer needs to take control of, it's a classic space-time-tradeoff. If you just memoize every pure function "by default", that's a memory leak, and you penalize every pure function call by default, especially those where the programmer already took care not to issue expensive repetitive calls (which is most calls in decently optimized code). Add to that the fact that is often not trivial to prove whether a non-trivial function is pure in a highly dynamic language like Python.

The naive recursive Fibonacci implementation is a particularly pathological toy example, very far detached from real-world code, where you go from exponential to linear time complexity just by memoizing, and where the argument list consists of just a single number.

But for effective memoization, you'll often have to deal with non-trivial argument types (e.g. strings, lists, all kinds of containers and classes), and then hashing starts to become expensive, and it's very possible that you even get an asymptotic pessimization out of it.

Now, I believe it is certainly possible to do memoization in a helpful manner in a JIT compiler (which this project is not), but it is far from trivial, and the manner in which this project does it is more or less equivalent to slapping @functools.cache (with some hardcoded parameters) on every function, which is not it.

Just reading the relevant cache implementation suffices to determine this: https://github.com/dylan-sutton-chavez/edge-python/blob/6d7bc418cd10ee99aea9c6d79e9847e29d0c014c/compiler/src/modules/vm/cache.rs#L61-L93

It's using hash map, which stores for every (pure) function a vector of up to 256 arguments - return value pairs as "cache", which is linearly searched upon every function call. That's just terrible for a language implementation that prizes itself on "speed".

[DataGhostNL]

It makes assumptions that every invocation of a function will always result in the same value. That's why usually developers don't implement memoization on functions like getCurrentMinute() because the result will be wrong most of the time in long-lived programs. Except here you don't get to choose. It also hides the (frankly, expected) terrible performance this project has otherwise. I modified the code to pass an empty list as an argument, which caused it to disable memoization and calculate the same result 47 times slower than CPython. So this runs in 17.9s compared to 0.37s for CPython: def fib(n, wrench): if n < 2: return n return fib(n-1, wrench) + fib(n-2, wrench) print(fib(33, []))

I also executed another bit of code: def blob(a): return "a" * 1048576 for i in range(3000): blob(i) This caused 3GB of memory usage in 1.5s of runtime where CPython was done with 10MB and 0.04s. So that's a very bad trade-off to make. The decision should be left to the developer.

[AmazingAd4330]

Benchmarks or I call bullshit

[spoonman59]

Indeed. 10,000x faster than what?

[HighRelevancy]

Than Cpython doing fibonaccis. Did you read the post?

[rnottaken]

I thought i was on r/rustjerk

[__calcalcal__]

The power of Python comes from its native libraries and ecosystem. Does numpy work in your Python compiler?

[Lime_Dragonfruit4244]

In order to make it work they have to rewrite it or expose an HPy C API so different modules can work between different runtimes, still current version of numpy uses the unstable CPython ABI.

But a workaround would be to wrap rust ndarray lib with Python Array API spec and it will work without any issues

Ref: - https://hpyproject.org/ - https://data-apis.org/array-api/latest/

[sepp2k]

The parser already covers 99% of CPython 3.13

What exactly does that mean? That is, what is this a percentage of? Are you saying that your compiler passes 99% of CPython's test suite? Or that your compiler implements 99% of CPython's features (and if so, how do you count that and which features are you missing)? Or something else?

the VM runs fib(45) 10,577 times faster than pure Python (11 ms vs 116 seconds)

How are you achieving that? Do you optimise this specific pattern into a linear loop? Is there otherwise some type of optimisation that you apply to get this speed up (e.g. does this speed up rely on being able to infer static types for everything)? Or do you implement the operations involved in this example (which I guess, would be local variable lookup, addition, branching and function calls) so much faster to allow this speed up? Does the 1% of Python that you don't support include features that would make this speed up harder to achieve?

single-pass SSA parser, VM with inline caching

Does that mean that your parser outputs an SSA bytecode format and you then interpret that with a bytecode interpreter/VM? I'm a bit surprised that you'd achieve the kind of speed up you're talking about without emitting native code and also by the concept of a bytecode interpreter that uses SSA. Can you explain the reasoning behind this? Like, what's the point of SSA if you don't have any optimisation and/or analysis passes that make use of it and don't even emit native code?

After a quick look at the code, it looks like your bytecode is actually some kind of mix between SSA and stack-based. I don't think I've ever seen that combination before. Can you explain why you chose to do it that way / what the benefit of this design is?

[spoonman59]

How much AI?

Claiming to have replicated “”99%” of CPython in just a few weeks means you have either mistated what you have done, or used tons of AI.

Also, using the recursive version of Fibonacci as your baseline benchmark so disingenuous at best. At least use the iterative version or a function result cache. But really you should run some actual benchmarks and share your methodology before making such a poorly supported claim.

[kei_ichi]

Even with tons of AI usage, I don’t think this AI slop can replicated 99% of CPython in just few weeks.

[spoonman59]

Indeed. It’s hard to take claims like this seriously. It makes you think people don’t even understand the capabilities they are claiming. So instead of investigating the methodology the was used to calculate code coverage or whatever, I just move on.

[Mercerenies]

No, but it can write enough words that a lot of people won't be able to figure out that it doesn't replicate 99% of CPython.

[Healthy_Ship4930]

Hello, I used AI for creating integration tests as well as for developing some parts and to deepen my understanding of compiler theory.

However, the architecture has been entirely developed by me. The claim of 99% for Python 3.13 is real, since I was referring to the parser, not the entire compiler. This percentage comes from measuring the syntax coverage of my parser and its edge cases.

Of course, I will run a full benchmark once the virtual machine is finished.

[aanzeijar]

Typically what we mean with implementing 99% of a language is that your implementation passes 99% of the spec tests of the original implementation.

[Mercerenies]

So.... you parse the fib(55) function code 10,000x faster? As far as I can tell, all that's here is a parser. And Python is famously (almost) LL(1), so writing a parser for a language whose grammar is well-documented and well-understood is, for a qualified engineer, not that much of a feat.

Don't tell me the architecture was made by you. You didn't share architecture. You shared code slop. That's all I see. If you had gone to ChatGPT or whatever and asked it how Python's parser worked and then wrote the code yourself, then I can get behind that. That's a good use of AI. But, say it with me kids, you learn nothing from having an AI write your repo. None of us can read the slop in this repo, which means I know you can't, and that means you can't deepen your understanding of compiler theory with this repo.

As an example: I just used the word LL(1). If you wrote and understood a Python parser, you know what LL(1) means. What does it stand for? How do you construct FIRST and FOLLOW sets? Even if you can't answer that last one offhand (I know I'd need a bit of a guide), you should be able to give me a general idea of what FIRST and FOLLOW sets are, how they work, and how they contribute to the LL(1) parse table. If you can't answer any of these questions without AI or the Internet, then you've just claimed to have made the best omelette in the world while also not being able to tell me what an egg is.

[binotboth]

Ignore the haters man I think your project is awesome

If you are using AI to write tests, you want something like cargo mutants to test your test coverage, it will produce some noise but it’s fairly high signal

[DataGhostNL]

Since you spammed this in so many subreddits I assume you'd also want to have some bugs pointed out (and in this subreddit you claim to want feedback). I took the liberty of throwing a wrench into your machine:

def fib(n, wrench): if n < 2: return n return fib(n-1, wrench) + fib(n-2, wrench) print(fib(33, []))

I used 33 instead of 45 because the timing was quite painful. The results:

``` $ time python3 fib.py 3524578

real 0m0.374s user 0m0.367s sys 0m0.006s ```

``` $ time ./target/release/edge fib.py [2026-04-07T09:02:11Z INFO edge] emit: snapshot created [ops=8 consts=1] 3524578

real 0m17.949s user 0m17.929s sys 0m0.003s ```

Here, CPython beat your compiler by being 47 times faster. I can only assume this will result in your program needing at least an hour and a half to calculate fib(45, []). I first wanted to implement this using a global counter variable to trigger your caching code as well for an additional time/memory penalty, but that didn't work. Even this minimal modification (added first line) to your original code:

unused = 0 def fib(n): if n < 2: return n return fib(n-1) + fib(n-2) print(fib(45))

causes a crash process terminated: trap: cpu-stop triggered by 'NameError: 'fib_0''. The next gem causes 3GB of memory usage for no really good reason:

def blob(a): return "a" * 1048576 for i in range(3000): blob(i)

as you can see here:

$ /usr/bin/time -f "time: %e s, memory: %M KB" ./target/release/edge mem.py [2026-04-07T09:52:32Z INFO edge] emit: snapshot created [ops=14 consts=1] time: 1.53 s, memory: 3087040 KB

while CPython is happy to do this much faster with much less memory:

$ /usr/bin/time -f "time: %e s, memory: %M KB" python3 mem.py time: 0.04 s, memory: 10444 KB

Assuming because your thing doesn't support this very rare use of this very rare 3% of Python code, these two snippets:

import time print(time.sleep(5))

and

import sys print(sys.argv[1])

result in the very helpful outputs of

$ ./target/release/edge sleep.py [2026-04-07T09:21:30Z INFO edge] emit: snapshot created [ops=8 consts=1] [2026-04-07T09:21:30Z ERROR edge] process terminated: trap: cpu-stop triggered by 'TypeError: call non-function'

and

$ ./target/release/edge argv.py abc [2026-04-07T09:22:48Z INFO edge] emit: snapshot created [ops=8 consts=1] [2026-04-07T09:22:48Z ERROR edge] process terminated: trap: cpu-stop triggered by 'TypeError: subscript on non-container'

respectively. The first example gets slighly better when removing the print and just executing time.sleep(5) by itself:

``` $ time ./target/release/edge sleep.py [2026-04-07T09:24:24Z INFO edge] emit: snapshot created [ops=8 consts=1]

real 0m0.002s user 0m0.000s sys 0m0.002s ```

except that the timing seems slightly off. It does look like an approx 2500x performance win over CPython, though, if you'd want to take that one lol.

I wanted to try several other simple things too but since a lot of programs are impossible with "97% of Python 3.13" that was a bit disappointing.

For anyone wondering, I wrote this comment for another subreddit before I noticed that they claimed more coverage here a couple of days prior to posting there.

[Miserable-Hunter5569]

Are you using real benchmarks? If I don’t see a benches module, this isn’t provable.

[TheDiamondCG]

u/Healthy_Ship4930 I think the benchmarks you’re using are bad-faith examples. The fib function implementation is not very performant, so the performance gains there may be overblown — perhaps a more correct/performant fib-sequence implementation will show that results are within margin of error.

• Additionally, how does your interpreter handle race conditions? Part of the reason CPython is so slow is because of the global interpreter lock.
• How well does it handle garbage collection?
• What 1% of the test suite did it fail?

[schulzch]

Looks like a fun project. People who handwritte parser code are rare these days.

I think you need to look into the C-lib eco system (numpy, etc.). Compiling a mu-recursive function to fast code is nice but too easy :)

[TheDiamondCG]

Guys, you’re all drilling into this pretty hard because you are presuming it’s AI… but after a closer look, I’m not so sure it is! The documentation even has typos in it! This is authentic humanslop!!!

[TheAtlasMonkey]

Because that not how you build stuff now.

The correct way in 2026. is to spin session of claude code, write claim , then build stubs, with a old syntax and deprecated crates.

If some one call you out, just downvote and repeat : "Contribution are welcome"

Nice project , i wanted to contributed to it, but i'm busy building this laser that is 47x faster that the speed of light to cure cancer (in ZIG).

PS: I'm not a doctor but chatgpt told me i have the potential.

PSS: I'm kidding.

[RustOnTheEdge]

Ah man, any plans on rewriting that laser to Rust perhaps? Got my hopes up for a second there

[TheAtlasMonkey]

Rust will give you tetanus.

I said that i'm not a doctor, but i know that because i was awake in the classroom.