- Python をハードウェア上で直接実行する カスタムプロセッサ で、インタプリタ や JIT なしで動作する
- PyXLの GPIO 往復時間は 480ns で、MicroPythonのPyBoardより 30倍 高速
- Zynq-7000 FPGA上で動作し、ARM CPU が設定とメモリを処理する
- GPIO は 汎用入出力 を意味し、PyXL はこれをハードウェア上で直接実行することで VM や ソフトウェアスタック を経由しない
- リアルタイム制御システム、ロボティクス、組み込み産業システム などで 決定論的 かつ 一貫した 性能を提供
PyXLの紹介
- PyXL は Python をハードウェア上で直接実行する カスタムプロセッサ である
- インタプリタ や JIT なしで シリコン 上で Python コードを実行する
- CPython ByteCode を カスタムアセンブリ に変換して パイプラインプロセッサ で実行する
PyXLの特徴
- C や インラインループ ではない
- MicroPython や JIT ではない
- Linux や OS を実行しない
- 決定論的 かつ 高速化 のために設計された Python 専用プロセッサである
PyXLの実行環境
- Zynq-7000 FPGA 上で動作し、Arty-Z7-20開発ボード を使用
- PyXLコア は 100MHz で動作する
- ARM CPU が設定とメモリを処理し、Pythonコード はハードウェア上で直接実行される
GPIOとは何か?
- GPIO は 汎用入出力 を意味し、ソフトウェア が LED、ボタン、センサー、モーター などを制御できるようにする
- MicroPython では Pythonコード が C関数 と相互作用してハードウェアレジスタを処理する
- PyXL は Pythonバイトコード をハードウェア上で直接実行し、インタプリタ や 関数呼び出し なしで ネイティブハードウェア 上で動作する
GPIOテスト
- Artyボード の2つのピンを ジャンパーケーブル で接続してテストした
- Pythonプログラム を作成し、GPIOピン1 が 1 に設定された後、別のピン で 1 が測定されるまでの時間を計測した
- PyXL と PyBoard の MicroPython VM を比較する 動画 により性能差を確認した
PyXLのプログラム構造
- Pythonプログラム は CPython Bytecode にコンパイルされた後、PyXLアセンブリ に変換される
- バイナリ が生成され、ネットワーク 経由で Artyボード に送信される
- ARM CPU が アプリケーション を受け取り、PyXLハードウェア と 共有メモリ にコピーして実行する
プラットフォーム比較
- GPIO往復遅延時間: PyXL は 480ns、MicroPython (PyBoard) は 14,741ns
- PyXL は PyBoard より 30倍 高速で、クロック速度 を 正規化 すると 50倍 高速
PyXLの利点
- Python VM は ソフトウェアインタプリタ を基盤としているため、オーバーヘッド と 複雑さ を招く
- PyXL はこうした 障壁 を取り除き、Pythonコード をハードウェア上で直接実行する
- GPIOアクセス は 物理的 であり、制御フロー は 予測可能 で 一貫した 性能を提供する
PyXLの応用分野
- リアルタイム制御システム を 純粋なPython で実装可能
- ML推論 および センサー応答ループ で 厳格な時間制約 を満たす
- ロボティクス で モーターフィードバック と センサー融合 を サイクルレベルの精度 で処理する
- 組み込み産業システム で タイミング と 信頼性 が重要な場合に適している
6件のコメント
バージョン変更にはどのように対処しますか？
HiLエンジニアにとっては、ひょっとすると朗報かもしれませんね。
おお、面白いですね
とても楽しみですね
このプロジェクトの開発者が、今回の PyCon US でこの内容について発表します。今年初めにプロポーザルをレビューしたときも、レビュアーの間でかなり話題になっていたのですが、それに比べると発表紹介の内容があまりにも控えめですね。PyCon に行かれる方は、ぜひ一度聞いてみることをおすすめします。
https://us.pycon.org/2025/schedule/presentation/40/
Hacker Newsのコメント
メモリ制限やOSとの相互作用を除いて、どのようなコードが実行可能なのかに制限があるのか気になる。動的言語ランタイム向けのバイトコードを専用プロセッサ向けにするという発想は、最近あまり十分に探究されていないと思う。なぜこの方向を選んだのか、なぜそれが良いアイデアだったのか、そして実装過程について知りたい
従来のVMやインタープリタなしでPythonプログラムを直接実行するハードウェアプロセッサを構築したとのこと。初期ベンチマークではGPIOのラウンドトリップ時間が480nsで、MicroPythonより30倍高速
とてもクールな仕事だと思う。最終的な機能セットが、カスタムハードウェアを作ることよりも、Python構文を持つ型安全な言語をネイティブコンパイルする方向より大きくなるのか気になる。バックグラウンドGCは言うほど簡単ではないが、すでに非常に難しい仕事をやってのけた人と話しているわけだからなおさら興味深い
なぜPythonを「コンパイル」することが一般的ではないのか気になる。インタープリタが高速な反復や互換性などに向いているのは理解しているが、Pythonの世界ではコンパイルの利点を捨てて「ソース」ファイルを本番環境にそのまま置くことが、なぜ受け入れられた慣行になっているのだろう
とても興味深い。根本的な物理的限界が何なのか気になる。つまり、タイミング精度、レイテンシ、ジッタなどだ。PyXLバイトコードが入力にどれだけ速く反応できるのか。ARTIQという似たものがあり、Pythonコードを「組み込みレベル」の性能で実行する。ARTIQは量子物理学の実験室でよく使われている。PythonコードとFPGAが相互に通信しなければならず、これは技術的に難しく落とし穴も多い。PyXLがそれをユーザーにとってより簡単にしてくれるなら、誰にとっても大きな利点だ
C#が登場したとき、誰かが.Netバイトコードをネイティブ実行するプロセッサを作るだろうと確信していた。どのHDLを使ってプロセッサを設計したのか気になる。プロセッサのアセンブリ言語を共有できるのかも気になる。既存プロセッサ（ARM/x86/RISCVなど）向けのバイトコードコンパイラを作るのと比べて、プロセッサを設計し、Pythonバイトコードコンパイラを作る利点は何なのだろう
Python開発者に聞いてみたい。このプロジェクトを見てすごいとは思うが、言語の外部の人間としては理解しきれない。a) 以前Pythonのせいで何が難しかったのか、b) この作業においてPythonが有用な理由、c) Pythonそのものについてどう思っているのか知りたい。Python 2と3、仮想環境、各バージョンのライブラリなどで苦労したことがある。PHP/Go開発者として関心はあるが、そうした問題のために二の足を踏んでしまう
驚くべき仕事だ。FPGA上の優れた実装を見るたびに、Tabulaが成功しなかったのが惜しまれる。非常に革新的で高速なFPGAだった
ASICがPython専用マイクロコントローラを実行していて、Python向けに調整されたマイクロコードを持っている、という理解で合っているのだろうか。Pythonバイトコードをマイクロコードにコンパイルするコンパイラと、そのコンパイル済みバイトコードをASICに渡すための支援インフラがあるということなのか。面白い。正しく理解できているか気になる