- Ang Python ay nangingibabaw sa AI dahil sa ecosystem nito, ngunit ang GIL, dynamic na pag-type, at ang interpreter ay humahadlang sa pagganap.
- Ang Mojo, batay sa MLIR, ay nag-aalok ng compilation, true parallelization, at compatibility sa Python library.
- Pinag-iisa ng Modular ang mga runtime para sa PyTorch at TensorFlow, na may pinagsamang acceleration at quantization.
- Malaking speedups (Mandelbrot, SIMD) ay posible; ang hamon ay dalhin ang kalamangan na iyon sa produksyon at maramihang hardware.
Mainit ang debate sa pagganap ng Mojo vs. Python dahil naaapektuhan nito ang puso ng modernong AI: ang tunay na bilis, kadalian ng paggamit, at suporta sa hardware. Sa mga nakaraang taon, lumitaw ang mga bilang ng acceleration na, sa papel, ay tila science fiction, ngunit sinusuportahan ang mga ito ng malalaking pagbabago sa mga compiler at sa kung paano isinasagawa ang code sa mga CPU, GPU, at AI accelerator.
Sa artikulong ito, tinipon namin ang isang komprehensibong pangkalahatang-ideya ng lahat ng inilathala sa iba't ibang mapagkukunan tungkol sa Python, ang mga limitasyon sa pagganap nito, at ang pamamaraan ng Mojo , ang wikang pinapagana ng Modular at pinangunahan ni Chris Lattner (LLVM, Clang, Swift). Ipinaliwanag din namin ang MLIR, ang mga dahilan sa likod ng mga bottleneck ng GIL, ang mga pagkakaiba sa pagitan ng CUDA at MPS, ang pagiging tugma sa ecosystem ng Python, at ang mga hamon sa pag-aampon na naghihintay pa rin.
Ang Python ay nangingibabaw sa AI, ngunit ang arkitektura nito ay hindi nakakatulong sa pagganap
Hindi nakakagulat na ang Python ang unibersal na wika ng AI : simpleng syntax, libu-libong library, tone-toneladang tutorial, at isang malaking komunidad. Gayunpaman, ang kasikatan na ito ay may kaakibat na hindi komportableng katotohanan: Ang Python ay binibigyang-kahulugan , dynamic na tinatype, at napapailalim sa Global Interpreter Lock (GIL) , na naglilimita sa sabay-sabay na pagpapatupad ng purong Python code sa iisang thread lamang.
Ang disenyong ito ay nagbibigay-daan para sa mas mabilis na pag-develop, ngunit nakompromiso nito ang bilis at kahusayan ng memorya kumpara sa mga na-compile na wika tulad ng C/C++, Swift, o Rust. Sa mga workload ng ML/DL, kung saan mahalaga ang bawat millisecond at napakabilis ng hardware, ang penalty na ito ay lubos na kapansin-pansin.
Upang makabawi, ang ecosystem ay gumamit ng mga workaround: NumPy (na may mga bahagi sa C at Fortran), mga library na nagdedelegate sa native code , at mga extension ng C/C++ para sa mga kritikal na operasyon. Gumagana ito, oo, ngunit nagpapakilala ito ng mga layer, dependency, at isang halimaw na bersyon, framework, at backend ng Frankenstein na maaaring mahirap panatilihin sa produksyon.
Bukod pa rito, ang parallelism sa Python ay kadalasang umaasa sa multiprocessing o sa mga library na naglalabas ng GIL sa mga native section. Ang resulta ay, maliban kung ang workload ay mahusay na naitalaga sa C/C++ o sa GPU, ang raw performance ng Python ay nagiging isang bottleneck.
NumPy at iba pang "patches": mahalaga, ngunit may mga limitasyon
Ang NumPy ang klasikong halimbawa: marami sa mga kritikal na operasyon nito ay nakasulat sa C o Fortran , na mas mabilis nang malaki kaysa sa purong Python. Gayunpaman, pagdating sa pinong paralelismo, pag-scale sa maraming core, o integrasyon sa mga bagong accelerator, muling lumilitaw ang mga limitasyon ng Python , lalo na kung ang daloy ng kontrol ay madalas na bumabalik sa interpreter.
Ang layered approach na ito (Python → C/C++ extensions → drivers/hardware) ay epektibo, ngunit mahirap i-debug at i-deploy . Sa AI sa malawakang saklaw, na may training, inference, at post-processing pipelines, ang operational complexity na ito ay halos kasing bigat ng mga available na FLOPS.
CUDA, MPS at ang portability na problema
Ang CUDA acceleration (NVIDIA) ay isang tagapagligtas ng buhay, ngunit isa ring ginintuang hawla: ang ilang mga modelo at pag-optimize ay ganap na nakasalalay sa NVIDIA stack. Kung susubukan mong patakbuhin ang parehong code sa Apple Silicon na may Metal Performance Shaders (MPS) o sa mga AMD GPU, maaari kang makatagpo ng mga hindi sinusuportahang tagubilin o hindi kumpletong mga compute path.
Malinaw ang pinakakaraniwang paghahambing: sa CUDA, nagmamaneho ka ng isang "Ferrari," habang ang MPS ay maaaring maging mas limitado para sa ilang partikular na workload. Gayunpaman, itinutulak ng industriya ang mga pamantayan at kadalian sa pagdadala dahil walang gustong itali ang kanilang negosyo sa iisang hardware vendor maliban kung talagang kinakailangan.
MLIR: ang tulay sa bagong panahon ng computing na kailangan
Para maunawaan ang iminumungkahi ni Mojo, kailangan nating pag-usapan ang MLIR (Multi-Level Intermediate Representation) , isang proyektong isinilang sa loob ng ecosystem ng LLVM na nagdaragdag ng intermediate representation na idinisenyo para sa mataas na performance at machine learning . Hindi tulad ng klasikong pipeline ng LLVM, pinangangasiwaan ng MLIR ang mga data graph, vectorization, tessellation, DMA insertion, at explicit cache management.
Sa madaling salita: Pinapayagan ng MLIR ang pagbabago ng high-level code sa mga implementasyon na malapit sa target na hardware (mga CPU, GPU, TPU, NPU, FPGA, atbp.), pagkuha ng paralelismo at paglalapat ng mga HPC optimization na hindi gaanong nasaklaw ng klasikong compiler para sa mga domain na ito.
Ano ba talaga si Mojo?
Ang Mojo ay isang wikang nagpapakita ng sarili bilang isang superset ng Python : pinapanatili nito ang isang pamilyar na syntax, maaaring gamitin ang parehong mga library, at isinasama ang isang modernong modelo ng compilation na sinusuportahan ng MLIR. Inilunsad ito noong 2023, sa una bilang isang web playground na maa-access on demand, at kalaunan ay may lokal na pagpapatupad sa GNU/Linux at macOS. Noong Pebrero 2025, ang karaniwang library nito ay ginawang open source, bagaman ang compiler ay nananatiling sarado hanggang sa araw na ito.
Ambisyoso ang layunin: ang pagiging simple ng Python na may performance na katulad ng C/C++ , kasama ang seguridad at kadalian ng paggamit na nakita natin sa mga wikang tulad ng Rust o Swift. Sa madaling salita, ang pagsusulat sa mataas na antas at paggawa ng maliliit, mabilis, at madaling i-deploy na mga binary.
Mga susi sa disenyo: pag-type, memorya, mga istruktura at pag-andar
Kabilang sa mga pinakakapansin-pansing katangian ay ang strong typing (at static typing kung kinakailangan), ang paggamit ng let/var upang magdeklara ng mga immutable at mutable elements, at suporta para sa mga struct na may mga compile-defined na disenyo, na nagpapadali sa pagbuo ng optimal machine code.
Pinapayagan ka ng Mojo na magdeklara ng mga function gamit ang `fn` bilang karagdagan sa `def` ; sa pangkalahatan, ang `fn` ay may posibilidad na magpahiwatig ng higit pang mga paghihigpit at, samakatuwid, mas mahusay na potensyal sa pag-optimize para sa compiler. Ipinagmamalaki rin nito ang mga "zero-cost abstractions" at mga kakayahan sa self-tuning , kung saan pumipili ang compiler ng mga mahusay na parameter para sa target na platform.
Nang walang GIL at may totoong parallelization
Hindi tulad ng Python, ang Mojo ay hindi umaasa sa GIL . Ang runtime at compiler ay idinisenyo upang gamitin ang mga thread, vector, at accelerator nang hindi kinakailangang makipagbuno ang developer sa pangunahing concurrency ng interpreter. Sa pagsasagawa, nangangahulugan ito na ang mga gawain na sa Python ay "tumutugma" sa GIL ay maaaring tunay na tumakbo nang parallel.
Ang puntong ito ay mahalaga sa masinsinang pag-compute: kung maaari mong hatiin ang isang problema sa mga subtask at patakbuhin ang mga ito nang sabay-sabay sa isang katutubong paraan, ang pagtaas ng pagganap ay hindi unti-unti, ito ay isang malaking pagbabago.
Pagganap: mula sa Mandelbrot hanggang sa mga vectorized na bersyon
Upang masukat ang mga pagpapabuti, isang paulit-ulit na pagsubok ang Mandelbrot set , isang computationally intensive fractal generator na perpekto para sa parallelization. Sa purong Python, naiulat ang mga oras na lumampas sa 1000 segundo , habang ang mga implementasyon sa Mojo ay bumaba sa humigit-kumulang 0,03 segundo pagkatapos ng magkakasunod na pag-optimize.
Ang mga pag-unlad ng sumusunod na uri ay naidokumento na: naive Python version → NumPy → naive Mojo version → vectorized Mojo with SIMD . Sa pamamagitan ng pipeline ng mga pagpapabuting ito, naobserbahan ang napakalaking mga speedup, mula 35.000x hanggang sa mga naiulat na bilang na 68.000x sa mga partikular na senaryo. Ito ay mga kamangha-manghang numero na, gaya ng dati, ay nakasalalay sa algorithm, sa hardware, at sa pag-iingat na inilalagay mo sa pag-optimize.
Simpleng compilation at deployment
Sinusundan ng Mojo ang pilosopiyang build-to-binary : ikaw ang bubuo, kukuha ka ng executable, at ipamamahagi mo ito . Kung galing ka sa Python, maiiwasan nito ang mga problema sa mga virtual environment , wheels , at mga kombinasyon ng mga bersyon ng library na hindi laging maayos na tumutugma.
Para mabigyan ka ng ideya, ang "Hello World" ay maaaring i-compile at patakbuhin gamit ang isang simpleng mojo hello.mojo . Bukod pa rito, ang mga file ay may extension na .mojo (ang flame emoji ay naging popular din bilang isang kindat), na ginagawang mas madali ang mga ito matukoy sa loob ng mga hybrid na proyekto.
Pagkatugma at ecosystem ng Python
Bahagi ng kagandahan ng Mojo ay hindi ka nito pinipilit na itapon ang kung ano ang mayroon ka na : ang pagiging tugma nito sa ecosystem ng Python ay nangangahulugan na maaari mong patuloy na gamitin ang mga library tulad ng NumPy, Pandas, o Matplotlib, habang ginagamit ang mas mahusay na mga istruktura at uri kapag nababagay sa iyo.
Sa pagsasagawa, pinapakinis ng estratehiyang "Python++" na ito ang kurba ng pag-aampon: pinapanatili mo ang iyong codebase , inililipat ang mga hot piece sa Mojo, at ginagamit ang compiler at MLIR upang mapataas ang performance nang hindi iniiwan ang syntax na alam mo.
Modular: isang runtime upang pag-isahin ang PyTorch at TensorFlow
Bukod sa wika, nagpakilala ang Modular ng isang unibersal na framework/runtime na kayang patakbuhin ang mga modelo ng PyTorch at TensorFlow nang hindi nangangailangan ng pag-install ng parehong stack. Ayon sa mga sangguniang ito, ang arkitektura nito ay maaaring mapabilis ang pagpapatupad ng TensorFlow nang hanggang 3x at ang PyTorch nang hanggang 2,5x , habang isinasama rin ang mga tool sa quantization , kaya nakakatulong sa AI scalability.
Ang pangitain ay upang maiwasan ang "tatlong-patong" na impyerno (Python → C/C++ → partikular na hardware) na may iisang programming layer at isang backend na nakikipag-ugnayan sa anumang hardware at nakakakuha ng pinakamahusay mula sa bawat platform nang hindi muling isinusulat ang iyong modelo tuwing makalawang araw.
Quantization: pagbabawas ng laki nang hindi sinasakripisyo ang katumpakan
Ang pag-quantify ng mga modelo ay parang isang MP3 para sa mga neural network: binabawasan mo ang katumpakan sa ilang partikular na timbang/layer at, kapalit nito, binabawasan mo ang laki at pinapabilis ang hinuha. Ang pagkawala ng katumpakan ay karaniwang maliit (halimbawa, mula 94% patungong 91% sa isang classifier) at ang pagtaas sa deployment at bilis ay higit pa sa nababawi.
Ang pamamaraang ito ay mahalaga sa pagdadala ng mga modelo sa mga lokal na device habang nirerespeto ang privacy. Sa katunayan, ang mga stack tulad ng Core ML at mga accelerator tulad ng mga NPU ng Apple (sa pamamagitan ng MPS/Accelerate) ay nagtutulak patungo sa mga naka-compress na modelo na akma at tumatakbo nang maayos sa isang iPhone o Mac nang hindi nagpapadala ng data sa cloud.
Mula sa Swift para sa TensorFlow hanggang sa Mojo: Ang paglalakbay ni Lattner
Ang landas patungo sa puntong ito ay hindi aksidente. Pagkatapos ng kanyang panahon sa Apple (LLVM, Clang, Swift ), nagtrabaho si Chris Lattner sa Tesla at Google Brain, kung saan pinangunahan niya ang Swift para sa TensorFlow . Ang pagtatangkang pagsamahin ang isang modernong wika sa machine learning ay ipinagpaliban, ngunit nagbunga ito ng mga aral na ngayon ay naging malinaw sa MLIR at sa disenyo ng Mojo.
Bago ang Modular, sinubukan din ni Lattner ang mundo ng RISC-V (SciFive), na akma sa ideya na ang kinabukasan ng AI ay kinabibilangan ng maraming uri ng hardware at kailangan natin ng mga compiler at runtime na may kakayahang mabilis na umangkop sa lahat ng mga ito.
Katayuan ng proyekto, suporta at pag-aampon
Inilunsad ang Mojo noong 2023, at bagama't mabilis na umuunlad ang wikang ito, nasa yugto pa rin ito ng pag-unlad . Binuksan ang karaniwang library nito noong Pebrero 2025, ngunit nananatiling sarado ang compiler . Sa usapin ng kasikatan (TIOBE index), ang Mojo ay nasa ibaba ng nangungunang 50, na inaasahan para sa isang wikang dalawang taong gulang pa lamang.
Sa seksyong "sino's sino", nabanggit ang suporta mula sa Amazon, AMD, NVIDIA, at Inworld . Gayunpaman, upang makipagkumpitensya sa Python, kakailanganin nito ng isang komunidad, dokumentasyon, mga pakete, at mga kwento ng tagumpay sa produksyon na maaaring magsilbing pamantayan para sa iba.
Mga hamon: komunidad, pagmuni-muni, at mga dinamikong katangian
Higit pa sa pagganap, panalo ang Python sa mga tuntunin ng komunidad, mga mapagkukunan, at ecosystem . Kailangang punan ng Mojo ang mga puwang sa mga lugar kung saan nangunguna ang Python, tulad ng ilang mekanismo ng pagmuni-muni o malawakang ginagamit na mga dynamic na pattern. Kakailanganin din nitong patuloy na pinuhin ang kadalian ng paggamit nito upang maging ganap na maayos ang paglipat mula sa Python.
Mula sa teknikal na pananaw, maganda ang pakinggan na pangako ng " pag-compile para sa lahat ng bagay ," ngunit ang bawat backend (CUDA, ROCm, MPS, TPU, FPGA…) ay may kanya-kanyang nuances. Ang pagpapanatili ng pare-parehong functionality at performance sa lahat ng mga ito habang tumatakbo ay isang maraton, hindi isang sprint.
Mojo at GPU: Higit pa sa NVIDIA
Isa sa mga kalakasan ng Mojo at MLIR ay ang kanilang kakayahang i-target ang mga GPU mula sa parehong NVIDIA at AMD , hindi lamang ang CUDA ecosystem. Kung ang suportang ito ay mananatiling napapanahon at mapagkumpitensya, maraming kumpanya ang makakakita ng estratehikong bentahe ng hindi pagkapit sa iisang vendor.
Kasabay nito, ang mundo ng Apple (kasama ang MPS ) at iba pang espesyalisadong mga accelerator (NPU, FPGA ) ay humihingi ng angkop na mga path ng compilation at mga library. Ang pangakong "sumulat nang isang beses, tumakbo nang mabilis kahit saan" ay ambisyoso, at kung maayos na matutupad, ito ay magiging isang game-changer.
Debate: Bagong wika o “Python++”?
Sa mga teknikal na forum, may debate kung ang Mojo ay "isa pang variant ng Python" o isang bagong wika na may syntax lamang. Para sa pang-araw-araw na paggamit, ang mahalaga ay maaari mong muling gamitin ang iyong code at mga library habang sabay na nagsusulat ng mga performance component na may mas detalyadong mga uri at istruktura.
Ang dualidad na ito, kasama ang modernong MLIR compiler, ang siyang nagbibigay-daan sa "hello world" na maging user-friendly habang nagbibigay-daan din sa iyong mga computing kernel na maabot o malampasan pa ang pagganap ng C/C++ sa mga vectorized na senaryo.
Mga mapagkukunan, komunidad, at pag-aaral
Kung nagsisimula ka pa lang sa AI, napakahalaga ng mga open learning community. Ang mga espasyong ito, na nakatuon sa mga estudyante at guro, ay nag-aalok ng mga pagkakataon upang magtanong, magbahagi ng mga mapagkukunan, at sumulong mula sa mga pangunahing kaalaman hanggang sa mga advanced na pamamaraan. Ang mga ito ay magagandang lugar upang magsanay, maghambing ng mga diskarte, at makakuha ng mga sagot sa totoong mundo.
Nakakatulong din ang outreach ecosystem: mula sa mga buod ng paglulunsad ng Mojo ng mga eksperto tulad ni Jeremy Howard, hanggang sa mga libreng kurso sa Python sa mga video platform na magbibigay sa iyo ng libreng coding. Kung mas malakas ang komunidad na nakapalibot sa Mojo, mas madali para sa mga kumpanya at developer na gamitin ito.
Mga praktikal na tala at mga kawili-wiling detalye
Ang maliliit na detalye tungkol sa kalidad ng buhay ay nagdaragdag din ng halaga: mga .mojo file , suporta para sa fn / def , direktang pagpapatupad gamit ang utos na mojo , o ang tahasang intensyon na mag-alok ng mga binary na madaling ipamahagi . Mga pangkaraniwan lang ang mga ito, ngunit kapag pinalaki mo ang mga proyekto, malaki ang nagagawa ng mga ito.
Kasabay nito, dapat kilalanin ang impluwensya ng Rust at Swift sa disenyo ng uri, kaligtasan ng memorya, at mga zero-cost na abstraksyon . Hindi ito nagkataon lamang: Si Lattner ay nagmula sa paglikha ng Swift at pag-pilot sa LLVM/Clang; ang pamana na ito ay kitang-kita sa disenyo ng compiler.
Mula sa lab hanggang sa produksyon: kung ano ang maaari mong asahan
Kung susubukan mo ang Mojo ngayon, makatuwiran na gamitin ito sa mga high-impact module (computing kernels, intensive transformations, o tight loops). Panatilihin ang iyong orchestration at tooling sa Python, at ilipat ang mga high-demand na component sa Mojo upang masukat ang tunay na benepisyo sa iyong mga metrics.
Ayon sa mga ulat na sinuri, ang mga Mandelbrot-type na gawain o SIMD kernel ay nakamit ang napakalaking pagpapabilis . Sa mga totoong pipeline, gamit ang I/O, preprocessing, at mga third-party na library, makakakita ka ng mga makabuluhang pagbuti, bagama't mas katamtaman at nakadepende sa nangingibabaw na bottleneck.
Pinag-isang mga layer: paalam sa "Frankenstack"
Isang mahalagang pangako ng Modular stack ay ang pag-iisa ng mga layer: sa halip na magkakalat na Python + C/C++ + mga partikular na backend, nag-aalok ito ng iisang wika para sa lahat ng tatlong layer at isang runtime na nakikipagnegosasyon sa hardware . Mas kaunting "pandikit," mas kaunting mga hindi pagkakatugma, at mas kaunting depensibong pagpapanatili.
Kung matutupad ang pananaw na ito, ang mga proseso ng pagsasanay at paghihinuha ay maaaring lumipat sa pagitan ng NVIDIA, AMD, Apple Silicon, TPU, o NPU nang hindi nangangailangan ng kumpletong reprogramming ng proyekto. At iyon, higit pa sa isang teknikal na detalye, ay isang estratehiya sa negosyo : kalayaan na pumili ng hardware batay sa gastos, availability, o kahusayan sa enerhiya.
Isang tala sa mga modelo ng boses at transkripsyon
Sa mga implementasyon sa totoong mundo, kapag nagpo-port ng mga modelo tulad ng Whisper (transcription) mula sa Python patungo sa mga native route o iba pang API (MPS/Accelerate), lumilitaw ang mga hindi pagkakatugma: may ilang mga instruksyon na umiiral sa CUDA ngunit wala sa MPS, o kabaliktaran. Dito makakaiwas sa maraming sakit ng ulo ang isang pinag-isang backend at isang compiler na may MLIR.
Kung wala ang karaniwang pandikit na iyon, magkakaroon ka ng mga code branch at manual port na magpapabagal sa ebolusyon ng proyekto. Gamit ito, ang pangako ay magsulat nang isang beses at makakuha ng mahusay na routing sa bawat sinusuportahang platform.
Konteksto ng "Meta": outreach, mga sponsorship, at ang tech na komunidad
Ang ilan sa mga materyal na nagpapasigla sa debateng ito ay nagmumula sa mga podcast at teknikal na blog na pinagsasama ang nilalamang pang-edukasyon sa mga sponsorship at komunidad (maging ang merchandising). Higit pa sa mga anekdota (mga kurso, app, Twitch, musika sa background, suporta sa podcast network…), ang nakakainteres ay ang teknikal na debate ay lumampas na sa niche nito at umalingawngaw na sa malawak na hanay ng mga madla.
Maganda ang ingay na iyan: nagdadala ito ng mahihirap na tanong, mga totoong gamit , at mga karanasan sa iba't ibang hardware. Ang pagpapalawak ng abot ng usapan patungo sa MLIR at Mojo ay nagpapabilis sa pagtuklas ng bug, mga gabay sa paglipat, at paglikha ng mga recipe na maaari nating gamitin muli.
Malinaw ang pangkalahatang larawan: Ang Python ay mananatiling daan patungo sa AI, ngunit mayroon nang praktikal na alternatibo kung kailan pinakamahalaga ang performance. Hindi nilalayon ng Mojo na alisin ang Python, kundi ang pahusayin ito gamit ang isang modernong compiler , tunay na parallelization, at isang runtime layer na nakakaintindi sa parehong accelerators ngayon at sa hinaharap. Kung nagtatrabaho ka sa ML/DL at mahalaga ang time/cost per inference o training epoch, sulit na subukan ito gamit ang sarili mong data at hardware.
