ML Compiler & System

Quadrants is an open-source translation layer that turns ordinary Python into optimized machine code at runtime, across CPU (Arm64, x86) and GPU (AMDGPU, CUDA, Metal, Vulkan) backends. CUDA is the primary target, with x86 the strong runner-up, especially for real-time simulation. The others drive adoption and support fast prototyping for research.

The ambition is explicit: build the best “Python compiler” in the world for physics and performance-critical numerical computing. We are fully committed to it, and we intend to beat leading alternatives like Nvidia Warp, Numba, or Triton.

It’s a standalone project with its own roadmap, built in the open. Genesis, our physics simulator, is its first and top-priority user, the source of its hardest workloads and its benchmarks. But Quadrants is general-purpose infrastructure for anyone writing performance-critical numerical Python, not an internal tool that happens to be public.

The bet: high-performance code should feel natural to write. Engineers write plain Python in a NumPy or PyTorch style, and Quadrants makes it fast.

You own Quadrants end to end: the API, the IR and lowering, the optimization passes, the numerical primitives, and the roadmap.

Our ultimate objective: engineers write for readability and maintainability, never for performance. They write the version of an algorithm they are most comfortable with, and Quadrants rebuilds it into kernels that run as if an expert had hand-tuned them. Performance is the compiler’s job, not theirs. Getting there is a frontier problem, part research and part engineering, and we intend to define the state of the art on it, relentlessly pushing the limit further.

It calls for two things at once: the low-level GPU and compiler skill to make a single kernel optimal, and the ability to keep the whole system coherent as it grows.

The core tradeoff is settled: usability comes first. When usability and performance collide, usability wins, unless the cost is severe. We will limit what the system supports to go fast (static shapes and fixed-size allocation baked into kernels, say), but never the convenience of the API itself. Experts who want maximum performance and full control over the generated code get lower-level escape hatches, down to inline assembly, C, or PTX.

• API & authoring experience. The surface that physics and numerical-computing engineers write against, and, as an open-source library, the product’s face to the world. Idiomatic, natural to Python users, never a separate language bolted onto Python. Clean decorators, legible constraints, sharp errors, real escape hatches.

• IR, lowering & backends. A stable IR that lowers to multiple backends, with room to grow and the door kept open for differentiable simulation. Today the computation graph is expressed through Quadrants’ own constructs. Recovering it automatically from ordinary Python is hard, and a long-term goal rather than today’s reality.

• Optimization. Turn naive code into strong execution plans: vectorization, register and shared-memory usage, barriers and atomics, cooperative threading, dead-buffer and redundant-traffic elimination, dropping needless synchronization. Move low-level optimization off users and into the platform.

• Primitives. Cholesky, eigendecomposition, matmul, reductions, solver kernels. Each owned with its correctness, benchmarks, and regression tracking.

• Watching Genesis and the compiler together. Hunt for performance wins on both sides, in Genesis and in Quadrants itself. Propose API changes that cut duplication, improve readability, and reduce platform-specific special-casing. Less to maintain, more that simply works.

• The project as a product. Benchmark real workloads, track performance over time, catch regressions early. Stay close to users (Genesis first), find friction and missing abstractions, drive adoption, set direction.

You reason about whole systems and have taste for where complexity should live. You measure before you optimize, and you reach for memory traffic and launch overhead before FLOPs. You have opinions about API design. You write tests and benchmarks as you go, not afterward.

The ground that judgment stands on:

• GPU. What optimal looks like and why: access patterns, registers, shared memory, barriers, atomics, threading. CPU intuition a plus.

• Python & API taste. Idiomatic Python. A feel for what’s natural to Python users. APIs that free users rather than constrain them.

• Compilers. The path from authoring to kernels (IR, lowering, optimization), weighed against maintainability.

And how you work: proactive and largely self-directed. You fetch context across the company instead of waiting for it. You’re comfortable talking to the engineers who use what you build, and at ease designing in the open for users you’ll never meet. Ready to grow into leading a small team (a couple of people, near term).

People adopt Quadrants from outside Genesis. Engineers write clearer code with less boilerplate. Kernels keep getting faster. Performance is tracked, not guessed. The architecture gets easier to extend, not harder.

How you work is up to you. What matters is that your ownership grows over time: blind spots shrink, the parts you can vouch for expand, technical debt goes down, the core stays sound.

That takes treating understanding as real work, not overhead. You read and challenge the codebase instead of just stacking features on it. You take nothing you did not write for granted. You watch the competition and what’s coming next, and you bring it in and ship it.

Use AI agents if they help. They are productivity tools, not code owners. You are.