Mojo ist endlich Open Source... Also habe ich es getestet

BBetter Stack
컴퓨터/소프트웨어

스크립트

00:00:00Mojo, die Programmiersprache, hat gerade 1.0 erreicht, und das Timing ist etwas seltsam.
00:00:05Es wurde mit einem geschlossenen Compiler veröffentlicht, sieben Tage später wurde es Open Source,
00:00:09und Qualcomm hatte das Unternehmen gerade gekauft.
00:00:12Aber vergessen wir das alles für eine Sekunde.
00:00:14Mojos eigentliche Stärke ist Python-ähnlicher Code, ohne für Geschwindigkeit auf C++ oder CUDA verzichten zu müssen.
00:00:20Schauen wir uns also an, ob das tatsächlich hält, was es verspricht.
00:00:27Das Wesen von Mojo dreht sich um eine bestimmte Frage.
00:00:30Was wäre, wenn Sie Code schreiben könnten, der sich genau wie Python anfühlt und aussieht,
00:00:34aber die wirklich wichtigen Teile ausführen könnten, ohne C++ oder CUDA aufzugeben?
00:00:39Eine einzige lesbare Sprache über CPU und GPU hinweg.
00:00:42Darum geht es hier im Grunde.
00:00:43Und da Mojo nun endlich Version 1.0 erreicht hat, wollte ich sehen, wie viel davon tatsächlich Realität ist.
00:00:49Bevor wir also zu Qualcomm, Open Source oder dergleichen kommen, lassen Sie es uns einfach ausführen.
00:00:53Wenn Ihnen Programmiertools zur Beschleunigung Ihres Workflows gefallen, abonnieren Sie den Kanal.
00:00:57Wir veröffentlichen ständig neue Videos.
00:00:59Ich mache das auf meinem Rechner, aber ich werde hier kein Mojo-Tutorial halten.
00:01:03Wenn Sie es noch nie gesehen haben, dann ja, es wird wie Python aussehen,
00:01:07aber Sie werden einige wesentliche Unterschiede feststellen.
00:01:10Auf der linken Seite sehen Sie Python.
00:01:12Auf der rechten Seite sehen Sie Mojo.
00:01:13Es ist dieselbe Schleife, dasselbe Raster, dasselbe Iterationslimit.
00:01:17Ich werde hier nicht durch die mathematischen Details gehen.
00:01:20Beobachten Sie die beiden While-Schleifen.
00:01:21Sie tun exakt dasselbe.
00:01:23Wir lassen hier zuerst Python laufen.
00:01:26Okay, großartig.
00:01:27Es lief.
00:01:28Es wurde ausgeführt.
00:01:28Nun folgt dasselbe Programm, kompiliert mit Mojo.
00:01:32Führen wir es auch hier aus.
00:01:35Und boch.
00:01:35Da haben wir es.
00:01:36Die Prüfsummen stimmen in der letzten Ziffer nicht überein.
00:01:39Sie unterscheiden sich bei einer Viertelmillion um ein paar Hundert.
00:01:43Python multipliziert erst und addiert dann.
00:01:45Der Mojo-Compiler kann dies zu einer einzigen Instruktion zusammenfassen.
00:01:49Ein paar Pixel benötigen eine zusätzliche Iteration.
00:01:51Betrachten Sie die Sekunden hier als den wahren Wert.
00:01:54Und das ist kein NumPy.
00:01:55Es ist kein Modell.
00:01:56Leistung bedeutet nicht nur, dass die CPU-Schleife schneller geworden ist.
00:02:00Man kann in Python beginnen, weil es einfach ist.
00:02:03Dann verlagert sich der Pfad zu C++ oder CUDA.
00:02:06Plötzlich besitzt man zwei Dateien und diese driften allmählich auseinander.
00:02:09Das ist also die Frage, die Mojo stellt.
00:02:12Kann die Datei, die man liest, dieselbe sein, die auf der GPU ausgeführt wird?
00:02:17Diese Funktion ist der Kernel.
00:02:18Jeder GPU-Thread addiert ein Zahlenpaar.
00:02:20Das ist alles.
00:02:21Ich habe nicht zu Metal, Swift oder CUDA gewechselt.
00:02:24Kompilieren wir es.
00:02:26Und nun läuft der Code.
00:02:28Also, ja.
00:02:30Mojo kann hier etwas ziemlich Interessantes leisten.
00:02:32Ich habe gerade einen funktionierenden GPU-Kernel auf einem MacBook kompiliert – in derselben Sprache,
00:02:38in der ich normalen Code geschrieben habe: Python.
00:02:40Ihr Code für maschinelles Lernen beginnt in Python, weil Python einfach zu handhaben ist.
00:02:44Das wissen wir alle.
00:02:45Irgendwann im Laufe der Zeit fängt die Leistung jedoch an, eine Rolle zu spielen.
00:02:48Also werden die wichtigen Teile in C++ oder CUDA neu geschrieben.
00:02:52Nun pflegen wir zwei Versionen desselben Systems.
00:02:55Und das führt mit der Zeit zu immer mehr Unklarheiten.
00:02:58Mojos Konzept ist, dass die lesbare Datei und die schnelle Datei ein und dieselbe sind.
00:03:03Der Kopf hinter alledem ist Chris Lattner.
00:03:06Er hat LLVM entwickelt, dann Clang und anschließend Swift.
00:03:10Aber einen laufenden GPU-Kernel zu erstellen, ist das eine.
00:03:14Die Sprache als 1.0 zu bezeichnen, ist dann doch etwas anderes.
00:03:18Was bedeutet Version 1.0 hier also eigentlich?
00:03:21Nicht, dass Mojo fertig ist.
00:03:23Es bedeutet mehr oder weniger Stabilität.
00:03:25Es gibt das Versprechen, dass der Code, den Sie heute schreiben, nicht kaputtgeht.
00:03:29Das zeichnet ein solches Major-Release aus.
00:03:30Doch dann stößt man auf den ersten seltsamen Punkt.
00:03:32Mojo erreichte Version 1.1, noch bevor der Compiler überhaupt Open Source war.
00:03:37Die Standardbibliothek war bereits im März 2024 geöffnet worden.
00:03:40Die Max-Kernels folgten 2025.
00:03:43Aber der Compiler, also das eigentliche Kompilierungswerkzeug, blieb bis zum 18. August dieses Jahres proprietär.
00:03:50Unter Apache 2.0 – und das ist wichtig, da er nur sieben Tage zuvor, beim Release von Mojo 1.0, noch geschlossen war.
00:03:57Das entkräftet einen der größten Kritikpunkte, mit denen sich Mojo drei Jahre lang konfrontiert sah.
00:04:02Früher hieß es: Sicher, aber der Compiler ist proprietär.
00:04:05Das kann man so nicht mehr sagen, was nach einer Entwicklung in die richtige Richtung klingt.
00:04:10Das mag sein.
00:04:10Bis man betrachtet, was drei Wochen zuvor geschehen ist.
00:04:14Qualcomms Übernahme wurde am 29. Juli abgeschlossen.
00:04:16Mojo 1.0 erschien am 11. August.
00:04:19Der Compiler wurde am 18. August geöffnet.
00:04:21Der größte Open-Source-Meilenstein in Mojos Geschichte fand also weniger als drei Wochen nach der Unabhängigkeit von Modular statt.
00:04:29Das lässt Raum für zwei völlig unterschiedliche Sichtweisen.
00:04:33Erstens: Qualcomm hat Modular gekauft, weil sie Mojo überall haben wollen.
00:04:37Wahrscheinlich eher nicht.
00:04:37Oder Qualcomm hat Modular gekauft, und am Ende wird das Ganze in ein viel größeres Unternehmen integriert.
00:04:44Qualcomm baut Chips.
00:04:45Eine Sprache, die gut für Chips kompiliert, wird dadurch weitaus wertvoller.
00:04:49Wir können sie nun frei nutzen.
00:04:50Der Schritt hin zu Open Source ergibt also durchaus Sinn.
00:04:53Ob Mojo erfolgreich sein wird, hängt jedoch wahrscheinlich nicht von Qualcomm ab.
00:04:57Es wird davon abhängen, ob die Sprache gut genug ist, um einen Wechsel überhaupt zu rechtfertigen.
00:05:02Und hier fängt die ganze Sache an, unübersichtlich zu werden.
00:05:05Mojo hat ein Benchmark-Problem.
00:05:07Im Jahr 2023 hieß es vollmundig, Mojo könne 68.000-mal schneller sein als Python.
00:05:13Das ist verrückt.
00:05:14Es gibt auch heute noch einen Beitrag, der behauptet, Mojo sei bei der DNA-Analyse 50 % schneller als Rust.
00:05:19Dieser Benchmark wurde komplett auseinandergenommen.
00:05:21Es wurde gezeigt, dass der Benchmark nicht das gemessen hat, was er vorgab zu messen.
00:05:25Und dennoch geistert die Zahl von 35.000-mal nach wie vor herum.
00:05:29Das stammt aus der Matrixmultiplikation.
00:05:31Aber was sie da vergleichen, ist Folgendes:
00:05:34Auf der einen Seite eine vollständig vektorisierte, parallelisierte und geteilte Mojo-Implementierung.
00:05:40Auf der anderen Seite eine dreifache Schleife in purem Python.
00:05:44Ja, eine dreifache Schleife.
00:05:45Nicht NumPy, sondern eine verschachtelte Schleife, die auf der Welt niemand wirklich so nutzen würde.
00:05:49Die Behauptung, es sei 35.000-mal schneller, kümmert mich also wenig.
00:05:52Ich wollte konkrete Zahlen von diesem Rechner.
00:05:54Ich nutze einen M4 Pro im Vergleich zu purem Python.
00:05:57Gegenüber purem Python ist es 26,5-mal schneller.
00:06:00Gegenüber NumPy ist es, pro Operation gemessen, fast doppelt so schnell.
00:06:05Nun, 26 ist natürlich nicht 68.000.
00:06:08Aber ein 26-mal höherer Wert ist dennoch beachtlich, da NumPy im Kern bereits auf C basiert.
00:06:14An dem Punkt schlägt man nicht mehr wirklich Python.
00:06:16Man schlägt C durch ein besseres Speicherverhalten.
00:06:19Und genau das ist das Frustrierende an Mojo.
00:06:21Aber die Leistung ist eigentlich nicht der Hauptgrund, warum ich zögern würde, Mojo heute einzusetzen.
00:06:25Ich habe bereits damit herumgespielt.
00:06:27Ich führe es heute hier aus.
00:06:28Der springende Punkt ist die Stabilität.
00:06:30Wie stabil ist das Ganze?
00:06:32Denn Mojo 1.0 enthält 41 Warnungen bezüglich instabiler APIs, einschließlich grundlegender Built-ins wie int, print und len.
00:06:40Sie wurden innerhalb eines sogenannten Stabilitäts-Releases als instabil eingestuft.
00:06:45Und am selben Tag, an dem Mojo verspricht, Ihr Code würde nicht brechen, zerstörte das Entfernen des Schlüsselworts FN etwa 39 Pakete des Ökosystems.
00:06:52Das FN-Schlüsselwort, das eine fundamentale Rolle für die Funktionsweise von Mojo spielte, wurde komplett entfernt.
00:06:58Kein FC-Prozess.
00:06:59Und während der Compiler nun Open Source ist, werden Beiträge dazu noch nicht akzeptiert.
00:07:04Mojo 1.0 ist also stabil, nehme ich an.
00:07:07Aber vielleicht doch nicht so stabil, wie behauptet wird.
00:07:09Was uns zu der einzigen Frage führt, die wirklich zählt.
00:07:12Sollten Sie das nutzen?
00:07:13Wenn Sie GPU-Kernel, CUDA, Triton oder in diesem Bereich schreiben, ist Mojo meiner Meinung nach definitiv ein oder zwei Tage Zeit wert.
00:07:21Eine Sprache für CPU und GPU, und ich habe einen funktionierenden GPU-Kernel auf einem Laptop kompiliert.
00:07:27Es gibt nicht viel anderes, das so etwas leistet.
00:07:29Aber das Ganze hat noch viel Raum zum Wachsen.
00:07:31Ich würde es zum jetzigen Zeitpunkt also keineswegs priorisieren.
00:07:35Vor drei Jahren war das Argument gegen Mojo recht einfach.
00:07:38Coole neue Sprache, aber wer soll das nutzen?
00:07:40Es war eine geschlossene Sprache von einem Startup, das Entwickler aufforderte, alles darauf zu setzen.
00:07:44Heute steht der Compiler unter der Apache 2.0-Lizenz.
00:07:47Die Sprache ist bei Version 1.0.
00:07:48Und dieses Startup ist nun Teil von Qualcomm.
00:07:51Ich bin Josh von BetterStack.
00:07:53Wenn Ihnen solche Programmiertipps und -tricks gefallen, abonnieren Sie den Kanal.
00:07:56Wir sehen uns im nächsten Video.

