（作成中）AI開発向けプログラミング言語Mojo 🔥 まとめ

Mojo 🔥: Programming language for all of AI

Mojoの概要

• プログラミング言語：Mojoは、研究と実用の間のギャップを埋める新しいプログラミング言語です。
• Python構文の利点：Pythonの構文とシステムプログラミング、メタプログラミングの長所を組み合わせています。
• ポータブルなコード：C言語よりも速いポータブルコードを記述できます。
• Pythonエコシステムとの連携：Pythonエコシステムとのシームレスな相互運用性を備えています。

Mojo🔥開発の理由

• 新言語の開発の意図なし：最初は新しいプログラミング言語を作る意図はありませんでした。
• ML/AIインフラの統合：世界のML/AIインフラを統一するプラットフォームを構築する中で、スタック全体のプログラミングが複雑すぎることに気づきました。
• 手作業でのMLIR記述：多くのMLIRを手作業で書いていて楽しくありませんでした。MLIR
• 革新的なプログラミングモデルの必要性：AI分野に広く存在するアクセラレーターやその他の異種システムをターゲットにできる革新的でスケーラブルなプログラミングモデルが求められました。
• 強力なコンパイル時メタプログラミング：これには、強力なコンパイル時メタプログラミング、適応型コンパイル手法の統合、コンパイルフロー全体のキャッシングなど、既存の言語ではサポートされていない機能が必要でした。
• ホストCPUの重要性：アクセラレーターは重要ですが、しばしば見過ごされがちな「アクセラレーター」の一つがホストCPUです。現在のCPUにはテンソルコアのようなAI加速ユニットが多くありますが、データのロードや前処理・後処理、外部システムとの統合など、特殊なアクセラレーターが対応しない操作の「フォールバック」としても機能します。
• 一つの言語での解決：適用されるAIシステムはこれらの問題すべてに対応する必要があり、一つの言語でこれを実現する理由はないと判断し、Mojoが誕生しました。

次世代コンパイラ技術のための言語

• AIコンピュートの課題解決に向けて：既存の言語ではAIコンピュートの課題を解決できないと気づいたため、プログラミング言語の設計と実装について根本的な再考を始めました。
• 従来のコンパイラ技術の不適合：多様なアクセラレーターを高性能でサポートする必要があるため、LLVMやGCCのような伝統的なコンパイラ技術は適しておらず、それに基づく言語やツールも不十分でした。
• 既存技術の限界：これらのコンパイラ技術は数十年前に設計され、現代のチップアーキテクチャを完全にサポートすることができません。
• MLIRの採用：現在、特化された機械学習アクセラレーターの標準技術はMLIR（Googleで始まり、そのリーダーがModularに移動した新しいオープンソースのコンパイラインフラストラクチャ）です。MLIR
• MLIRの強み：MLIRの強みは、AI ASIC、量子コンピューティングシステム、FPGA、カスタムシリコンなど、従来のCPUやGPUではない特殊なドメイン向けのドメイン固有コンパイラを構築する能力にあります。MLIR
• Mojoの独自性：Modularで次世代AIプラットフォームを構築する目標のもと、MLIRを一部のインフラストラクチャに既に使用していましたが、スタック全体でMLIRの可能性を完全に解放できるプログラミング言語がありませんでした。MojoはMLIRに特化して設計された最初の主要な言語であり、AIワークロードのシステムレベルのコードを書く際に特に強力です。

Pythonファミリーのメンバー：

