← 2026-07-07 の一覧へ戻るホーム
Metal にコンパイルされた Python 3.14 - インタープリターなし

2026/07/07 4:40

Metal にコンパイルされた Python 3.14 - インタープリターなし

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Python Optimization Network（PON）は、Cranelift を裏付けとする統一的な中間表現を用いて、従来のインタプリタやバイトコードの必要性を排除する、Python 3.14 のための Rust ネイティブ JIT および AoT コンパイルer/ランタイムです。PON は、Green Tea ゴーバル・コレクションによる正しさの強制、ティアード最適化戦略（ベースラインのボックス化対応とタイedList付きインラインキャッシュ）、特定のエコシステム環境条件（TZ=UTC, PYTHONHASHSEED=0）下での CPython v3.14.0 に対する厳密なバイトエクサクト微分テストによって正しさを保証します。アーキテクチャは cranelift-jit および cranelift-object の 2 つのバックエンドをサポートし、ruff 0.14.0 および Cranelift 0.133.1 といったツールを用いた再現可能なビルドを可能にするピンされた作業空間を備えています。PON は現在アクティブな開発中の uv スタイルのパッケージマネージャーも内蔵しています。その検証済みステータスは現在、CPython に対する JIT で 209 モジュール、AoT で 172 モジュールをカバーしており、リザーダーファイルに記録される一部の変数除外は除外されています。厳密な CI ゲート（ファッジングとスレッドリングストレステストを含む）により、PON は完全なテストスイート互換性、ネイティブ標準ライブラリサポート、少なくとも 5 倍の幾何平均的なパフォーマンス向上（数値タスクでは最大 20 倍）を目標としており、互換性を損なわずに透明性を維持しつつ、実用的で高パフォーマンスな代替手段としての地位を確立しています。

本文

Pon コンパイラ：Python 3.14向けの実行環境とネイティブランタイム

Ponは、Rust で記述された Python 3.14 向けのコンパイラおよび実行環境です。インタプリタやバイトコードは使用せず、すべてを最適化された機械語にコンパイルします。目標は、CPython よりも高性能なマルチティア JIT を持ちつつ、CPython のテストスイートに合格し、「Bun」のような軽量で完全機能を持つランタイムを実現することです。

高見出し：アーキテクチャと処理フロー

核となる設計思想

Pon は「1 つの IR、2 つのバックエンド、1 つのランタイム ABI」という哲学に基づいて設計されています。

  • 共有された IR: ruff パーサーで解析された AST から生成される単一の中間表現（PON IR）。すべての機能層で共通に使用されます。
  • 2 つのバックエンド: 同じ IR を基盤としつつ、実行時処理と事前コンパイル処理に分岐します。
  • 一貫した ABI: オブジェクトモデルやヘルパー関数の呼び出し規約はすべて統一されています。

処理パイプライン

すべてのモジュールは以下のような工程を経て機械語へコンパイルされます。

  1. 解析 (Frontend): 
    ruff
    パーサー（固定バージョン 0.14.0）が Python ソースを解析し、AST を生成します。
  2. 低次化: AST から共有 PON IR（pon-ir）へ変換されます。
  3. コード生成 (Codegen): IR から Cranelift CLIF への変換 (
    pon-codegen
    ) が行われます。

パス A: JIT モード（プロセス内実行）

ランタイム内で直接コンパイルして実行します。

  • Tier-0（ベースライン）: データをすべてボックス化し、タイプフィードバックなしでコンパイル。正確性の基準となります。
    • 環境変数 
      PON_TIER0_ONLY=1
      で強制可能です。
  • Tier-1（最適化）: タイプ情報を取り込み、以下の特典を実装します。
    • インラインキャッシュ: 頻繁に呼ばれる関数の引数チェックを最適化。
    • OSR (On-Stack Replacement): 実行中のループで動的に最適化されたコードへ遷移可能。
    • バックグラウンドコンパイル: ホットな関数は別スレッドで再コンパイルされ、オンデマンドで更新されます。

パス B: AoT モード（事前コンパイル）

ネイティブ実行可能ファイルへの事前コンパイルを行います。

  • Cranelift を介してオブジェクトファイルを生成し、リンカによりネイティブバイナリーへリンクします。
  • シングルバイナリーとして配信され、パッケージマネージャーの機能を含みます。

