Mojo 1.0 Ships Under Qualcomm, and the Independent Benchmarks Are More Nuanced Than "CUDA Parity"

What happened with Mojo 1.0?#

Modular has published a release announcement for Mojo 1.0 — the post is titled, without much understatement, "Mojo — It's finally here!". According to Cloud Codes, which covered the release, Modular shipped it on August 11 and attached a 1.x stability promise to the language, meaning the core language should stop breaking user code between releases. Cloud Codes also reports that the release notes contained no new performance figures.

The release lands weeks after Qualcomm completed its acquisition of Modular. Qualcomm's press release confirms the completion; the $3.9 billion all-stock valuation comes from Cloud Codes' coverage and is not stated in the material we could resolve.

Mojo's pitch, as described by its creators and tested by third parties, is a single language with Python interoperability and CUDA-like low-level control that compiles to GPUs from more than one vendor. The code that claim rests on lives in the modular/modular repository, described there as "The Modular Platform (includes MAX & Mojo)".

What does the Oak Ridge benchmark paper actually say?#

The independent evidence here is "Mojo: MLIR-Based Performance-Portable HPC Science Kernels on GPUs for the Python Ecosystem", a paper from a team at Oak Ridge National Laboratory including William F. Godoy, Pedro Valero-Lara and Jeffrey S. Vetter, published in September 2025. It is the source of every "Mojo matches CUDA" claim in circulation, so its actual findings matter more than any summary of them.

The paper describes Mojo as the first language built on LLVM's Multi-Level Intermediate Representation (MLIR) compiler infrastructure, aiming to combine Python interoperability with CUDA-like syntax for compile-time portable GPU programming. The authors ported four scientific workloads to Mojo and compared them against vendor baselines on an NVIDIA H100 and an AMD MI300A:

• Seven-point stencil — memory-bound
• BabelStream — memory-bound
• miniBUDE — compute-bound
• Hartree-Fock — compute-bound with atomic operations

The headline result, in the paper's own words: "Mojo's performance is competitive with CUDA and HIP for memory-bound kernels, whereas gaps exist on AMD GPUs for atomic operations and for fast-math compute-bound kernels on both AMD and NVIDIA GPUs." The abstract does not publish specific percentage figures, so no precise speedup or slowdown numbers can be quoted from it.

The benchmark source code used in the study is public in the tdehoff/Mojo-workloads repository under an MIT license, which makes the methodology inspectable in principle.

What is actually new in Mojo 1.0?#

The documented fact is the stability commitment itself: a 1.0 label on a language that, per Cloud Codes' account of its three-year development, has been through deliberate breaking churn — keyword deletions, unifying closures and pointers, and an fn-to-def deprecation. Cloud Codes describes the 1.0 feature set as including pointer types, closures and error checks. None of these specifics appear in material we could resolve beyond the release announcement's existence, so treat them as reported, not documented.

One genuinely useful piece of fine print, also reported by Cloud Codes: the stability promise covers the language, not the standard library, whose APIs remain unstable. If accurate, that means code written against Mojo 1.0's core syntax is protected, but code built heavily on the standard library is not — a distinction most "stable release" headlines will not carry.

Does Mojo really match CUDA? Where the coverage outruns the paper#

Cloud Codes' summary describes the Oak Ridge work as "proving single-codebase Mojo kernels hit full performance parity with CUDA on Nvidia H100 and HIP on AMD MI300A." That is stronger than what the paper says.

The paper's finding is conditional: competitive on memory-bound kernels (the stencil and BabelStream), with explicit gaps on atomic operations for AMD and on fast-math compute-bound kernels for both vendors. Two of the four tested workloads fall at least partly into the gapped categories. "Competitive for memory-bound kernels, with gaps elsewhere" and "full performance parity" are different claims, and only the first is in the paper.

This matters for the adoption question. Memory-bound kernels — the category where Mojo matched the vendor baselines — are common in AI inference and stencil-style HPC. Compute-bound kernels with fast math or heavy atomics are common in training and quantum chemistry. The paper supports Mojo as a portability play; it does not yet support it as a drop-in CUDA replacement across workload types.

What are the limitations and open questions?#

The paper is candid about its own scope: it covers four kernels and two GPUs, and it notes that Mojo programming "is still fairly low-level" despite the Python syntax. Four workloads is a reasonable pilot study, not a survey of the software people actually run on GPUs. A result that would materially change the picture is the same study extended to production-scale applications and newer hardware.

Two open questions are political rather than technical, and both are reported rather than documented. Cloud Codes raises the closed-source Mojo compiler as a live controversy, with the community watching ModCon 2026 ("Compute Unlocked") for movement. And the Qualcomm acquisition cuts both ways: it gives Modular distribution and resources, but it also means the would-be neutral, cross-vendor CUDA alternative is now owned by a company with its own silicon interests. Whether Qualcomm maintains equal investment in NVIDIA and AMD backend quality is a fair thing to watch.

Finally, the sources for this story are thin in one respect: everything about the 1.0 release beyond its existence — the stability promise's exact scope, the feature list, the missing performance figures — traces to a single reporter's reading of the release notes. The release announcement itself resolved only as a title. If Modular publishes detailed notes or an independent deep dive appears, this article should be revised.

Sources#

Primary sources#

• Mojo: MLIR-Based Performance-Portable HPC Science Kernels on GPUs for the Python Ecosystem — William F. Godoy, Tatiana Melnichenko, Pedro Valero-Lara et al.; 2025-09-25; arXiv:2509.21039
• modular/modular — 2023-04-28; modular/modular
• tdehoff/Mojo-workloads — 2025-06-12; tdehoff/Mojo-workloads
• Modular: Mojo🔥 - It’s finally here!
• Qualcomm Completes Acquisition of Modular | Qualcomm
• ModCon 2026: Compute Unlocked

Reporting that surfaced this#

• Cloud Codes — Mojo 1.0 Is Here: The CUDA Rival Goes Stable (2026-08-12)