hwpythonner

I just had to give it a name. Didn't really search for vacancies. Maybe I need to rename :)

Thank you! And yes, exactly.

There have been efforts (like Cython, Nuitka, PyPy’s JIT) to accelerate Python by compiling subsets or tracing execution — but none fully replace the standard dynamic model at least as far as I know.

Thanks you very much. I learned of Jazelle after started working on it and this is a good thing, because Jazelle didn't become too popular AFAIK, so it would just make me quit. Glad I didn't though :)

You're absolutely right — today, PyXL only supports pure Python execution, so C extensions aren’t directly usable.

That said, in future designs, PyXL could work in tandem with a traditional CPU core (like ARM or RISC-V), where C libraries execute on the CPU side and interact with PyXL for control flow and Python-level logic.

There’s also a longer-term possibility of compiling C directly to PyXL’s instruction set by building an LLVM backend — allowing even tighter integration without a second CPU.

Right now the focus is on making native Python execution viable and efficient for real-time and embedded systems, but I definitely see broader hybrid models ahead.

GC is still a WIP, but the key idea is the system won't stall — garbage collection happens asynchronously, in the background, without interrupting PyXL execution.

Thank you!

The microcode or the ISA of the system actually runs on the co-processor (PyXL custom cpu)

If you refer to the ARM part as the host (did you?) it's just orchestrating the whole thing, it doesn't run the actual Python program

Oh boy, I definitely considered that — turning PyXL into a RISC-V extension was an early idea I thought of.

It could probably be adapted into one.

But I ultimately decided to build it as its own clean design because I wanted the flexibility to rethink the entire execution model for Python — not just adapt an existing register-based architecture.

FPGA is for prototyping. although this could probably be used as a soft core. But looking forward, ASIC is definitely the way to go.

You're close: It's currently running on an FPGA (Zynq-7000) — not ASIC yet — but yeah, could be transferable to ASIC (not cheap though :))

It's a custom stack-based hardware processor tailored for executing Python programs directly. Instead of traditional microcode, it uses a Python-specific instruction set (PySM) that hardware executes.

The toolchain compiles Python → CPython Bytecode → PySM Assembly → hardware binary.

Thanks for the question.

HDL: Verilog

Assembly: The processor executes a custom instruction set called PySM (Not very original name, I know :) ). It's inspired by CPython Bytecode — stack-based, dynamically typed — but streamlined to allow efficient hardware pipelining. Right now, I’m not sharing the full ISA publicly yet, but happy to describe the general structure: it includes instructions for stack manipulation, binary operations, comparisons, branching, function calling, and memory access.

Why not ARM/X86/etc... Existing CPUs are optimized for static, register-based compiled languages like C/C++. Python’s dynamic nature — stack-based execution, runtime type handling, dynamic dispatch — maps very poorly onto conventional CPUs, resulting in a lot of wasted work (interpreter overhead, dynamic typing penalties, reference counting, poor cache locality, etc.).

PyPy is a JIT compiler — it runs on a standard CPU and accelerates "hot" parts of a program after runtime analysis.

This is a great approach for many applications, but it doesn’t fit all use cases.

PyXL is a hardware solution — a custom processor designed specifically to run Python programs directly.

It's currently focused on embedded and real-time environments where JIT compilation isn't a viable option due to memory constraints, strict timing requirements, and the need for deterministic behavior.

Hi everyone, I built PyXL — a hardware processor that executes a custom assembly generated from Python programs, without using a traditional interpreter or virtual machine. It compiles Python -> CPython Bytecode -> Instruction set designed for direct hardware execution.

I’m sharing an early benchmark: a GPIO test where PyXL achieves a 480ns round-trip toggle — compared to 14-25 micro seconds on a MicroPython Pyboard - even though PyXL runs at a lower clock (100MHz vs. 168MHz).

The design is stack-based, fully pipelined, and preserves Python's dynamic typing without static type restrictions. I independently developed the full stack — toolchain (compiler, linker, codegen), and hardware — to validate the core idea. Full technical details will be presented at PyCon 2025.

Demo and explanation here: https://runpyxl.com/gpio Happy to answer any questions