핵심 요약

Obwohl Mojo als Open-Source-Sprache in Version 1.0 vorliegt und auf dem M4 Pro im Vergleich zu purem Python einen 26,5-mal schnelleren Wert erreicht, leidet die Plattform unter Stabilitätsproblemen und API-Änderungen.

하이라이트

  • Mojo verbindet Python-ähnliche Syntax mit der Leistung von C++ und CUDA.

  • Der Mojo-Compiler wurde am 18. August unter der Apache-2.0-Lizenz veröffentlicht, kurz nach der Qualcomm-Übernahme von Modular.

  • Auf einem M4 Pro erreicht Mojo im Vergleich zu purem Python einen 26,5-mal schnelleren Wert.

  • Die Version 1.0 enthält 41 Warnungen bezüglich instabiler APIs, darunter elementare Built-ins wie int, print und len.

타임라인

Grundkonzept und Leistungsvergleich

  • Mojo verbindet Python-Syntax mit der Ausführungsgeschwindigkeit von C++ und CUDA.
  • Ein direkter Test auf einem lokalen Rechner zeigt Abweichungen in den Prüfsummen durch Compiler-Optimierungen.

Die Programmiersprache Mojo zielt darauf ab, lesbaren Python-Code mit rechenintensiven Operationen über CPUs und GPUs hinweg zu vereinen. Ein direkter Vergleich zwischen Python und Mojo bei While-Schleifen demonstriert Leistungsunterschiede, wobei Mojo mathematische Ausdrücke zu einzelnen Instruktionen zusammenfassen kann.

