Pythonが今Mojoを実行できるようになった

339日前原文(koaning.io)

概要

Python から Mojoコード を呼び出す方法の紹介
Mojo による関数高速化の実例解説
セットアップ方法 と簡単なサンプルコードの提示
パフォーマンス比較 と現状の課題整理
今後への 期待感 と注意点のまとめ

PythonからMojo関数を呼び出す試行

Chris Lattner が「PythonからMojoコードを呼び出せる」と発言
Python の弱点を補う 高速関数 の導入ニーズ
Mojo はRustよりも学習コストが低い印象

セットアップ手順

uv を利用した簡単なインストール方法
- uv pip install modular --index-url https://dl.modular.com/public/nightly/python/simple/
Mojoファイル （例: mojo_module.mojo）の作成
- Python拡張として関数をエクスポートする構成
PythonObject 型を用いたPythonとの橋渡し

サンプル：階乗計算関数

Mojo側関数 ：引数をint化し、階乗を計算
Python側 ：通常のimportでMojo関数を利用
パフォーマンス測定 ：time.time()で実行速度比較
- 10の階乗
  - Mojo: 3.0e-05秒
  - Python: 5.0e-06秒
- 100の階乗
  - Mojo: 結果が0（オーバーフロー）
  - Python: 正常に大きな値を出力
課題：Mojo側で整数型のオーバーフロー発生
- スタックが初期段階であることを示唆

素数カウント関数による追加検証

Mojo で素数カウント関数を実装
Python ・ NumPy による同等アルゴリズムと比較
- n=20,000の場合の結果
  - Python: 0.45秒
  - NumPy: 0.26秒
  - Mojo: 0.011秒
Mojo の高速性が顕著
アルゴリズム自体は最適化余地あり（参考程度）

現状のまとめと今後

Mojo はPython拡張として有望な選択肢
Rust よりも学習障壁が低い印象
モジュールスタック はまだ発展途上
- 拡張ビルドのサポートも限定的
現時点では本番利用には早い が、将来性に期待
夢の実現 に一歩近づいた感触

まとめ

Mojo によるPython高速化は着実に進展
セットアップも簡単になり、 実験的利用 には十分
現状の制約 （オーバーフロー・サポート体制）に注意
今後の発展に 期待感

Hackerたちの意見

Mojoを応援してるよ。言語が目指してることがすごく好きだし、Nvidia + CUDAじゃないハードウェアでSOTA AIのワークロードを簡単に動かせるようになるのは、いろんな可能性を広げると思う。ただ、彼らがどれだけVCから資金を集めたのか、そしてそれがビジネスモデルにどんな影響を与えるのか、ちょっと不安だな。

└

もし彼らがオープンソースにする計画を実現できたら、少し安心できるかな。応援してるけど、オープンソースになるまでは、彼らのエコシステムに自分の時間を投資する気にはなれないよ。

Mojoについてあまり知らない人のために説明すると、MojoはCUDAなしで超高速なCPU+GPU実行ができるPython風の言語だよ。 https://news.ycombinator.com/item?id=35790367

Chris Lattner（MojoやLLVM、Clang、Swift、MLIRの技術リーダー）が、ちょっと前にポッドキャストに出演して、Mojoの現状や今後について話してたよ。オープンソース化についても触れていて、会社がどこでお金を稼ぐつもりなのかも話してた。 https://www.youtube.com/watch?v=04_gN-C9IAo

└

その動画は制限されてるみたいだけど、公開リンク持ってる？

確かに、Pythonに本当に速い関数を提供できるシンプルなコンパイル言語を探してるから、Nimかな？ https://github.com/yglukhov/nimpy

└

Mojoの本当のポイントは言語そのものじゃなくて、MLIRへの深い根ざしなんだ。これはLLVMがコンパイラに対してやったことを、GPUやMLハードウェアで実現しようとしている試みなんだよ。プロジェクトはクリス・ラトナーが率いていて、彼はLLVMとMLIRを作った人だよ。

Mojoにはあまり惹かれないんだよね。新しい言語に興味があるから、ちょっと偏見があるかもしれないけど、Mojoの大きな売りは既存の言語からできるだけ変えないことだから。それでも、Pythonにこれだけ簡単にインポートできるのはかなり大きなことだと思う。パフォーマンスの問題で行き詰まってるチームには、これがめちゃくちゃ役立つだろうね！

└

その大きな売りは、既存の言語からできるだけ変更を少なくすることだ。これはあまり正しくないよ。MojoはPythonの構文を採用しているけど、内部的には全く違う言語なんだ。Mojoは多くの方向で革新を進めている（例えば、mlir統合、所有権モデル、コンパイル時など）。クリエイターたちは、それに加えて構文で革新する必要を感じていなかったみたい。

事前にコンパイルされた関数を呼び出せるPythonにはあまり興味がないな。動的ライブラリを生成できる言語なら、すでに可能だし。私が興味あるのは、実行時にコンパイルされたプログラムだよ。例えば、完璧なハッシュデータ構造を生成するケースがある。キーワードをリストした設定ファイルがあって、それをもとに完璧なハッシュデータ構造を動的に生成するんだ。キーワードがコンパイル時の値として扱われるから、コンパイル時に生成される感じでね。もしキーワードの数が少なすぎるなら、線形探索にフォールバックする。すべてコンパイル時に動的ディスパッチのコストなしで実行できる。もちろん、numbaのことを言ってるんだけど、ホスト言語がPythonだから呪われてると思う。もしPythonがもっと型が強い言語だったら、全く新しい最適化のスケールが開けるだろうね。