I built a hardware processor that runs Python programs directly, without a traditional VM or interpreter. Early benchmark: GPIO round-trip in 480ns — 30x faster than MicroPython on a Pyboard (at a lower clock). Demo: https://runpyxl.com/gpio

This reminds me of ladder diagrams from industrial control systems—not because of the domain, but because both emphasize a linear, visually structured flow of logic.

One thing I didn’t see mentioned here yet: a lot of high-performance data center workloads don’t actually go through the Linux kernel’s network stack at all.

Instead, they use DPDK, XDP, or userspace stacks like Onload or VMA—often with SmartNICs doing hardware offload. In those cases, this patch wouldn’t apply, since packet processing happens entirely outside the kernel.

That doesn’t mean the patch isn’t valuable—it clearly helps in setups where the kernel is in the datapath (e.g., CDNs, ingress nodes, VMs, embedded Linux systems). But it probably won’t move the needle for workloads that already bypass the kernel for performance or latency reasons. So the 30% power reduction headline is likely very context-dependent.

Do their stats include the guy who forgets to take it every third day, or is that part of the 1%?

I used to think Python had no place in embedded — way too heavy, too dynamic, too unpredictable.

But I’ve been messing around with some ideas that challenge that assumption. If you throw out the traditional VM model and rethink things from the ground up (no VM, no JIT, not even C underneath), it’s surprisingly possible to get Python code close to the metal.

Can confirm some bans just teach employees how to be more creative. Like, say, hypothetically pairing a keyboard to a phone...

I saw it was Palladium but didn’t actually know what kind of publication that was until I checked the homepage—makes more sense now. Definitely reads more like a speculative 'Jules Verne for the compute age' than a serious technical proposal. Fun thought experiment, but falls apart fast if you think operationally.

Well, you could basically do any llvm supported language. I remember a few years ago I tried creating a DSL just for fun and the sake of testing on iOS.

You can create a frontend of whatever language you want for llvm so it’d translate it to llvm-ir.

You just need a small wrapper in objective c to make it work.

Fascinating work! I’m not a physicist, but I wonder from what distance down the lane this model’s predictions become reliably accurate. It might be interesting to pair it with a second model—one that helps bowlers achieve the needed initial conditions (release speed, angle, spin) with the required precision. A kind of two-stage approach to managing the chaos in the system.

This is impressive work—feels like it should be packaged as a handbook for high-performance computing or even a practical guide for HFT developers. Great resource!

Try compiling with optimizations. I think by default this site doesn't add optimization flags.

Here what happens with optimizations: https://godbolt.org/z/G18zd7chP

Look at the registers usages vs stack

Not an expert in JS, but maybe this makes sense in JS where everything is passed as objects anyway and having a single param is often more readable there.

But in native languages like C/C++/etc, this pattern usually hurts performance. Separate arguments go into registers (faster but depends on number of arguments), while structs often involve indirection, and sometimes alignment/padding issues. Also, passing a const struct doesn’t guarantee the fields inside are truly const.

That said, it's context dependent. If you're passing stuff through multiple layers or want a more stable function signature, using a struct can be cleaner. Just not something I’d generalize to any language or any use case.

I’m not deep into autodiff (just recall some calculus from university), but the syntax in this post reminds me a lot of ML (the programming language, not machine learning)

I know autodiff isn’t lambda calculus, but the expression-based structure and evaluation rules feel similar. Couldn’t this be implemented in something like ML or Clojure? Just wondering what the custom DSL adds that existing functional languages wouldn’t already support

Proof? Research?

The whole “AI doesn’t understand” argument assumes we do.

John Searle’s Chinese Room makes the case: a person follows rules to manipulate Chinese symbols without knowing the language. From the outside, it looks like understanding—but inside, it’s just symbol shuffling.

But what if that’s us too?

What if our brains are just predictive engines—layers of heuristics, compression, and feedback—outputting the next “token” based on statistical patterns?

What if intelligence is just what statistical fluency feels like from the inside?

I visited California last summer and even the most basic 2-star motels — like on the outskirts of San Diego — were going for over $300 a night. Nothing fancy, just clean sheets and a door.

I think a big part of the drop in European tourism is simple: the U.S. has gotten insanely expensive.

Between hotels, food, transportation, and tipping culture, the cost adds up fast. For many travelers, it’s not about politics or safety. It’s just not worth the price.