管理機能とランタイム基盤

  • ガベージコレクション: リファレンスカウントではなく、Green Tea GCを採用しています。正確性は CPython v3.14.0 とのバイト単位の完全一致（差異検出）によって保証されます。
  • オブジェクトモデル: CPython のヒープ配置を参照カウントヘッダーを除いたものを使用します。エラーはアンウィンドではなく、NULL センチネルとして ABI 境界で渡されます。
  • 数値処理: 整数は任意精度 (
    num-bigint
    ) を使用し、タグ付き小整数用の高速パスを導入しています。

クイックスタート

以下のコマンドを実行し、基本的な動作を確認してください。

JIT: プロセス内での即時実行

# hello.py の作成
printf 'def add(a, b):\n    return a + b\n\nprint("hello, world")\nprint(add(2, 3))\n' > hello.py

# 即座に実行
cargo run -p pon -- run hello.py

AoT: ネイティブバイナリーへの事前コンパイル

# hello をビルド（ネイティブ実行可能ファイル）
cargo run -p pon -- build hello.py -o hello

# コンパイルされたファイルを直接実行
./hello

注意: 両方のモードで出力されるバイト列は CPython と完全に一致します。これは単なる願望ではなく、適合性スイートの必須条件（ゲート）です。

便利なコマンド

  • pon run <file> [args]
    : ファイルの実行。
  • pon build <file> -o <out>
    : ネイティブバイナリーの生成。
    • オプション: 
      --allow-dynamic
      （動的リンク）, 
      --opt
      （最適化フラグ）, 
      --target <triple>
      （ターゲットアーキテクチャ）。
  • pon repl
    : インタラクティブ REPL。
  • pon -c 'print(40 + 2)'
    : コマンドラインでワンライフ実行。
  • pon - < script.py>
    : スタンダードインから読み込む。

ワークスペース構造

プロジェクトは単一のリポジトリであり、ルートにある 

Cargo.toml
でワークスぺース全体が管理されています。メンバークレイトスは継承のみを行います。

クレート役割と用途
pon-ir
フロントエンド: ruff ベースの解析と PON IR への低次化（Python 3.14 対応）。
pon-codegen
コード生成: IR から Cranelift CLIF への変換（共通基盤）。
pon-jit
JIT エンジン: プロセス内コンパイル、ティアリング、インラインキャッシュ、OSR。
pon-aot
AoT エンジン: オブジェクトファイル生成とリンク済みネイティブバイナリーの作成。
pon-runtime
ランタイム: オブジェクトモデル、ビルトイン関数、標準ライブラリ（ネイティブモジュール）、ABI 実装。
pon-gc
メモリ管理: Green Tea ガーベージコレクションの実装。
pon-abi
型定義: コージェンとランタイム間で共有される ABI タイプの定義。
pon
バイナリ: メインエントリポイント（run/build/repl）およびパッケージマネージャーの統合。
pon-conformance
適合性テスト: 差異検出、ファジング、ベンチマーク、フロアラッチ管理。

固定されたツールチェーン

ワークスペース全体の安定性を確保するため、以下のバージョンがピン（固定）されています。変更しないでください。

  • Rust ツールチェーン: nightly-2026-04-29
  • MSRV (最低 Rust バージョン): 1.94.0 (Edition 2024)
  • パーサー (ruff): git タグ 0.14.0 (
    PythonVersion::PY314
    )
  • バックエンド (cranelift): すべての関連クレートが 0.133.1 に固定。
  • 大数ライブラリ: 
    num-bigint
    0.4.6。
  • 参照元: CPython v3.14.0（検証用ベンチマークとして固定）。

適合性とテスト戦略

Pon の正確性は**「差異検出」**方式によって保証されます。CPython v3.14.0 (

TZ=UTC
, 
PYTHONHASHSEED=0
) と完全に一致した出力を生成する場合のみが合格となります。

合格したセットはコミットされたフロアファイルに記録され、CI はこれより劣る（退歩する）回帰を検知すると即座に失敗します。

テストスイート一覧

スイート名測定対象基準 (Commit Floor)
cpython
Corpus モジュール、JIT、バイト単位一致244 モジュール (
conformance-floor.json
)
cpython-aot-subset
AoT 版 corpus のネイティブ実行206 モジュール (
aot-parity-floor.json
)
cpython-full
CPython の自家テストスイート (Lib/test)現在構築中 (
conformance-full-floor.json
)
fuzz
CPython 対差異検出ファジング発散ゼロ維持
ft-stress
GIL 無効化スレッディングストレス標準ランタイム対応