└

Pythonがいくつかのプリコンパイルされた関数を呼び出せることにはあまり興味がないな。これは動的ライブラリを生成するどんな言語でも可能だから。 > 僕が興味があるのは、実行時にコンパイルされたプログラムのことなんだ。具体的には、完璧なハッシュデータ構造を生成する使い道がある。キーワードをリストした設定ファイルがあって、そのキーワードをコンパイル時の値として扱って完璧なハッシュデータ構造を動的に生成する感じだね（実際にそうだから）。君の言ってることを正しく理解できてるか分からないけど、これら二つは繋がってるように思える。もし僕が君がやりたいことをPythonでやるなら、zig build-libを作ってctypesと一緒に使うかな。

└

CPythonがCommon LispやScheme、Racket、Smalltalk、Selfのコンパイルモデルみたいになればいいなと思ってる。残念ながら、周りの競争相手はほとんど無視されてるから、特別なJIT DSLやネイティブ拡張を書くことに苦しむ必要があるんだ。多くの場合、CPythonが唯一の実装だからね。

└

Mojoはすでにそのパラメーターシステムでこれをサポートしてるんじゃない？ https://docs.modular.com/mojo/manual/parameters/ 君が言ってたJittingはMAXグラフAPIでサポートされてるよ: https://docs.modular.com/max/tutorials/build-custom-ops。もうちょっとNumbaみたいにきれいな構文だといいと思うけど、君のアイデアは面白いね。

majoで階乗テストがゼロを返すってことは、任意精度整数演算をやってないってことだね。MojoはPythonのスーパーセットとして好きだった。任意のPythonを実行できて、新しい部分を選んで変更できるようにしたかったんだ。「Pythonicな言語」っていうのは、その目標が捨てられたように聞こえるから、僕にはその価値があまり明確じゃなくなってきた。

└

Mojo側で明示的に'Int'にキャストしてたけど、モジュラーウェブサイトでは特定のビット幅じゃないって言ってるから、驚いてるよ。

└

数日前のModularのDiscordでクリス・ラトナーが言ってたこと: 「そう、その通り。intがマシンの整数のように振る舞うのは、システムのパフォーマンスにとって非常に重要なんだ。'int'の名前空間をそのままにしておくことで、将来的にPythonとの互換性のためにオブジェクトベースのbigintを持つことができる。上でも言われてるように、Pythonとの互換性を持つことはまだ目標だけど、短期的な優先事項ではない。」

└

変更なしのPythonを速くするのは基本的に不可能だよ。

NVidiaがGTC 2025で発表したように、Python JIT DSLに本気を出すことに決めた今、Mojoが研究者たちの間でどれだけの支持を得られるか気になるな。「PythonでCUDAカーネルを書く1001の方法」 https://www.youtube.com/watch?v=_XW6Yu6VBQE 「CUDA Python開発者のツールボックス」 https://www.nvidia.com/en-us/on-demand/session/gtc25-S72448/ 「加速されたPython：コミュニティとエコシステム」 https://www.youtube.com/watch?v=6IcvKPfNXUw 「CUTLASS 4.0でのPythonによるTensor Coreプログラミング」 https://www.linkedin.com/posts/nvidia-ai_python-cutlass-acti... それに、Juliaもあるね。Pythonコミュニティの外にいる多くの人が移行していて、ツールも成熟しているし、Windowsサポートも一流だから、何らかの理由でWindowsの仕事用ノートパソコンを持っている研究者にはいいかも。 https://info.juliahub.com/industries/case-studies Mojoはプログラミング言語としては面白そうだけど、市場での採用に関してはSwiftやSwift for TensorFlowのようになるかどうか、まだ判断がつかないね。

└

DSLの制限とPythonの魅力があって、Pythonの互換性が上がれば実用的なスイートスポットになると思う。

└

Mojoは、NVIDIAだけじゃなくて、どんなハードウェアでも最大のパフォーマンスを引き出す方法として売り出されてるんだよね。いろんな理由で異なるハードウェアブランドでコードを動かしたい人には魅力的かも。

└

Mojo（とModularの全スタック）は、今のところトレーニングや研究よりも推論に興味がある人向けに完全に焦点を当ててる感じ。だから、低遅延・高スループットの推論システムを構築したい人をターゲットにしてるんだよね。あと、他の人も指摘してたけど、NVIDIAだけじゃなくて、いろんなハードウェアを対象にしてる。

└

Juliaが大好きで、ぜひ成功してほしい！でも、大きな企業の支援がないのが辛いよね。

いや、PythonはMojoを動かせないよ。Cythonや他の何百ものプロジェクトと同じように、MojoはC拡張を作って、それを読み込むんだ。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++の方が簡単だよ。

Python用のコンパイルされた拡張を書くときに注目してるのは、拡張の速度じゃなくて、呼び出しのオーバーヘッドと、Pythonからコンパイルされたもの、コンパイルされたものからPythonへのオブジェクト移動のオーバーヘッドなんだ。大きなオブジェクト用のゼロコピーインターフェースはあるの？その場合、オブジェクトのライフタイムはどうなるの？特にMLで使うなら、大きな行列を運ぶ必要があるし。GILの問題もあるし、Mojoはそれをどう処理してるのか気になるな。

ハクソク