- Python domineert AI vanwege het ecosysteem, maar GIL, dynamische typering en de interpreter belemmeren de prestaties.
- Mojo, gebaseerd op MLIR, biedt compilatie, echte parallelisatie en compatibiliteit met Python-bibliotheken.
- Modulair verenigt runtimes voor PyTorch en TensorFlow, met geïntegreerde versnelling en kwantificering.
- Grote versnellingen (Mandelbrot, SIMD) zijn mogelijk; de uitdaging is om dat voordeel naar de productieomgeving en meerdere hardwaremodellen te brengen.
Het debat over de prestaties van Mojo versus Python woedt hevig omdat het de kern van moderne AI raakt: echte snelheid, gebruiksgemak en hardwareondersteuning. De afgelopen jaren zijn er versnellingscijfers verschenen die op papier sciencefiction lijken, maar die worden ondersteund door ingrijpende veranderingen in compilers en in de manier waarop code wordt uitgevoerd op CPU's, GPU's en AI-acceleratoren.
In dit artikel hebben we een uitgebreid overzicht samengesteld van alles wat er in verschillende bronnen is gepubliceerd over Python, de prestatiebeperkingen ervan en de aanpak van Mojo , de taal die wordt aangedreven door Modular en geleid door Chris Lattner (LLVM, Clang, Swift). We leggen ook MLIR uit, de oorzaken van GIL-knelpunten, de verschillen tussen CUDA en MPS, compatibiliteit met het Python-ecosysteem en de uitdagingen die nog voor de implementatie liggen.
Python domineert AI, maar de architectuur ervan draagt niet bij aan de prestaties
Het is geen verrassing dat Python de universele taal van AI is : eenvoudige syntaxis, duizenden bibliotheken, talloze tutorials en een enorme community. Deze populariteit gaat echter gepaard met een ongemakkelijke realiteit: Python is een geïnterpreteerde taal , dynamisch getypeerd en onderhevig aan de Global Interpreter Lock (GIL) , die de gelijktijdige uitvoering van pure Python-code beperkt tot één enkele thread.
Dit ontwerp maakt snellere ontwikkeling mogelijk, maar gaat ten koste van de snelheid en het geheugenverbruik in vergelijking met gecompileerde talen zoals C/C++, Swift of Rust. Bij ML/DL-workloads, waar elke milliseconde telt en de hardware ongelooflijk snel is, is dit nadeel zeer merkbaar.
Om dit te compenseren, heeft het ecosysteem zijn toevlucht genomen tot noodoplossingen: NumPy (met onderdelen in C en Fortran), bibliotheken die taken delegeren aan native code , en C/C++-extensies voor kritieke bewerkingen. Het werkt, ja, maar het introduceert lagen, afhankelijkheden en een Frankenstein-achtig monster van versies, frameworks en backends die lastig te onderhouden kunnen zijn in een productieomgeving.
Bovendien is parallellisatie in Python vaak afhankelijk van multiprocessing of van bibliotheken die de GIL vrijgeven in native secties. Het gevolg is dat, tenzij de werklast zeer goed wordt gedelegeerd aan C/C++ of de GPU, de pure prestaties van Python een knelpunt vormen.
NumPy en andere "patches": essentieel, maar met beperkingen
NumPy is het klassieke voorbeeld: veel van de cruciale bewerkingen zijn geschreven in C of Fortran , wat aanzienlijk sneller is dan pure Python. Echter, als het gaat om fijne parallelisatie, schaalbaarheid naar meerdere cores of integratie met nieuwe accelerators, komen de beperkingen van Python weer aan het licht , vooral als de controlestroom regelmatig terugkeert naar de interpreter.
Deze gelaagde aanpak (Python → C/C++-extensies → drivers/hardware) is effectief, maar complex om te debuggen en te implementeren . Bij grootschalige AI, met trainings-, inferentie- en nabewerkingspipelines, weegt deze operationele complexiteit bijna net zo zwaar als het aantal beschikbare FLOPS.
CUDA, MPS en het draagbaarheidsprobleem
CUDA- acceleratie (NVIDIA) is een redder in nood, maar tegelijkertijd ook een gouden kooi: sommige modellen en optimalisaties zijn volledig afhankelijk van de NVIDIA-stack. Als je dezelfde code probeert uit te voeren op Apple Silicon met Metal Performance Shaders (MPS) of op AMD GPU's, kun je te maken krijgen met niet-ondersteunde instructies of onvolledige rekenpaden.
De meest voorkomende vergelijking is duidelijk: met CUDA rijd je in een "Ferrari", terwijl MPS voor bepaalde workloads beperkter kan aanvoelen. Desondanks streeft de industrie naar standaarden en portabiliteit , omdat niemand zijn bedrijf aan één hardwareleverancier wil binden, tenzij het absoluut noodzakelijk is.
MLIR: de brug die het nieuwe computertijdperk nodig heeft
Om te begrijpen wat Mojo voorstelt, moeten we het hebben over MLIR (Multi-Level Intermediate Representation) , een project dat is ontstaan binnen het LLVM-ecosysteem en dat een tussenliggende representatie toevoegt die is ontworpen voor hoge prestaties en machine learning . In tegenstelling tot de klassieke LLVM-pipeline, behandelt MLIR datagrafieken, vectorisatie, tessellatie, DMA-insertie en expliciet cachebeheer.
Simpel gezegd: MLIR maakt het mogelijk om code op hoog niveau om te zetten in implementaties die zeer dicht bij de beoogde hardware liggen (CPU's, GPU's, TPU's, NPU's, FPGA's, enz.), waarbij parallellisme wordt geëxtraheerd en HPC-optimalisaties worden toegepast die de klassieke compiler voor deze domeinen minder goed ondersteunde.
Wat is Mojo precies?
Mojo is een programmeertaal die zichzelf presenteert als een superset van Python : het behoudt een vertrouwde syntaxis, kan gebruikmaken van dezelfde bibliotheken en integreert een modern compilatiemodel dat wordt ondersteund door MLIR. Het werd gelanceerd in 2023, aanvankelijk als een webomgeving die op aanvraag toegankelijk was, en later met lokale uitvoering op GNU/Linux en macOS. In februari 2025 werd de standaardbibliotheek open source gemaakt, hoewel de compiler tot op de dag van vandaag gesloten blijft.
Het doel is ambitieus: de eenvoud van Python met de prestaties van C/C++ , plus de beveiliging en gebruiksvriendelijkheid die we kennen van talen als Rust of Swift. Met andere woorden: programmeren op een hoog niveau en het produceren van kleine, snelle en eenvoudig te implementeren binaire bestanden.
Ontwerptoetsen: typen, geheugen, structuren en functies
Tot de meest opvallende kenmerken behoren sterke typering (en statische typering waar nodig), het gebruik van let/var om onveranderlijke en veranderlijke elementen te declareren, en ondersteuning voor structs met compiler-gedefinieerde ontwerpen, wat het genereren van optimale machinecode vergemakkelijkt.
Mojo biedt naast `def` ook de mogelijkheid om functies te declareren met `fn` ; over het algemeen legt `fn` meer beperkingen op en biedt daardoor een beter optimalisatiepotentieel voor de compiler. Het beschikt bovendien over "zero-cost abstractions" en zelfafstemmende mogelijkheden , waarbij de compiler efficiënte parameters selecteert voor het doelplatform.
Zonder GIL en met echte parallelisatie
In tegenstelling tot Python is Mojo niet afhankelijk van de GIL (Global Interpreter Lock). De runtime en compiler zijn ontworpen om gebruik te maken van threads, vectoren en accelerators, zonder dat de ontwikkelaar zich hoeft bezig te houden met de basisprincipes van parallelle uitvoering van de interpreter. In de praktijk betekent dit dat taken die in Python de GIL gebruiken, daadwerkelijk parallel kunnen worden uitgevoerd.
Dit punt is cruciaal bij intensief computergebruik: als je een probleem kunt opsplitsen in subtaken en deze gelijktijdig en op een native manier kunt uitvoeren, is de prestatieverbetering niet geleidelijk, maar een enorme verandering.
Prestaties: van Mandelbrot naar vectorversies
Om verbeteringen te meten, wordt regelmatig de Mandelbrot- set gebruikt als test. Dit is een rekenintensieve fractalgenerator die zich uitstekend leent voor parallelisatie. Met pure Python zijn tijden van meer dan 1000 seconden gerapporteerd , terwijl implementaties in Mojo na opeenvolgende optimalisaties zijn teruggebracht tot ongeveer 0,03 seconden.
Er zijn verschillende ontwikkelingsstappen gedocumenteerd, zoals: naïeve Python-versie → NumPy → naïeve Mojo-versie → gevectoriseerde Mojo met SIMD . Met deze reeks verbeteringen zijn enorme snelheidsverbeteringen waargenomen, variërend van 35.000x tot, in specifieke scenario's, zelfs 68.000x. Dit zijn spectaculaire cijfers die, zoals altijd, afhangen van het algoritme, de hardware en de zorgvuldigheid waarmee de optimalisatie wordt uitgevoerd.
Eenvoudige compilatie en implementatie
Mojo hanteert de 'build-to-binary' -filosofie : je bouwt, je krijgt een uitvoerbaar bestand en je distribueert het . Als je bekend bent met Python, vermijdt dit de problemen met virtuele omgevingen , wheels en combinaties van bibliotheekversies die niet altijd goed samenwerken.
Om je een idee te geven: "Hello World" zou gecompileerd en uitgevoerd kunnen worden met een simpele mojo hello.mojo . Bovendien hebben de bestanden de extensie .mojo (de vlam-emoji is ook populair geworden als knipoog), waardoor ze gemakkelijker te herkennen zijn binnen hybride projecten.
Compatibiliteit en ecosysteem van Python
Een van de charmes van Mojo is dat je niet gedwongen wordt om weg te gooien wat je al hebt : de compatibiliteit met het Python-ecosysteem betekent dat je bibliotheken zoals NumPy, Pandas of Matplotlib kunt blijven gebruiken, terwijl je tegelijkertijd efficiëntere structuren en gegevenstypen gebruikt wanneer dat je uitkomt.
In de praktijk zorgt deze "Python++"-strategie voor een soepelere overgang: je onderhoudt je codebase , verplaatst de meest gebruikte onderdelen naar Mojo en maakt gebruik van de compiler en MLIR om de prestaties te optimaliseren zonder de bekende syntaxis te verloochenen.
Modulair: een runtime om PyTorch en TensorFlow te verenigen
Naast de programmeertaal heeft Modular een universeel framework/runtime geïntroduceerd waarmee PyTorch- en TensorFlow -modellen kunnen worden uitgevoerd zonder dat beide stacks geïnstalleerd hoeven te worden. Volgens deze bronnen kan de architectuur de uitvoering van TensorFlow tot wel 3 keer en die van PyTorch tot wel 2,5 keer versnellen, en integreert het bovendien kwantificatietools , wat bijdraagt aan de schaalbaarheid van AI.
De visie is om de "drie-lagen" hel (Python → C/C++ → specifieke hardware) te vermijden met één enkele programmeerlaag en een backend die met elke hardware communiceert en het beste uit elk platform haalt zonder dat je je model om de paar dagen hoeft te herschrijven.
Kwantisering: de grootte verkleinen zonder in te boeten aan nauwkeurigheid
Het kwantiseren van modellen is vergelijkbaar met een MP3-bestand voor neurale netwerken: je verlaagt de nauwkeurigheid in bepaalde gewichten/lagen en in ruil daarvoor verklein je de omvang en versnel je de inferentie. Het verlies aan nauwkeurigheid is meestal klein (bijvoorbeeld van 94% naar 91% bij een classificator) en de winst in implementatie en snelheid compenseert dit ruimschoots.
Deze aanpak is cruciaal om modellen naar lokale apparaten te brengen met respect voor de privacy. Sterker nog, technologieën zoals Core ML en accelerators zoals Apple's NPU's (via MPS/Accelerate) stimuleren de ontwikkeling van gecomprimeerde modellen die passen en soepel draaien op een iPhone of Mac zonder gegevens naar de cloud te hoeven sturen.
Van Swift voor TensorFlow naar Mojo: Lattners reis
De weg naar dit punt is geen toeval. Na zijn tijd bij Apple (LLVM, Clang, Swift ) werkte Chris Lattner bij Tesla en Google Brain, waar hij de ontwikkeling van Swift voor TensorFlow leidde . Die poging om een moderne programmeertaal te combineren met machine learning werd uiteindelijk stopgezet, maar leverde wel lessen op die nu hun weerslag hebben gehad op MLIR en het ontwerp van Mojo.
Voordat Lattner zich met Modular bezighield, experimenteerde hij ook met RISC-V (SciFive), wat aansluit bij het idee dat de toekomst van AI vele soorten hardware omvat en dat we compilers en runtimes nodig hebben die zich snel aan al deze hardware kunnen aanpassen.
Projectstatus, ondersteuning en acceptatie
Mojo werd gelanceerd in 2023 en hoewel de taal zich snel ontwikkelt, bevindt ze zich nog steeds in een ontwikkelingsfase . De standaardbibliotheek werd in februari 2025 openbaar gemaakt, maar de compiler blijft gesloten . Qua populariteit (TIOBE-index) staat Mojo buiten de top 50, wat te verwachten is voor een taal die pas twee jaar oud is.
In het gedeelte "wie is wie" wordt de steun van Amazon, AMD, NVIDIA en Inworld genoemd . Desondanks heeft het, om met Python te kunnen concurreren, een community, documentatie, pakketten en succesvolle productieprojecten nodig die als maatstaf voor anderen kunnen dienen.
Uitdagingen: gemeenschap, reflectie en dynamische kenmerken
Naast prestaties wint Python het op het gebied van community, resources en ecosysteem . Mojo zal tekortkomingen moeten wegwerken op gebieden waar Python uitblinkt, zoals bepaalde reflectiemechanismen of veelgebruikte dynamische patronen. Het zal ook de gebruiksvriendelijkheid verder moeten verbeteren om de overstap van Python volledig soepel te laten verlopen.
Vanuit technisch oogpunt klinkt de belofte van " compileren voor alles " geweldig, maar elke backend (CUDA, ROCm, MPS, TPU's, FPGA's, enz.) heeft zijn eigen nuances. Het handhaven van consistente functionaliteit en prestaties voor al deze backends tijdens de runtime is een marathon, geen sprint.
Mojo en GPU's: verder dan NVIDIA
Een van de sterke punten van Mojo en MLIR is hun vermogen om GPU's van zowel NVIDIA als AMD te ondersteunen , en niet alleen die van het CUDA-ecosysteem. Als deze ondersteuning actueel en concurrerend blijft, zullen veel bedrijven het strategische voordeel inzien van niet gebonden te zijn aan één enkele leverancier.
Tegelijkertijd vereisen de Apple-wereld (met MPS ) en andere gespecialiseerde accelerators (NPU's, FPGA's ) geschikte compilatiepaden en bibliotheken. De belofte van "schrijf één keer, voer overal snel uit" is ambitieus, en als die goed wordt waargemaakt, zou het een revolutionaire verandering teweegbrengen.
Debat: Nieuwe taal of “Python++”?
In technische fora wordt gedebatteerd of Mojo "een andere variant van Python" is of een nieuwe taal die alleen de syntaxis deelt. Voor dagelijks gebruik is het cruciaal dat je je code en bibliotheken kunt hergebruiken, terwijl je tegelijkertijd prestatieverhogende componenten schrijft met rijkere gegevenstypen en structuren.
Deze dualiteit, in combinatie met de moderne MLIR-compiler, maakt "hello world" gebruiksvriendelijk en zorgt er tegelijkertijd voor dat uw computerkernels in gevectoriseerde scenario's de prestaties van C/C++ benaderen of zelfs overtreffen.
Hulpbronnen, gemeenschap en leren
Als je net begint met AI, zijn open leergemeenschappen van onschatbare waarde. Deze omgevingen, gericht op zowel studenten als docenten, bieden mogelijkheden om vragen te stellen, bronnen te delen en van de basisprincipes naar geavanceerde technieken toe te werken. Het zijn fantastische plekken om te oefenen, benaderingen te vergelijken en antwoorden uit de praktijk te krijgen.
Het ecosysteem rondom Mojo draagt hier ook aan bij: van samenvattingen van de Mojo-lancering door experts zoals Jeremy Howard tot gratis Python-cursussen op videoplatformen waarmee je kosteloos kunt leren programmeren. Hoe sterker de community rondom Mojo, hoe makkelijker het voor bedrijven en ontwikkelaars zal zijn om het te adopteren.
Praktische notities en interessante details
Ook kleine details die het gebruiksgemak vergroten, tellen mee: .mojo- bestanden , ondersteuning voor fn / def , directe uitvoering met het mojo- commando , of de expliciete intentie om binaire bestanden aan te bieden die gemakkelijk te distribueren zijn . Het zijn alledaagse dingen, maar bij het opschalen van projecten maken ze een wereld van verschil.
Tegelijkertijd moet de invloed van Rust en Swift op typeontwerp, geheugenveiligheid en zero-cost abstracties worden erkend . Dit is geen toeval: Lattner heeft Swift ontwikkeld en was een van de drijvende krachten achter LLVM/Clang; deze achtergrond is duidelijk terug te zien in het ontwerp van de compiler.
Van lab tot productie: wat u kunt verwachten
Als je Mojo vandaag wilt uitproberen, is het verstandig om het te gebruiken in modules met een grote impact (rekenkernels, intensieve transformaties of strakke lussen). Houd je orchestratie en tools in Python en migreer de meest gebruikte componenten naar Mojo om het werkelijke voordeel in je statistieken te meten.
Volgens de geanalyseerde rapporten hebben Mandelbrot-achtige taken of SIMD-kernels enorme snelheidsverbeteringen opgeleverd . In echte pipelines, met I/O, preprocessing en externe bibliotheken, zul je aanzienlijke winst zien, hoewel deze bescheidener is en afhankelijk van de dominante bottleneck.
Geünificeerde lagen: vaarwel tegen de “Frankenstack”
Een belangrijke belofte van de modulaire architectuur is de unificatie van de lagen: in plaats van verspreide Python + C/C++ + specifieke backends, biedt het één taal voor alle drie de lagen en een runtime die communiceert met de hardware . Minder "lijm", minder incompatibiliteiten en minder preventief onderhoud.
Als deze visie werkelijkheid wordt, kunnen trainings- en inferentieprocessen worden verplaatst tussen NVIDIA, AMD, Apple Silicon, TPU's of NPU's zonder dat het project volledig opnieuw geprogrammeerd hoeft te worden. En dat is, meer dan een technisch detail, een bedrijfsstrategie : de vrijheid om hardware te kiezen op basis van kosten, beschikbaarheid of energie-efficiëntie.
Een opmerking over stemmodellen en transcriptie
In de praktijk ontstaan er bij het overzetten van modellen zoals Whisper (transcriptie) van Python naar native routes of andere API's (MPS/Accelerate) incompatibiliteiten: bepaalde instructies bestaan wel in CUDA, maar niet in MPS, of andersom. Een uniforme backend en een compiler met MLIR kunnen in zulke gevallen veel problemen voorkomen.
Zonder die gemeenschappelijke basis krijg je codevertakkingen en handmatige aanpassingen die de ontwikkeling van het project vertragen. Met die basis is de belofte dat je de code één keer hoeft te schrijven en vervolgens efficiënte routing krijgt op elk ondersteund platform.
'Meta'-context: outreach, sponsoring en de tech-gemeenschap
Een deel van het materiaal dat dit debat voedt, is afkomstig van podcasts en technische blogs die educatieve content combineren met sponsoring en online communities (zelfs merchandising). Naast de anekdotische voorbeelden (cursussen, apps, Twitch, achtergrondmuziek, ondersteuning van podcastnetwerken…), is het interessant dat het technische debat zijn niche heeft overstegen en een breed publiek aanspreekt.
Die ruis is goed: het brengt lastige vragen, praktijkvoorbeelden en ervaringen met diverse hardware met zich mee. Door het gesprek over MLIR en Mojo meer aandacht te geven, wordt de opsporing van bugs, de ontwikkeling van migratiehandleidingen en het creëren van herbruikbare oplossingen versneld.
Het algemene beeld is duidelijk: Python blijft de toegangspoort tot AI, maar er bestaat al een pragmatisch alternatief wanneer prestaties van het grootste belang zijn. Mojo is niet bedoeld om Python te vervangen, maar juist om het te verbeteren met een moderne compiler , echte parallelisatie en een runtime-laag die zowel de huidige als de toekomstige accelerators begrijpt. Als je werkt met machine learning/deep learning en tijd/kosten per inferentie of trainingsepoch belangrijk voor je zijn, is het de moeite waard om het met je eigen data en hardware te proberen.