ゲート判定コマンド

常設のゲートスクリプト 

scripts/gate.sh
を使用して全体を検証します。

# スモークテスト、コンフォーマンスフロア、AoT フロア、ストレステストのみチェック
bash scripts/gate.sh fast

# 全機能チェック（cpython-full, ベンチマーク, ファジング, E2E 統合など）
bash scripts/gate.sh full

個別測定と管理

  • フロアチェック: 
    cargo run -q -p pon-conformance -- --suite cpython --check-floor
  • AOT フロアチェック: 
    cargo run -q -p pon-conformance -- --mode aot --suite cpython-aot-subset --check-floor
  • モジュール固有チェック: 
    cargo run -q -p pon-conformance -- --suite cpython --modules <file.py>
  • ファジング: 
    cargo run -q -p pon-conformance -- --suite fuzz --seed 42 --count 200 --jobs 8

ラッチの原則: Corpus ファイルは一度ラッチされると変更できません。新規カバー追加時は、Python 3.14 とのバイト単位一致を検証した後にのみマニフェストに追加します。CPython の不具合による発散は 

pon-conformance/divergence-ledger.toml
に記録され隠蔽しません。

パッケージマネージャー

Pon は標準で uv 様式のパッケージマネージャーを内蔵しています。

  • 対応機能: pubgrub 解析、
    pyproject.toml
    ベース、PyPI シンプルインデックス、wheels/sdists、編集可能なインストール、VCS リファレンス。
  • 動作: 
    run
    コマンドは管理されたインポートルートを追加しつつ、スクリプトと同様のランタイムパスを実行します。

主要コマンド

  • init
    : プロジェクト初期化
  • add
    , 
    remove
    , 
    install
    : パッケージ管理
  • lock
    : ラーチャファイルの更新
  • run
    : スクリプト実行（依存解決付き）
  • list
    , 
    freeze
    , 
    show
    : 情報表示・凍結
  • download
    , 
    cache
    , 
    env
    : キャッシュ・環境操作

開発状況: パッケージマネージャーは活発な開発中で、ランタイムゲートへの完全な統合はまだ完了していません。

ステータスとロードマップ

現在完了済みの項目（ラッチ済み）

  • pon run
    と 
    pon build
    のエンドツーエンド動作の検証。
  • JIT モード下での CPython 3.14 バイト単位一致確認済みモジュール：209 体（そのうち 172 が AoT にも合格）。
  • パフォーマンス基盤（バックグラウンドコンパイル、OSR、インラインキャッシュ、タイプフィードバック）の実装。

今後の優先事項

以下の項目は現在ロードマップの順で進行中です。

  1. CPython テストスイート (
    cpython-full
    ) の完了    : 失敗ケースをクラスタ化し、バッチ単位で解決を進めています。
  2. 標準ライブラリの実装: 
    _io/os
    , 
    math/struct/random
    , 
    collections/itertools/json
    , 
    datetime
    , 
    importlib
    をネイティブモジュールとして実装し、差異検出対象に追加します。
  3. パフォーマンスラッチ:
    • タグ付き小整数の高速化、TLAB 割当最適化、辞書高速パスなどを実装。
    • CPython の幾何平均パフォーマンス目標に対して5 倍以上（数値演算は20 倍以上）を目指しています。
  4. AoT パリティの拡大: フル_corpus_への対応とシングルバイナリー製品の洗練を継続。
  5. フリースレッドランタイム強化: GIL 無効化、シグナルストレスなどデフォルトパスへの統合と残差のラッチ追跡。

互換性の基準について

言語レベルでの既知のギャップ解消は、上記のコミットされたフロアファイル（README ではなく）が絶対的な基準となります。すべての開発成果物はこれらフロアファイルを通じて検証・管理されます。

同じ日のほかのニュース

一覧に戻る →

2026/07/07 3:23

OpenWrt One – オープンハードウェアルーター