• コンパイラ内部とアクセラレータのサポート：Mojoの主な目標は、コンパイラの内部構造の革新と、現在および新興のアクセラレータのサポートです。
• 言語構文やコミュニティの革新は不要：言語構文やコミュニティでの革新は不要と見なし、広く使用され愛されているPythonエコシステムを採用しました。
• Mojo言語の野心的な目標：Pythonエコシステムとの完全な互換性、予測可能な低レベルのパフォーマンスとコントロール、そしてアクセラレータへのコードの部分展開が可能であることを目指しています。
• ソフトウェアエコシステムの分断を避ける：Python 2から3への移行のような痛みをPythonユーザーにもたらしたくないという考えです。
• 既存の基盤からの発展：Mojoは新しいコードベースですが、概念的にはゼロから始めているわけではありません。Pythonを採用することで、設計努力が大幅に簡素化され、構文のほとんどがすでに指定されています。
• Mojoのコンパイルモデルとシステムプログラミング機能：Mojoのコンパイルモデルとシステムプログラミング機能の構築に努力を集中できます。
• 他の言語からの教訓：Rust、Swift、Julia、Zig、Nimなどの他の言語からの教訓や、開発者を新しいコンパイラや言語に移行させる経験、そして既存のMLIRコンパイラエコシステムを活用します。
• 長期目標：Mojoの長期目標はPythonのスーパーセット（既存のPythonプログラムとの互換性）を提供し、長い尾のエコシステムサポートのためにCPython実装を採用することです。
• Pythonプログラマーへの親和性：Pythonプログラマーにとって馴染み深く、CやC++を必要とするようなシステムレベルのコードを安全かつ高性能に開発するための新しいツールを提供することを目指しています。
• 静的・動的の良さ：「静的が最良」や「動的が最良」という世界観を押し付けるのではなく、適切なアプリケーションでそれぞれが良いと考え、プログラマーが静的または動的を使用するタイミングを決定できるようにMojoを設計しました。

Pythonを選んだ理由：

• MLとその他の分野における支配的な地位：Pythonは、機械学習や数多くの他の分野で支配的な役割を果たしています。
• 学習の容易さと広範な知識：Pythonは学びやすく、多くの重要なプログラマーに知られており、素晴らしいコミュニティを持ち、価値ある多くのパッケージがあります。
• 豊富なツール類：Pythonには様々な良質なツールが揃っています。
• 美しいAPIの開発支援：Pythonの動的プログラミング機能は、TensorFlowやPyTorchのような機械学習フレームワークが、C++で実装された高性能ランタイムのフロントエンドとしてPythonを採用する理由となりました。
• Modularにおける不可欠な部分：Modularにおいて、Pythonは顧客によって決定されるAPIサーフェススタックの不可欠な部分です。他のすべてが交渉可能であるため、「Pythonファースト」のアプローチから始めるのが合理的です。
• Pythonの美しさ：Pythonはシンプルで組み合わせ可能な抽象概念で設計されており、実際には冗長な句読点を省略し、強力な（動的な）メタプログラミング機能を備えています。これらはすべて、Modularで必要とされる言語への拡張のための基盤を提供します。
• Pythonエコシステムへの貢献：Pythonエコシステムにいる人々が、MojoをPythonと競合するものではなく、Pythonを次のレベルへ進化させる方向として捉えてほしいと願っています。

Pythonとの互換性：

• Pythonエコシステムとの完全な互換性：MojoはPythonエコシステムと完全に互換性を持つことを目指していますが、互換性には実際には二つのタイプがあります。
• 既存のPythonモジュールのインポート：既存のPythonモジュールをMojoプログラムで使用する能力については、CPythonを使用しているため、Mojoは100%互換性があります。
• PythonコードのMojoへの移行：すべてのPythonコードをMojoに移行する能力については、まだ完全に互換性があるわけではありません。Mojoは既にPythonの多くのコア機能をサポートしていますが、クラスのサポートを含む他の多くの機能がまだ欠けています。
• 進行中の作業：多くの作業が必要ですが、他の主要技術の構築経験を持つチームに導かれ、目標を達成する自信があります。
• ClangコンパイラとSwift言語への旅：ClangコンパイラやSwiftプログラミング言語の経験を通じて、互換性を持たせる方法やレガシーランタイムとの協力に関する教訓を学びました。
• PythonとMojoのコードの混在：PythonとMojoのコードを混在させたい場合、MojoはCPythonランタイムと直接連携し、CPythonのクラスやオブジェクトとの統合をサポートする予定です。これにより、既存の大規模なコードエコシステムとのプラグイン互換性が提供され、Mojoへの段階的な移行が可能になります。
• 言語設計と進歩への焦点：言語設計とPythonとの完全な互換性に向けた段階的な進歩に焦点を当てることで、必要な時期に目標を達成すると信じています。
• 純粋なMojoコードの実装：純粋なMojoコードを書く場合、実装、コンパイル、ランタイムに既存のPython技術は使用されていません。Mojo自体は、全く新しい言語であり、全く新しいコンパイルとランタイムシステムを持っています。

