PythonでMojoが使えるように！
引用元：https://news.ycombinator.com/item?id=44331316
NVidiaがGTC 2025でPython JIT DSLsに本腰入れるって発表したけど、研究者にMojoがどれだけ受け入れられるか気になるな。”1001 Ways to Write CUDA Kernels in Python”（https://www.youtube.com/watch?v=_XW6Yu6VBQE）とか”The CUDA Python Developer’s Toolbox”（https://www.nvidia.com/en-us/on-demand/session/gtc25-S72448/）とか、”Accelerated Python: The Community and Ecosystem”（https://www.youtube.com/watch?v=6IcvKPfNXUw）とか”Tensor Core Programming in Python with CUTLASS 4.0”（https://www.linkedin.com/posts/nvidia-ai_python-cutlass-acti…）みたいな動きもあるし、Pythonコミュニティ以外ではツールも成熟してWindowsサポートも手厚いJulia（https://info.juliahub.com/industries/case-studies）に移った研究者も多いらしい。Mojoは言語オタク的には面白そうだけど、競合がいる中で市場に普及するかはSwiftとかSwift for Tensorflowみたいになるかまだ分からないね。
Mojo（とModularのスタック全部）は、今のところ学習とか研究より推論（inference）に完全にフォーカスしてる感じかな。低遅延・高スループットな推論システムを作りたい人向けってことだね。あと、別の人が指摘してたけど、NVidiaだけじゃなく色んなハードウェアもターゲットにしてるよ。
PyO3を使えばいいんじゃない？CythonとかC++ライブラリよりずっとインターフェースが綺麗だよ。Mojoの一番のメリットは、Pythonにできるだけ近いGILフリーな構文みたいだけどね。
RustでのGPUプログラミングはそんなに良くないんだよね。Mojoだとそれが言語のほぼ全ての要点って感じ。CPUだけ使うなら、PyO3は良い選択肢だよ。
Huggingface製のCandleはどうかな？少なくとも基本的なことはできるし、CPUとGPU両方で動く例もたくさんあるよ。深くはまだ見てないけど、ちょっと触った感じでは埋め込み（embedding）用には十分だったな。
Mojoの大きな付加価値は、もう特定のGPUアーキテクチャでしか動かないGPUコードを書かなくていいことだと思うんだ。LLVMがCPUコードを複数のCPUアーキテクチャに対応させるみたいに、MLIR＼MojoはGPUコードをいろんなベンダーのGPUに対応させられるんだよ。新しいGPUアーキテクチャ向けのバックエンドを書くには多少努力が必要で、LattnerはH100のサポートに2ヶ月くらいかかったって話してたよ。
そうだね、GPUだけじゃなくてアクセラレータ全般だよ。Mojoは、変な特殊なハードウェアも（移植性が重要なら）ターゲットにできるようになるだろうね。
今のところはCPUと、そのうちAMDって感じに見えるかな。YouTubeのセッションとか、NVidiaからの解放についてのブログ記事を見てた感じだとね。あと、WindowsのCPUはWSLを使わないとダメみたいだよ。
サーバーグレードもコンシューマー向けもかなり幅広いGPUをサポートしてるよ。ちょっと分かりにくいけど、一番信頼できるサポートGPUのリストはMojo infoのドキュメントにあるよ。https://docs.modular.com/mojo/stdlib/gpu/host/info/
もうすでにGPUコード、カーネル、そしてモデル全体が、データセンターのAMD GPUで同じコード、同じプログラミングモデル、そして同じ言語構造を使って動かせるようになってるよ。
うん、最近のNVIDIAとAMDの一般向けGPUはサポートされてるよ！詳しくはここ見てね: https://docs.modular.com/max/faq/
よくわかんないけど、Modularは主に企業向けみたいね。でも今のPR見ると、みんな自分でNVIDIAとかAMDの個人向けGPUに対応させてるよ。低レベルでちょっとコード足せばできちゃうから簡単なんだって。iGPUとかApple GPUsはまだだけど、どうなるか興味あるね。
MojoってNVIDIAだけじゃなく、どんなハードウェアでも最高の性能を出せるって売り込みなんだよね。だから色んなメーカーのハードでコード動かしたい人にはいいかもね。
確かに目標はそうだけど、今はまだだよ。Windowsでもそのまま動かないし。Juliaとか他のPython DSL JITsみたいに、既に色んなハードで使えるものもあるしね。Mojoもきっとできるようになるだろうけど、主流になるには十分速く達成できるかどうかって話だよね。
Mojo GPU kernelsは今、NvidiaとAMD両方のGPUで動かせるよ。
JuliaはNvidia、AMD、Intel、Apple向けのGPUコンパイラがあるし、KernelAbstractions.jlを使えばCPU含め全部で動くカーネルが書けるんだよ！
確か特定のモデルだけだった気がするな。
LLVMが全ての新しいCPUアーキテクチャに自動対応しないのと同じで、Mojo/MLIRも新しいハード全部に自動対応するわけじゃないんだ。でも、LLVMにRISC-Vのバックエンドができたら、そこに乗ってる言語やソフトはRISC-Vで動くようになるでしょ。それと同じ。新しいGPU/TPU向けにコード全部書き直すんじゃなくて、新しいバックエンドだけ作ればいいんだよ。
いやいや、モデル以外でも今日のMojoコードはNvidiaとAMD両方のGPUで動くよ。AIに特化したコードじゃなくても大丈夫。
GPUのモデルのこと言ってるんだと思うよ、LLMのモデルじゃなくてね。
DSLsの限界とPythonの魅力考えると、もしPython互換性を十分高められたら、これは実用的なちょうどいいところだと思うよ。
Julia大好きでもっと広まってほしいんだけど、大きな企業の後ろ盾がないのが辛いね。
企業の後ろ盾の話だけど、結構あるよ。だからHNerが見落としがちなこれを指摘したんだ。
https://info.juliahub.com/industries/case-studies
確かにJuliaを使ってる企業はたくさんあるけど、GoogleがGoを、OracleがJavaを、MozillaがRustを後押ししてるみたいには、どこも支援してないって話だよ。
PythonやRubyだって、初期にbig nameの後ろ盾がなくてもそんなに困らなかったでしょ。MITとか、さっきのリストに載ってた企業も十分関連性あると思うよ、FAANGじゃなくてもいいんだし。
MojoはnVidiaとAMDで動くよ。競合はTritonであって、CUDAとかJuliaじゃないんだ。
JuliaはNvidia、AMD、Intel、AppleのGPUsで動くよ。
Chris Lattner（Mojo, LLVM, Clang, Swift, MLIRの技術リーダー）が1週間くらい前にポッドキャストに出て、Mojoの現状や将来について話してたよ。Mojoのオープンソース化や、会社がどうやって収益を上げるかについても話したみたい。
https://www.youtube.com/watch?v=04_gN-C9IAo
Chris Lattnerは先週r/programminglanguagesにも現れて、それについて少し話してたよ。
https://www.reddit.com/r/ProgrammingLanguages/comments/1lfz9…
JuliaじゃなくてMojo作った理由、弱くなったね。FAQに「Juliaは素晴らしいけどMojoは全然違う。Python開発者が新しい文法覚える必要ないPythonファーストだよ」って書いてあったのに。
今は「Pythonスーパーセットって言いすぎた。今日のMojoができることに集中する。CPU/GPUを速くするのに最高な言語だよ」って言ってるし。笑えるわ。
https://docs.modular.com/mojo/faq/#why-not-make-julia-better
もっとコメントを表示（1）
もっと面白いのはこれだよ。
TensorFlowのSwiftのドキュメントに、Juliaは「オープンでアクティブな素晴らしい言語。機械学習技術に投資してて、Python APIとの連携も良い」って書いてあるんだ。
https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF…
うん、それは本当にもったいない機会だったと思う。8年前に協力してたら、今の状況より良い結果になってた可能性が高いよね。
「既存言語Yの文法と意味論を全部サポートしつつ、その上に何か加える」って始めて、「結局Yに漠然と似てるだけの言語になる」プロジェクトの割合は、ほぼ100%と区別つかないくらい多いよね。
生存者バイアスはあるだろうけど、C++とかTypescript、Ocamlみたいに互換性をかなり保ってうまくいった例もあるんじゃないかな。最初に思いつくのはね。
本当の理由は、Chris LattnerがJuliaで仕事したくなかったからだと思うんだ。彼はこういうことに関してきっと強い意見を持ってるし、自分のプロジェクトで自由にクリエイティブな権限を持ちたいんじゃないかな。
もう十分有名な人なら、他の人と関わるより、自分で立ち上げて全部自分で決めちゃう方がいいんじゃない？
Modularのビデオをいくつか見てると、Chris Lattnerは今は監督役で、実際にMojoやMaxのツールを進めてるのは他の人たちに見えるんだけど。プレゼンの形式からの誤解かもしれないけどね。
彼はMojoでたくさん仕事してるよ。ほとんど週末だけどね。この数ヶ月で、文字列、コレクションリテラル、依存型、参照キャプチャ、内包表記とか、色々な素敵な言語機能に取り組んでるんだ。
それにJuliaはWindowsでも動くし、この10年でたくさんの問題が解決されたし、多くの人が投資してる。単一企業の製品じゃないんだ。
もちろん主流言語の多くは一企業から始まったけど、それって特定のプラットフォームにアクセスするための「門番」が必要だったからだろ？
だからMaxとその製品としての価値以外で、誰がMojoコードを書こうと急ぐかって話だよね。
MojoはPythonみたいな書き方で、C++/CUDAを置き換えてAIのインフラ問題を解決しようとしてるんだと思うよ。頭の負担を減らすためにPython構文なんだろうね。Juliaがこれに向いてるかは疑問だなあ。Juliaはシステムプログラミング言語として売られてないし、動的型付けでGCやJITがあるのにシステム言語になれるとは思えないんだ。
研究とか学習で使われる高水準の動的コード分野でJuliaがPythonを置き換えられるか？それはあるかもね。でも、CUDA/ROCm/C++とかを置き換えるのはすごく難しいと思うよ。
昔のXerox PARCとかTexas InstrumentsのLisp MachinesやGeneraは、価格で負けたけど、システムとして有能だって証明したよね。DylanはNewtonのシステム言語になるはずだったけど、C++チームに負けちゃった（AppleにはNewton OS開発チームが２つあったんだ）。ユーザー空間はNewtonScriptだったし、プロジェクト中止までにはJITも載る予定だったみたいだね。Objective-CはCとの共通部分以外は動的型付けだけど、NeXTSTEPのドライバー書くのに使われたりしたよ。
JuliaがCUDA/ROCm/C++に対抗できるか、どれくらいチャンスがあるかは分からないなあ。特に最近はGPU業界がPythonに力を入れてて、公開初日からBindingsやJIT DSLsでPythonでも使えるようにしてるから、MojoはJulia以上にチャンスがないかもね。Juliaにはもうエコシステムがあって、MITとも繋がってる科学コミュニティで地位を築いてる。Pythonは王者だし、CUDA/ROCm/C++書いてる人のほとんどがPythonも使ってるよ。FortranとかC、C++が苦手な人が、PythonのJIT DSLs/bindingsとかJuliaじゃなくて、なんでMojoに手を出すんだろうね？
JuliaとかPythonがCUDAみたいな基盤プラットフォームにDSLとかBindingsを作るのって、それを置き換えてるんじゃなくて、既存のプラットフォームの上にさらに層を重ねてるだけか、研究用のプロトタイプ環境を作ってるだけだよ。問題はJuliaがCUDAとインターフェースできるかじゃなくて、JuliaがC++/CUDA/ROCmを（できればいろんなGPUベンダーで動くように）エンドツーエンドで置き換えられるかってことなんだ。それができないなら、JuliaとMojoの目標は全く違うし、完全に別々のユースケースをターゲットにしてるから、比較にならないんだよ。
Juliaは単にCUDAへのBindingsがあるだけじゃないんだ。Juliaのネイティブコードは.ptxカーネルにコンパイルできるんだよ https://cuda.juliagpu.org/stable/development/kernel/。この同じコードで、AMD GPU、Intel GPU、そしてMetal用のカーネルも生成できるんだ。
例えば、俺たちはユーザー関数を組み込んだカーネルをオンデマンドで生成するソフトウェアを開発して、これら4つのシステム全部で動かしたんだ。特定の非線形システムでは、ただのCUDA bindingsよりもずっと高速だってことを示したよ（https://www.sciencedirect.com/science/article/abs/pii/S00457…）。
Juliaはみんなが思ってるよりずっと静的言語に近いんだ。実際、fixed world-ageの中では、JuliaのJITから見ると静的言語と同じだよ。俺たちのJITも他のJITとはちょっと違ってて、Tracing JITよりは伝統的なコンパイラに近い作りだから、“Just Ahead Of Time”コンパイラって呼ぶこともあるんだ。
GPUコンパイルもかなりすごいんだよ。Juliaの関数はNvidia、AMD、Intel、AppleのGPUに、それぞれのGPUコンパイラパッケージを通してコンパイルできるし、KernelAbstractions.jlを使えばGPUベンダーに依存しないコードも書けるんだ。v1.12では、（実験的な）完全AOTコンパイラも言語に組み込まれる予定で、実行ファイルとかdylibを出力できるようになるよ。
俺が普段使ってるツールだと、動画は地域ロックされてないみたいだよ。https://polsy.org.uk/stuff/ytrestrict.cgi
ごめん、そのリンクは普通に見れるんだけど。このPodcastのエピソードリストのリンクの方が役に立つかも。https://www.youtube.com/@LatentSpacePod
それはLatent Space podcastだよ。6月13日に出たやつ。AIの情報を追うのに結構いいPodcastだよ。共同ホストの一人、SwyxはここHNでも活動してる人だよ。
factorialのテストでゼロになるのは、任意精度整数演算をやってないってことだよね？
MojoはPythonのsupersetだって聞いてて、普通のPythonコードも動かせて、必要なところだけ新しい機能を使えるようになるのを期待してたんだ。
でも、「pythonic language」って呼ばれるってことは、その目標はもうないみたいで、そうなるとあんまり魅力を感じないな。
Pythonのsupersetって考え方はもう捨てちゃったのかな？
公開されたばかりの頃に少し追ってたんだけど、その時は”心配しないで、すぐに本物のPython supersetになりますよ”って言ってたんだよね。
その時一番なかったのがクラスのサポートだったんだけど、数年経っても同じPythonの機能がないままで、彼ら独自の言語機能がたくさん追加されたように見えるね。
捨てたっていうより、延期したって感じかな。
あれはすごく野心的な目標だったし、現実的に考えると今はPythonからインスピレーションを受けて、より強力な統合フックを持つ方が良いんだ。（ぶっちゃけ、俺Modularで働いてるんだ）
今のこの言語が何を目指してるか、もっと正確に伝えるために”superset of Python”って言葉を使うのはやめたんだよ。
deferred（延期）ってことは、いつかは来るかもしれないって意味だけど、本当に来るかはわからないね。
俺は多分来ない方に賭けるな。
Pythonのsupersetであることと、速いことって、根本的に両立が難しいんだ。
Pythonの動的な機能を使わない限りは最高のパフォーマンスが出るsuperset、ってのはもしかしたら可能かもしれない。
でも、動的な機能を使ったり、そういう機能に依存するコードを使ったりした時に、急にパフォーマンスがガタ落ちする隠れた落とし穴があるのは、ユーザーがイライラする原因になると思うな。
Pythonの動的な機能って、SmalltalkとかSelfとかCommon Lispの動的な機能と何も変わらないんだ。
でも、Pythonコミュニティで動的コンパイラが普及しなかったせいで、みんな違うものだって思い込まされちゃってるんだよね。
数日前のModularのDiscordでのChris Lattnerからの投稿だよ。
”ええ、その通りです。intがマシン整数のように振る舞うことは、システムパフォーマンスにとって非常に重要です。
”int”名前空間をそのままにしておくことで、将来的にPythonとの互換性のためにオブジェクトベースのbigintを持てるようになります。
他の人も言ってるように、時間をかければPythonと互換性を持たせることは依然として目標ですが、短期的な優先事項ではありません。”
全く変更しないPythonコードを速くするのは、基本的に無理だよね。
それはそうなんだけどさ、変更しないPythonコードは普通のPythonの速度でサポートして、それに加えて、もっと高速に実行できる言語拡張を持つことはできるでしょ。
Mojo側でIntにキャストしてるのに、Modularのサイトじゃbit幅は決まってないって書いてあるんだって。びっくりだね。
bit幅が決まってないってのはね、ターゲットのアーキテクチャが対応してる一番大きい整数型（つまり32bitか64bit）になるってことだよ。
好き嫌いは主観的？へー、すごい発見だね。Pythonはさ、関数型とか合成とか、みんなが良いっていう方向と逆行するような、いい加減な言語なんだよ。デカいIT企業は大事なシステムでPythonを使わないように、いっぱいお金かけてるんだぜ。
Mojoをまだ知らない人のために説明しとくね。MojoはPythonみたいな言語で、CUDAなしでCPUもGPUもめっちゃ速く動かせるんだよ。詳しくはここを見てみて。https://news.ycombinator.com/item?id=35790367
もっとコメントを表示（2）
超高速の技術がやっとPythonにも来るなんて、嬉しいね！あの開発チーム、ここ10年くらいRustで忙しかったみたいだけど、ようやくPythonで超速いものを作り始めたんだね。
PyPyみたいなプロジェクトにもっとみんなが目を向けてたら、Mojoみたいに超高速じゃなくても、すでに高速にはできたはずなのにね。
Mojo、マジで応援してるよ。この言語が目指してるとこ、すごく好きだね。Nvidia+CUDA以外のハードで最新のAIを動かしやすくなるのは、色んな道が開けると思う。ただ、VCからどれだけ資金集めたのかとか、それが将来のビジネスにどう響くか、ちょっと心配もあるな。
もし彼らがオープンソースにするって計画をちゃんと実行できたら、ひとまず安心するかな。俺も応援してるけど、オープンソースになるまでは、正直自分の時間をMojoのエコシステムに注ぎ込む気にはなれないんだ。
もうApache 2.0ライセンスでコード出したみたいだね。全部がオープンソースってわけじゃないけど、コアな部分はオープンソースっぽいよ。
コンパイラはオープンソースじゃないんだって。出したのはstdlibのコードだけだよ。
いや、PythonがMojoを動かすんじゃなくて、CythonみたいにC拡張を作って読み込む感じだよ。
始め方見るとさ、インストールとかめっちゃ大変そうなんだよね。URL見てみてよ！https://docs.modular.com/mojo/manual/get-started/
curl -fsSL https://pixi.sh/install.sh | sh
pixi init life ＼
-c https://conda.modular.com/max-nightly/ -c conda-forge ＼
&& cd life
なんかもう、「いいや、C++の方が楽だわ」って思っちゃったw。
大きな違いはね、MojoとPythonの連携部分がコンパイルとか読み込みの面倒を見てくれるってこと。Pythonに近い感じで、必要な時にハードウェアを高速化できて、プラットフォームごとにC++コードをビルドしなくていいのが目標なんだ。Modularの社員だけど、GPUプログラミング初めての人からも「Mojo使いやすい！」って好評だったよ。C++はすごいけど、学習曲線が急なんだよね。GPUとかHPCをもっと簡単にできる余地はたくさんあって、TritonやJuliaみたいなのもその辺を攻めてる。デバイス固有のコードを隠蔽するのが大事なんだ。昔HPC C++プログラマーだったけど、デバイスごとに再コンパイルするのがマジで大変だった（cmakeとか悪夢w）。Mojoはそういうプログラミング体験を改善する仕組みがたくさんあるよ。
記事の例だとC++拡張よりずっとビルドも使うのも簡単そうだったけどな。このコメント（32286）からだと、結局何が気に入らないのかよくわかんなかったよ。
＞ C++ is easier.って言ってるけど、その意見にみんなが賛成するとは思えないな〜。
Pythonからコンパイル済みの関数呼び出せるって言われても、そこまで惹かれないな。それってどの言語でもできるじゃん？俺が興味あるのは実行時コンパイルができるプログラムなんだ。例えば、コンフィグファイルのキーワードリストから、そのキーワードをコンパイル時の値みたいに扱って完璧なハッシュ構造を動的に生成するとか。キーワードが少なければ線形探索にフォールバックするとか。動的ディスパッチのコストなしで、コンパイル時に全部やっちゃうの。もちろん、これってnumbaの話なんだけどね。ただ、ホスト言語がPythonなのが辛いと思うんだ。Pythonがもっと強く型付けされてたら、最適化のレベルが全然違っただろうな〜。
CPythonがCommon LispとかSchemeとかRaket、Smalltalk、Selfみたいなコンパイルモデルだったらいいのにな〜って想像しちゃう。残念ながら、そういうニッチな候補はほとんど無視されちゃってるから、JIT DSLを特別に使ったり、ネイティブ拡張を書いたりする必要があるんだよね。多くの場合、CPythonしか使えないのが現状だからさ。
Mojoってさ、そのパラメータシステムで既にこういうのサポートしてない？https://docs.modular.com/mojo/manual/parameters/
君が言ってたJITはMAX graph APIでサポートされてるよ。https://docs.modular.com/max/tutorials/build-custom-ops
numbaみたいにもっと良い構文だといいけどね。君のアイデア、面白いと思うよ。
＞ Pythonからコンパイル済みの関数呼び出せるって言われても…
＞ 俺が興味あるのは実行時コンパイルができるプログラムなんだ…
君が言ってること、ちゃんと理解できてるか分からないけど、この二つって繋がってる気がするんだ。Pythonで君がやりたいことをやるなら、zigでライブラリ作ってctypesで使うかな。
Zigってさ、実行時の設定でプログラム全体を自己再コンパイルできるの？ 設定次第でプログラムをnoopにしたり、最適なハッシュアルゴリズムを使ったりさ。普通のシステム言語じゃ無理だと思うんだけど。
Python用のコンパイル拡張書くとき、拡張自体の速度よりPythonとの間でオブジェクトやり取りするオーバーヘッドが気になるんだよね。巨大な行列とかゼロコピーできる？ オブジェクトの寿命は？ GILは？ Mojoがどう対応してるか知りたいな。
知る限りだと、Numpy配列とかTorchテンソルみたいなオブジェクトにはゼロコピーインターフェースがあるよ。Mojo内でその場で操作できるらしい。
Mojoにはいまいちピンと来てなかったんだけど、新しい言語探してる身としては既存言語からの変更が少ないって売りがなんか物足りないんだよね。でもさ、Pythonにこんな簡単に取り込めるなら、パフォーマンスで困ってるチームには超便利だろうね！
＞既存言語からの変更が少ないって売り＜は違うと思うな。構文はPythonに似てるけど、中身は全然別物だよ。MLIR統合とか所有権モデルとかcomptimeとか、Mojoは色んな方向で革新的なんだ。構文まで変える必要はなかったってことじゃない？
うん、ごめんね。”売りの一部”とか”セールスポイントの一つ”って言うべきだったかも。Mojoの野心的な目標を軽んじるつもりはなかったんだ。でも、Pythonは複雑だし、そのスーパーセットだとMojoも複雑になっちゃうから、構文はもう少し大胆でも良かったのになーって今でも思ってるよ。
＞Pythonに関数提供できるシンプルなコンパイル言語を探してる＜なら、Nimはどう？ これ使えるよ → https://github.com/yglukhov/nimpy
Mojoの本当の要は言語そのものじゃなくて、MLIRとの深い連携なんだよ。LLVMをコンパイラでやったことを、GPUやMLハードウェアでやろうとしてる試みなんだ。LLVMとMLIRの生みの親であるChris Lattnerがこのプロジェクトを率いてるんだから。
記事によると”PythonがMojoコードを呼べるようになった”って書いてあるね。これって、Cでバインディング作るのと何が違うの？って思うんだけど。Pythonからコンパイル言語に徐々に移行しやすくなるって点では同じだよね。PythonからMojoへの移植は、Cへの移植よりコピペで済むから楽だろうってのがMojoの強みかな。
へえ、PythonModuleBuilderを使えばC言語挟まずにPythonから呼び出せる”.so”作れるんだ。テストケース見ると、素数カウントみたいな単純なループで純粋Pythonの0.446秒が0.011秒になってて、めちゃくちゃ速いね！Pythonの壁にぶつかった時に手軽に速度アップできるね。ただ、型に制限があって、factorial(100)は固定幅intでオーバーフローしちゃうみたいで、bigintの代替はないんだね。配列の扱いがどう進化するかは注目だね。それがMojoが一部の計算重い分野に留まるか、もっと広く使われるかの分かれ目になると思う。まだ初期段階だけど、”使える”ってのが重要だね。