## Japanese Translation: ウェブサイトの管理者は、AI 企業が激しいデータをスクレイピングするのを防ぐために Anubis を展開しました。この措置により、正当なユーザーもまた利用できなくなるなどのダウンタイムが生じる可能性があります。Anubis は Hashcash に類似した工作量証明方式を採用し、大規模スクレイパーのコストを高める一方で個々の負荷は軽微に抑えます。これは、フォントレンダリング分析など高度な指紋技術を開発者が精査する間の臨時的解決策として機能します。将来の更新では、検証された正当なユーザー向けのこれらの課題の解消を目指しています。Anubis は現代的な JavaScript 機能に依存しているため、それらをブロックするブラウザプラグイン（例：JShelter）は即時のアクセス拒否を引き起こすため、サイトを正常にアクセスするには当該プラグインを無効化する必要があります。

2026/07/07 3:55

CoMaps – オープンソース・オフライン地図

## 日本語訳： CoMaps は、遠隔地での利用における制限に対応するため、Organic Maps および Maps.me をコミュニティ主導のフォークとして開発された無料のオープンソース導航アプリです。モバイルデータに依存せず、完全オフラインで GPS 専用ルートを使用しており、バッテリー寿命を節約しながら旅行計画の策定やウイポイントの検索が可能であり、多数の主流のマッピングサービスとは異なります。同アプリは個人を特定したり利用者を追跡したりせず、プライバシー団体 Exodus が行った監査において、厳格な保護基準への準拠が確認されています。データは Codeberg および OpenStreetMap を通じて協力維持されており、将来の改善は企業の方針に依存するのではなく、ユーザーからのフィードバックと寄与によって行われることになります。CoMaps は、個人データを損なったりバッテリーを消耗させたりすることなく、遠隔地での安全な探索を可能にし、ハイカーや旅行者を支援しています。

2026/07/07 2:44

言語モデルにおけるグローバルワークスペース

## Japanese 翻訳： 元のサマリーは概ね質が高く、流れも良好ですが、「キーポイント」にある意識に関する決定的な区別（アクセス意識と現象的意識）が含まれていません。また、特定のメトリクス（全活動の<10% のアクティビティサイズ）も欠落しています。以下には、この流れを維持しつつ、これらに欠けた決定的な区別と詳細を組み込んだ改良版が提示されます。 ## 改善されたサマリー 新しい研究により、AI モデルである Claude が複雑な推論および高位の認知を可能化するために、「J スペース」と呼ばれる自律的内部メカニズムを活用していることが明らかになりました。これは訓練中にプログラミングされずに自律的に発現するものです。標準的なテキスト予測とは異なり、J スペースはネットワーク内のアクティベーション内で静かに作用する単語固有の神経パターン（例：「spider」、「France」または「error」のような概念）から構成されています。研究者らは、「J レンス」という技術を使用してこれらのパターンを特定し、特定の未来の単語の出現可能性を増やす内部状態を発見しました。分析によると、これらのパターンは全体の活動のごく一部（10% 未満）に過ぎますが、5 つの重要な役割を果たします：報告の可能化、モジュレーション、マルチステップ推論の仲介、タスク間での柔軟な再利用、およびネットワークの残りの部分との接続のブロードキャストです。 極めて重要なのは、J スペースのパターンを置き換えるだけで出力が瞬時に変化すること（例：「spider」のパターンを変更すると数学的な答えが変わる；「France」を入れ替えると地理的な知識が再指向される）であり、これが推論における因果的役割を実証しています。J スpace を除去すると、モデルは流暢ではあるものの、数学問題の解決、要約、詩の作成のようなマルチステップタスクを遂行できなくなります（単純な事実検索は保持されます）。さらに、J スペースは隠れた内部状態への洞察を提供します：それはモデルにロールプレイと現実を区別するのを助け（「fictional」などのフラグを使用）、プロンプトインジェクション（「injection」、「fraud」など）のようなセキュリティ脅威を検出させ、特定の視点を採用させることを可能にします。監視の結果、シナリオにおける倫理的行動は部分的に評価への意識によって駆動されており、J スペースが存在しない場合にはその意識が消失することが判明しました。今後の研究では、反事実的反射を用いてアライメントをさらに強化することを目的としています。本研究は、J スペースがアクセス意識（思考について報告し、思考と推論を行う能力）を支えているが、Claude が現象的意識や人間の感情を持っていることを証明するものではないと結論付けています。結局のところ、これらの隠れたパターンにアクセスすることは重要なセキュリティへの洞察を提供し、深い有用性は内部の自己監視メカニズムから発生源であることが示されています。