- Python dominates AI due to its ecosystem, but the GIL, dynamic typing, and the interpreter weigh down performance.
- Mojo, based on MLIR, offers compilation, true parallelization, and compatibility with Python libraries.
- Modular unifies runtimes for PyTorch and TensorFlow, with integrated acceleration and quantization.
- Huge speedups (Mandelbrot, SIMD) are possible; the challenge is to bring that advantage to production and multiple hardware.
The Mojo vs. Python performance debate is raging because it touches on the heart of modern AI: real speed, ease of use, and hardware support. In recent years, acceleration figures have emerged that, on paper, seem like science fiction, but they are backed by profound changes in compilers and in how code is executed on CPUs, GPUs, and AI accelerators.
In this article, we've compiled a comprehensive overview of everything published across various sources about Python, its performance limitations, and the approach of Mojo , the language powered by Modular and spearheaded by Chris Lattner (LLVM, Clang, Swift). We also explain MLIR, the reasons behind GIL bottlenecks, the differences between CUDA and MPS, compatibility with the Python ecosystem, and the adoption challenges that still lie ahead.
Python dominates AI, but its architecture doesn't help performance
It's no surprise that Python is the universal language of AI : simple syntax, thousands of libraries, tons of tutorials, and a huge community. This popularity, however, comes with an uncomfortable reality: Python is interpreted , dynamically typed, and subject to the Global Interpreter Lock (GIL) , which limits the concurrent execution of pure Python code to a single thread.
This design allows for faster development, but it compromises speed and memory efficiency compared to compiled languages like C/C++, Swift, or Rust. In ML/DL workloads, where every millisecond counts and the hardware is incredibly fast, this penalty is extremely noticeable.
To compensate, the ecosystem has resorted to workarounds: NumPy (with parts in C and Fortran), libraries that delegate to native code , and C/C++ extensions for critical operations. It works, yes, but it introduces layers, dependencies, and a Frankenstein's monster of versions, frameworks, and backends that can be tricky to maintain in production.
Furthermore, parallelism in Python often relies on multiprocessing or on libraries releasing the GIL in native sections. The result is that, unless the workload is very well delegated to C/C++ or the GPU, Python's raw performance becomes a bottleneck.
NumPy and other "patches": essential, but with limitations
NumPy is the classic example: many of its critical operations are written in C or Fortran , which is significantly faster than pure Python. However, when it comes to fine parallelism, scaling to multiple cores, or integration with new accelerators, Python's limitations reappear , especially if the flow of control frequently returns to the interpreter.
This layered approach (Python → C/C++ extensions → drivers/hardware) is effective, but complex to debug and deploy . In AI at scale, with training, inference, and post-processing pipelines, this operational complexity weighs almost as heavily as the available FLOPS.
CUDA, MPS and the portability problem
CUDA acceleration (NVIDIA) is a lifesaver, but also a gilded cage: some models and optimizations are entirely dependent on the NVIDIA stack. If you try to run the same code on Apple Silicon with Metal Performance Shaders (MPS) or on AMD GPUs, you may encounter unsupported instructions or incomplete compute paths.
The most common comparison is clear: with CUDA you're driving a "Ferrari," while MPS can feel more limited for certain workloads. Even so, the industry is pushing towards standards and portability because no one wants to tie their business to a single hardware vendor unless absolutely necessary.
MLIR: the bridge the new era of computing needed
To understand what Mojo proposes, we need to talk about MLIR (Multi-Level Intermediate Representation) , a project born within the LLVM ecosystem that adds an intermediate representation designed for high performance and machine learning . Unlike the classic LLVM pipeline, MLIR handles data graphs, vectorization, tessellation, DMA insertion, and explicit cache management.
In layman's terms: MLIR allows transforming high-level code into implementations very close to the target hardware (CPUs, GPUs, TPUs, NPUs, FPGAs, etc.), extracting parallelism and applying HPC optimizations that the classic compiler did not cover as well for these domains.
What exactly is Mojo?
Mojo is a language that presents itself as a superset of Python : it maintains a familiar syntax, can leverage the same libraries, and integrates a modern compilation model supported by MLIR. It was launched in 2023, initially as a web playground accessible on demand, and later with local execution on GNU/Linux and macOS. In February 2025, its standard library was made open source, although the compiler remains closed to this day.
The goal is ambitious: the simplicity of Python with the performance of C/C++ , plus the security and user-friendliness we've seen in languages like Rust or Swift. In other words, writing at a high level and producing small, fast, and easy-to-deploy binaries.
Design keys: typing, memory, structs and functions
Among the most striking features are strong typing (and static typing when needed), the use of let/var to declare immutable and mutable elements, and support for structs with compile-defined designs, which facilitate the generation of optimal machine code.
Mojo allows you to declare functions with `fn` in addition to `def` ; generally speaking, `fn` tends to imply more restrictions and, therefore, better optimization potential for the compiler. It also boasts "zero-cost abstractions" and self-tuning capabilities , where the compiler selects efficient parameters for the target platform.
Without GIL and with real parallelization
Unlike Python, Mojo doesn't rely on GIL . The runtime and compiler are designed to leverage threads, vectors, and accelerators without the developer having to wrestle with the interpreter's basic concurrency. In practice, this means that tasks that in Python "hit up" with GIL can truly run in parallel.
This point is key in intensive computing: if you can break a problem down into subtasks and run them concurrently in a native way, the performance leap is not incremental, it's a league change.
Performance: from Mandelbrot to vectorized versions
To measure improvements, a recurring test is the Mandelbrot set , a computationally intensive fractal generator perfect for parallelization. With pure Python, times exceeding 1000 seconds have been reported , while implementations in Mojo have dropped to around 0,03 seconds after successive optimizations.
Progressions of the following type have been documented: naive Python version → NumPy → naive Mojo version → vectorized Mojo with SIMD . With this pipeline of improvements, enormous speedups have been observed, ranging from 35.000x to reported figures of 68.000x in specific scenarios. These are spectacular numbers that, as always, depend on the algorithm, the hardware, and the care you put into optimization.
Simple compilation and deployment
Mojo follows the build-to-binary philosophy : you build, you get an executable, and you distribute it . If you're coming from Python, this avoids the headaches of virtual environments , wheels , and combinations of library versions that don't always play well together.
To give you an idea, "Hello World" could be compiled and run with a simple mojo hello.mojo . Furthermore, the files have the .mojo extension (the flame emoji has also become popular as a wink), making them easier to identify within hybrid projects.
Python compatibility and ecosystem
Part of Mojo's charm is that it doesn't force you to throw away what you already have : its compatibility with the Python ecosystem means you can continue using libraries like NumPy, Pandas, or Matplotlib, while adopting more efficient structures and types when it suits you.
In practice, this “Python++” strategy smooths the adoption curve: you maintain your codebase , move hot pieces to Mojo, and leverage the compiler and MLIR to squeeze out performance without abandoning the syntax you know.
Modular: a runtime to unify PyTorch and TensorFlow
In addition to the language, Modular has introduced a universal framework/runtime capable of running PyTorch and TensorFlow models without requiring the installation of both stacks. According to these sources, its architecture can accelerate TensorFlow execution by up to 3x and PyTorch by up to 2,5x , while also integrating quantization tools , thus contributing to AI scalability.
The vision is to avoid the "three-layer" hell (Python → C/C++ → specific hardware) with a single programming layer and a backend that talks to any hardware and gets the best out of every platform without rewriting your model every other day.
Quantization: reducing size without sacrificing accuracy
Quantizing models is like an MP3 for neural networks: you reduce accuracy in certain weights/layers and, in return, you reduce the size and speed up inference. The loss of accuracy is usually small (for example, going from 94% to 91% in a classifier) and the gain in deployment and speed more than compensates.
This approach is key to bringing models to local devices while respecting privacy. In fact, stacks like Core ML and accelerators like Apple's NPUs (via MPS/Accelerate) are pushing towards compressed models that fit and run smoothly on an iPhone or Mac without sending data to the cloud.
From Swift for TensorFlow to Mojo: Lattner's journey
The path to this point is no accident. After his time at Apple (LLVM, Clang, Swift ), Chris Lattner worked at Tesla and Google Brain, where he spearheaded Swift for TensorFlow . That attempt to combine a modern language with machine learning was shelved, but it yielded lessons that have now crystallized in MLIR and the design of Mojo.
Before Modular, Lattner also dabbled in the RISC-V world (SciFive), which fits with the idea that the future of AI involves many types of hardware and we need compilers and runtimes capable of quickly adapting to all of them.
Project status, support and adoption
Mojo was launched in 2023, and although the language is evolving rapidly, it is still in a maturation phase . Its standard library was opened in February 2025, but the compiler remains closed . In terms of popularity (TIOBE index), Mojo ranks below the top 50, which is to be expected for a language that is only two years old.
In the "who's who" section, support from Amazon, AMD, NVIDIA, and Inworld has been mentioned . Even so, to compete with Python, it will need a community, documentation, packages, and production success stories that can serve as a benchmark for others.
Challenges: community, reflection, and dynamic characteristics
Beyond performance, Python wins in terms of community, resources, and ecosystem . Mojo will have to close gaps in areas where Python excels, such as certain reflection mechanisms or widely used dynamic patterns. It will also need to continue refining its user-friendliness to make the transition from Python completely seamless.
From a technical standpoint, the promise of " compiling for everything " sounds great, but each backend (CUDA, ROCm, MPS, TPUs, FPGAs…) has its nuances. Maintaining consistent functionality and performance across all of them in the runtime is a marathon, not a sprint.
Mojo and GPUs: Beyond NVIDIA
One of Mojo and MLIR's strengths is their ability to target GPUs from both NVIDIA and AMD , not just the CUDA ecosystem. If this support remains up-to-date and competitive, many companies will see the strategic advantage of not being locked into a single vendor.
At the same time, the Apple world (with MPS ) and other specialized accelerators (NPUs, FPGAs ) demand appropriate compilation paths and libraries. The "write once, run fast everywhere" promise is ambitious, and if properly delivered, it would be a game-changer.
Debate: New language or “Python++”?
In technical forums, there's debate about whether Mojo is "another variant of Python" or a new language that only shares syntax. For everyday use, the crucial thing is that you can reuse your code and libraries while simultaneously writing performance components with richer types and structures.
This duality, combined with the modern MLIR compiler, is what allows "hello world" to be user-friendly while also enabling your computing kernels to approach or even surpass the performance of C/C++ in vectorized scenarios.
Resources, community, and learning
If you're starting out in AI, open learning communities are invaluable. These spaces, geared towards both students and teachers, offer opportunities to ask questions, share resources, and progress from the basics to advanced techniques. They're fantastic places to practice, compare approaches, and get real-world answers.
The outreach ecosystem also helps: from Mojo launch summaries by experts like Jeremy Howard, to free Python courses on video platforms that get you coding at no cost. The stronger the community surrounding Mojo, the easier it will be for companies and developers to adopt it.
Practical notes and interesting details
Small quality-of-life details also add up: .mojo files , support for fn / def , direct execution with the mojo command , or the explicit intention to offer binaries that are easy to distribute . They're mundane things, but when you scale projects, they make all the difference.
At the same time, the influence of Rust and Swift on type design, memory safety, and zero-cost abstractions must be acknowledged . This is no coincidence: Lattner comes from creating Swift and piloting LLVM/Clang; this heritage is evident in the compiler's design.
From lab to production: what you can expect
If you're going to try Mojo today, it makes sense to use it in high-impact modules (computing kernels, intensive transformations, or tight loops). Keep your orchestration and tooling in Python, and migrate high-demand components to Mojo to measure the real benefit in your metrics.
According to the reports analyzed, Mandelbrot-type tasks or SIMD kernels have achieved enormous speedups . In real pipelines, with I/O, preprocessing, and third-party libraries, you'll see significant gains, although more modest and dependent on the dominant bottleneck.
Unified layers: goodbye to the “Frankenstack”
A key promise of the Modular stack is the unification of layers: instead of scattered Python + C/C++ + specific backends, it offers a single language for all three layers and a runtime that negotiates with the hardware . Less "glue," fewer incompatibilities, and less defensive maintenance.
If this vision takes hold, training and inference processes can move between NVIDIA, AMD, Apple Silicon, TPUs, or NPUs without requiring a complete reprogramming of the project. And that, more than a technical detail, is a business strategy : freedom to choose hardware based on cost, availability, or energy efficiency.
A note on voice models and transcription
In real-world implementations, when porting models like Whisper (transcription) from Python to native routes or other APIs (MPS/Accelerate), incompatibilities arise: certain instructions exist in CUDA but not in MPS, or vice versa. This is where a unified backend and a compiler with MLIR can save you a lot of headaches.
Without that common glue, you end up with code branches and manual ports that slow down the project's evolution. With it, the promise is to write once and get efficient routing on every supported platform.
“Meta” context: outreach, sponsorships, and the tech community
Some of the material fueling this debate comes from podcasts and technical blogs that combine educational content with sponsorships and communities (even merchandising). Beyond the anecdotal (courses, apps, Twitch, background music, podcast network support…), what's interesting is that the technical debate has moved beyond its niche and is resonating with a wide range of audiences.
That noise is good: it brings tough questions, real-world use cases , and experiences with a variety of hardware. Increasing the reach of the conversation toward MLIR and Mojo accelerates bug detection, migration guides, and the creation of recipes that we can all reuse.
The overall picture is clear: Python will remain the gateway to AI, but a pragmatic alternative already exists when performance is paramount. Mojo doesn't aim to eliminate Python, but rather to elevate it with a modern compiler , true parallelization, and a runtime layer that understands both today's and tomorrow's accelerators. If you work in ML/DL and time/cost per inference or training epoch matters, it's worth trying with your own data and hardware.