Pythonとの意図的な違い：

• Python互換性と移行可能性の重要性：Mojoの成功にはPythonとの互換性と移行可能性が鍵ですが、Mojoは他の言語に依存しない独立した言語として一流であるべきです。互換性を維持するためだけに新しいキーワードや文法の導入を制限するべきではありません。
• 二つのアプローチへの取り組み：
  1. CPythonの利用：既存のPython 3コードを修正せずに実行し、そのランタイムを全エコシステムとの完全な互換性のために変更せずに使用します。この方法でコードを実行することはMojoの利点はありませんが、このエコシステムの存在と利用可能性はMojoの立ち上げを加速し、Pythonが高レベルプログラミングにすでに非常に優れているという事実を活用します。
  2. 機械的な移行ツールの提供：PythonからMojoへコードを移行したい人々に非常に良い互換性を提供する移行ツールを提供します。例えば、Mojoのキーワードと一致する識別子名を使用するPythonコードの移行エラーを避けるために、Mojoではバックティック機能を提供して、任意のキーワードが識別子として振る舞うことができます。
• Mojoの統合と段階的移行：これにより、MojoはほとんどCPythonの世界にうまく統合され、Mojoプログラマーはコードを段階的に（モジュールやファイル単位で）Mojoに移行できるようになります。これはAppleがObjective-CからSwiftへの移行で実証されたアプローチです。
• Mojoと移行サポートの構築：Mojoの残りの部分と移行サポートを構築するには時間がかかりますが、この戦略によりエネルギーを集中し、気を散らさずに済むと自信を持っています。
• CPythonとの相互関係：CPythonチームがいずれMojoでインタープリターを再実装するという可能性もあり、それは魅力的ですね。🔥

二つの世界の問題：

• システムプログラミングに不適切なPython：Pythonはシステムプログラミングには適していないものの、接着層として素晴らしい強みを持ち、CやC++への低レベルバインディングを通じて、より良いパフォーマンス特性を持つライブラリをC、C++などの他の言語で構築することが可能です。これがNumPy、TensorFlow、PyTorchなど、エコシステム内の多くのライブラリの実現を可能にしています。
• 高性能ライブラリ構築のコスト：このアプローチは高性能なPythonライブラリを構築する効果的な方法ですが、複雑さというコストが伴います。これは、CPythonの内部構造の低レベルな理解が必要であり、C/C++（または他の）プログラミングの知識が求められるため、Pythonを使う元々の目的を損なうことがあります。また、大規模なフレームワークの進化を困難にし、「グラフベース」プログラミングモデルへの移行を促しますが、これは「イーガーモード」システムよりも使い勝手が劣るとされています。TensorFlowやPyTorchは、この点で大きな課題に直面しています。
• 二つの世界の問題による複雑性：この二つの世界の問題はシステムの複雑さを生み出すだけでなく、エコシステム全体をより複雑にしています。デバッガーは一般的にPythonとCのコードを横断してステップすることができず、できるものも広く受け入れられていません。PythonパッケージエコシステムがC/C++コードを扱わなければならないのは厄介です。PyTorchのようなプロジェクトでは、C++への大きな投資がありながら、使い勝手を向上させるためにコードベースの大部分をPythonに移行しようと意図的に試みています。

三つの世界とNの世界の問題：