Open-Source-Status und Qualcomm-Übernahme

  • Ein funktionierender GPU-Kernel lässt sich direkt auf einem MacBook kompilieren.
  • Der Compiler wurde am 18. August unter der Apache-2.0-Lizenz veröffentlicht, kurz nach der Übernahme durch Qualcomm.

Die Entwicklung umfasst die Kompilierung von GPU-Kerneln in derselben Sprache wie normaler Python-Code, angeführt von Chris Lattner. Zeitlich fällt die Freigabe des zuvor proprietären Compilers als Open-Source-Projekt eng mit der Übernahme von Modular durch Qualcomm im Juli zusammen.

Benchmarks und Stabilitätsprobleme

  • Messungen auf einem M4 Pro zeigen eine 26,5-fache Geschwindigkeit im Vergleich zu purem Python.
  • Mojo 1.0 enthält 41 Warnungen bezüglich instabiler APIs und das Entfernen des FN-Schlüsselworts beschädigte mehrere Pakete.

Frühere Behauptungen über extreme Geschwindigkeitsvorteile basieren oft auf Vergleichen mit dreifachen Schleifen in purem Python. Neben echten Leistungszuwächsen gegenüber NumPy stehen jedoch Herausforderungen wie mangelnde Stabilität, zahlreiche API-Warnungen und kurzfristige Syntaxänderungen in Version 1.0.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기