世界を動かす技術を、日本語で。

MLには新しいプログラミング言語が必要 – クリス・ラトナーとのインタビュー

概要

  • Chris Lattnerが LLVMやSwiftの開発者 としての経歴を語るエピソード
  • Mojo言語 開発の背景と、GPU活用の生産性向上に挑む意図
  • ハードウェアの詳細 を理解しやすく・共有しやすくする型安全なメタプログラミングの重要性
  • 計算内容と ハードウェアプラットフォーム 特化の両立を目指す設計思想
  • エコシステムの自由化と 一社独占の回避 に向けた課題意識

機械学習に新しいプログラミング言語が必要な理由

  • Chris Lattnerは LLVMやSwift など、基幹技術の開発者
  • 新たに Mojo の開発に取り組み、現代GPUの性能を 最大限引き出す 生産的な方法を模索
  • 従来の言語では、 高性能カーネル の記述と使いやすさの両立が困難
  • ハードウェアの詳細を 意識的に扱わせつつ、作業量を抑え、共有もしやすくする 型安全なメタプログラミング を導入
  • 計算内容やハードウェアごとの 最適化・特化 を柔軟に実現する設計
  • AI計算資源の民主化、一社独占の回避を目指す
  • MojoやMLIR、Modular AIなど 関連プロジェクト の紹介

Chris Lattnerのキャリアと思想

  • 幼少期から コンピュータの仕組みに興味 を持ち、BASICやPC雑誌でプログラミングを学習
  • ゲーム開発や ハードウェア性能の追求 がきっかけで、システムとパフォーマンスに関心
  • 大学で コンパイラ分野 に出会い、LLVMを開発
  • 大規模システム としてのコンパイラの面白さ、ソフトウェア工学的な積み上げ体験
  • LLVM以降、C++やSwiftなど低レイヤから高レイヤまで幅広く設計・実装
  • ハードウェアとソフトウェアの 境界領域 での経験と知見が強み

Swift誕生の背景と設計思想

  • LLVMの成熟後、C++サポートを Clang で実現し、自己コンパイルも可能に
  • C++の設計に限界を感じ、「より良い言語を作りたい」と Swift を開発
  • Swiftは 夜間・週末の個人プロジェクト として開始、既存言語の欠点を補う狙い
  • パターンマッチング や代数的データ型など、実用的な機能を重視
  • 学術的な型理論よりも、 現場での使いやすさ・実用性 を優先した設計

パターンマッチングの重要性

  • MLやOCaml、Haskell など、関数型言語で普及していたパターンマッチング
  • 2010年前後の主流言語( C++、C#、Java、JavaScript)では未対応
  • 実用性・表現力 の高さから、Swiftでも積極的に採用
  • 学術的な理論よりも、 開発者目線での便利さ を重視する姿勢

新しい言語設計と今後の展望

  • ハードウェアの進化に伴い、 従来の抽象化 では性能を引き出しきれない課題
  • 型安全なメタプログラミング で、詳細制御と生産性の両立を図る
  • Mojo をはじめ、AI・機械学習向けの 新しいエコシステム 構築への挑戦
  • 開発者が ハードウェアの違いを意識しつつ も、再利用性・共有性を損なわない設計
  • 一社独占 を防ぎ、誰もがAI計算資源にアクセスできる未来を目指す

Hackerたちの意見

そうだね、でもMojoのライセンスは全然ダメだね。

わぁ、ちょっと見てみたけど、商業目的でCPUとNvidiaを分けて、他の「アクセラレーター」(TPUやAMDみたいな)とは別にしてるみたい。 他のアクセラレーターにはライセンスのために連絡しないといけないんだって。 https://www.modular.com/blog/a-new-simpler-license-for-max-a...

私の素朴な考えでは、非営利団体ではなく単一の企業によって管理されている言語は、スタート地点にも立てないと思う。Javaのライセンス変更の時に、どれだけの企業が反応したか見てみて。Pythonの代わりにMojoのような言語にビジネスを基づけるのは、バカか、私には理解できないほど賢い人だけだと思う。

Mojoがやってることって、Juliaにはできないことなの? Juliaはエコシステムに制約があるのは分かるけど(Pythonとはうまく連携できるし)、Mojoがどこが優れてるのかはよく分からないな。

Mojoはかなり低レベルに見えるし、コントロールの度合いも高いね。それに、もっと堅牢な感じがする。Juliaはセマンティクスやパフォーマンスが不安定で、Mojoが目指すような基盤ソフトウェアには向いてないと思う。

特に、JuliaにはJuliaGPUやReactantみたいなユーザーフレンドリーで堅牢なGPU機能があるからね。他にも一般的なJuliaコードをGPUに変換するオプションがたくさんあるし。 1: https://enzymead.github.io/Reactant.jl/dev/ 2: https://enzymead.github.io/Reactant.jl/dev/

Pythonとの相互運用性はちょっと良さそうだね。でも一方で、PythonCall.jl(JuliaからPythonを呼び出せるやつ)はかなり良くて安定してる。Juliaには結構いいMLフレームワーク(Lux.jlやFlux.jl)があるし、Mojoに同じように使えるネイティブなMLフレームワークがあるかは分からないな。

Mojoってカーネルを書くために作られたんじゃないの?記事の冒頭にも書いてあるじゃん。> 最先端のカーネルを書くために。JuliaとPythonは、高水準言語で、カーネルが存在する他の言語を呼び出すんだよね。

[0] https://danluu.com/julialang/

MojoがJuliaにはできないことって何か知ってる?AoTコンパイルのファーストクラスサポートだよ。https://docs.modular.com/mojo/cli/build そう、Juliaにも実行可能ファイルを作るオプションはいくつかあるけど、なんか後付け感があるよね。

  • 任意のJuliaコードをネイティブスタンドアロンバイナリ(rust/C++風)にコンパイルすること、そのすべての影響を伴って。

JuliaでPythonモジュールを作ろうと調べたけど、今のところあんまりサポートされてないみたい。対して、Mojoではそれがコア機能なんだよね。

Hacker Newsで議論の続きを見る