• Pythonエコシステムにおける二つの世界の問題：Pythonエコシステム全体で共通して感じられる二つの世界の問題がありますが、機械学習フレームワークの開発者にとってはさらに厳しい状況です。
• AI分野におけるアクセラレータの使用：AIは広範囲にアクセラレータを使用しており、これらのアクセラレータはCUDAのような特殊なプログラミング言語を使用しています。CUDAはC++の親戚ですが、独自の問題や制限があり、デバッガーやプロファイラーなどの一貫したツールがありません。また、特定のハードウェアメーカーに縛られている状態です。
• ハードウェア分野の革新と複雑性：AI分野ではハードウェアの前面に驚くべき革新があり、その結果、複雑性は制御不能になっています。アクセラレータ向けの限定的なプログラミングシステム（OpenCL、Sycl、OneAPIなど）を構築しようとする試みがいくつかあります。しかし、この複雑性の爆発は続いており、これらのシステムのいずれも、業界に甚大な損害を与えているツールやエコシステムの根本的な断片化を解決していません。実際には断片化をさらに増加させています。

モバイルとサーバーへのデプロイメント：

• Pythonエコシステムの課題：Pythonエコシステムにはデプロイメントに関する多くの課題があります。
• デプロイメントの多面性：
  • 依存関係のコントロール：依存関係をどのように管理し、制御するか。
  • 「a.out」ファイルの展開：密封されたコンパイル済みの「a.out」ファイルをどのようにデプロイするか。
  • マルチスレッディングとパフォーマンスの向上：マルチスレッディングの改善とパフォーマンスの向上。
• Pythonエコシステムの進歩への期待：これらの領域では、Pythonエコシステムが大きく前進することを望んでいます。

関連する取り組み：

• Pythonの改善に向けた他の努力：Pythonの改善を目指す多くの他の取り組みがありますが、これらはMojoで解決しようとしている根本的な問題を解決しません。
• Python改善の進行中の取り組み：
  • Pythonの速度向上とGILの置き換え：Pythonの実行速度を上げ、Global Interpreter Lock（GIL）を置き換える作業。
  • Pythonに似た言語の構築：Pythonに似ているが、Pythonのサブセットであるような言語の構築。
  • 埋め込みドメイン固有言語（DSL）の構築：Pythonと統合されるが、一流の言語ではない埋め込みドメイン固有言語の開発。
• これらのプロジェクトの課題とMojoとの違い：これらのプロジェクトが直面している課題について詳細なリストは提供できませんが、これらがMojoが解決する問題とは異なる理由については言及できます。

CPythonの改善とPythonのJITコンパイル：

• CPython性能の向上：最近、コミュニティはCPythonの性能向上と他の実装問題に大きなエネルギーを注いでおり、これが大きな成果を上げています。例えば、Python 3.11は内部改善によりPython 3.10に比べて10-60%のパフォーマンス向上を達成しました。Python 3.12ではトレースオプティマイザーを導入してさらなる向上を目指しています。
• GILの制御とJITコンパイル：GIL（Global Interpreter Lock）を制御しようとする多くのプロジェクトや、PyPyのようにJITコンパイルやトレーシングアプローチを用いてPythonを高速化するプロジェクトがあります。
• これらの取り組みとModularのニーズの違い：これらの取り組みは素晴らしく、コミュニティにとって価値があると考えますが、残念ながらModularでのニーズを満たすものではありません。これらの方法では、アクセラレータへの統一言語の提供が可能になりません。多くの現代のアクセラレータは非常に限定された動的機能をサポートしているか、または非常に低いパフォーマンスでそれを行っています。さらに、システムプログラマーは「パフォーマンス」だけでなく、計算の方法に対する予測可能性とコントロールを求めます。
• CまたはC++の使用排除と最高のパフォーマンスの追求：Pythonライブラリ内でCまたはC++を使用する必要を排除し、最高のパフォーマンスを追求し、場合によっては動的機能を一切受け入れることができません。したがって、これらのアプローチは私たちの問題を解決しません。

PythonサブセットとPythonライクな言語：

• 「デプロイ可能な」Pythonの試み：TorchScript（PyTorchプロジェクトから）のように、デプロイ可能なPythonを構築しようとする試みが多数あります。これらは低依存性のデプロイメントソリューションを提供し、時には高いパフォーマンスを持つため、有用です。
• Pythonライクな構文の利点：Pythonに似た構文を使用するため、新しい言語を学ぶよりも簡単である可能性があります。
• 広範囲な採用の欠如：これらの言語はPythonのサブセットであるため、一般的にPythonエコシステムと相互運用性がなく、優れたツール（例えばデバッガー）がないことが多く、Pythonの不便な振る舞いを一方的に変更することが多いため、広範囲に採用されていません。これは互換性を壊し、エコシステムをさらに断片化します。
• これらのアプローチの課題：これらのアプローチはPythonの弱点を解決しようとしますが、Pythonの強みを活かすことはありません。これらはCやC++への新たな代替を提供する可能性がありますが、Pythonの動的な使用ケースを解決せず、「二つの世界の問題」を解決することはできません。このアプローチは断片化を促進し、非互換性は移行を困難から不可能にします。Python 2からPython 3への移行がいかに困難であったかを思い出してください。

PythonスーパーセットとC互換性：

• Mojoの設計：Mojoは、システムプログラミング機能が向上したPythonのスーパーセットとして設計されており、PyrexやCythonのような他のPythonスーパーセットといくつかの高レベルなアイデアを共有しています。Mojoと同様に、これらのプロジェクトは自身の言語を定義し、Python言語もサポートしています。これにより、PythonとCライブラリの両方と相互運用できる、より高性能なPython拡張を書くことができます。
• Pythonスーパーセットの利点と限界：これらのPythonスーパーセットは、特定の種類のアプリケーションには素晴らしく、一部の人気Pythonライブラリによって効果的に適用されています。しかし、これらはPythonの二つの世界の問題を解決せず、CPythonのコアセマンティクスに依存しているため、それなしでは機能しません。一方、Mojoは既存のPythonコードとの互換性を提供するために必要な場合にのみCPythonを使用します。純粋なMojoコードは既存のランタイムやコンパイラ技術を使用せず、代わりにMLIRベースのインフラストラクチャを使用して、幅広いハードウェアでの高性能実行を可能にします。

Python内の埋め込みDSL：

• 埋め込みドメイン固有言語の開発：Python内で埋め込みドメイン固有言語（DSL）を構築するのは一般的なアプローチで、通常はPythonのデコレーターを使用してインストールされます。TensorFlowの@tf.functionデコレーターやOpenAIのTritonプログラミングモデルの@triton.jitなど、多くの例があります。
• システムの主要な利点：これらのシステムの大きな利点は、Pythonツールのエコシステムとの互換性を維持し、Pythonロジックにネイティブに統合することで、動的な使用ケースのためのPythonの強みと共存する埋め込みミニ言語を可能にすることです。
• 埋め込みミニ言語の限界：これらのシステムによって提供される埋め込みミニ言語は、しばしば予想外の制限があり、デバッガーや他のワークフローツールとの統合がうまくいかず、異種コンピュートを統一し、大規模なカーネルやシステムを書くための主要な言語であることを目指す私たちが求めるネイティブ言語統合のレベルをサポートしていません。
• Mojoによる全体システムの使いやすさの向上：Mojoでは、システムを単純化し、より一貫性を持たせることによって、全体の使いやすさを前進させることを目指しています。埋め込みDSLはデモをすばやく立ち上げるための迅速な方法ですが、私たちはより良い使いやすさと予測可能性を提供するために、追加の努力と作業を行う意思があります。
• Mojoでこれまでに構築したものを知るには：Mojoマニュアルを参照してください。

インストール

TODO 以下続き記載

Developer Console