パスワードを忘れた? アカウント作成
16529379 story
Python

Pythonコンパイラ「Codon」誕生 72

ストーリー by nagazou
両立 部門より
Pythonは可読性や広範なエコシステムなどから、最も人気のあるプログラミング言語だが、速度面での評価は高くない。そんな中、MITの研究者たちは高級言語の親しみやすさと低水準言語の高速性を両立させる方法を発見したという(The Register)。

彼らは「Codon」と呼ばれるPythonコンパイラを開発し、Pythonコードをネイティブなマシン語に変換することで、実行時のパフォーマンスを低下させないようにすることに成功したそうだ。レポートによれば、Codon使用時のパフォーマンスは、シングルスレッド性能で従来の10-100倍以上の高速化を達成している。C/C++と同等もしくはそれ以上の性能があるとしている。

もっとも課題も残っているという。CodonはPythonのほとんどの機能を実装しているが未実装の部分も残っていたり、Pythonのモジュールの中にはCodonに組み込まれていないものもある。このほか、コードの解析や最適化を難しくする機能も省かれているという。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 簡単に並列化できるようにならないかな?
    • by Anonymous Coward

      簡単に並列化できるようにならないかな?

      Pythonが八岐大蛇かヒュドラかギドラにクラスチェンジですね

      • by Anonymous Coward

        Orochiとかガイジンに受けそうじゃん。それいこ。

    • by Anonymous Coward

      GILの制約はどうなってんだろ

  • by Anonymous Coward on 2023年03月14日 15時19分 (#4426520)

    日本語が標準で使えないじゃないかよ。
    自作スクリプトのほとんどを置き換えられないよ。

    アメリカ人からみたら、ASCII以外を使うのは不要なオーバーヘッドにしか見えないんだろうけど。

    • by Anonymous Coward

      > Unicodeが使えないとなると
      これ、どこの情報ですか?

      • by Anonymous Coward on 2023年03月14日 17時13分 (#4426609)

        Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
        https://docs.exaloop.io/codon/general/differences [exaloop.io]

        親コメント
        • by Anonymous Coward

          今時ASCIIに限定する意味が分からん
          UTF-8も駄目なのか

          • by Anonymous Coward

            Unicode文字列の処理はかなり面倒なので後回しにしたんでしょ。UTF-8は入出力のエンコーディングであって、内部では別の表現になっている。

            • by Anonymous Coward

              Unicode自体がだいぶスジの悪い多言語対応なのよね、いったい実装上いくらあれば十分なんだ?
              UTF-16なら十分か?UTF-32か?UTF-65536か?
              将来において太陽系外惑星と接触したときのことまで考えられているのか?
              Unicode、UTF系だから安心だと考えるその精神構造がまず理解できない

              • by Anonymous Coward

                太陽系外惑星と接触したときには地球人が思いつかなかった、あっと驚く基礎的なテクノロジーに出会うと思う。
                どうしてそれを思いつかなかったのか?くやしい!っていうレベルの。

            • by Anonymous Coward

              内部でも単なる8ビットバイト列として扱っていて文字の途中で平然とぶった切ってくる手抜き実装も普通にあるけどな

    • by Anonymous Coward

      Unicode(UTF-8のこと?)を処理するためのライブラリをpythonで誰か実装しないかなー?(そういうのってクラスで解決するのかな?)

  • by nekopon (1483) on 2023年03月14日 17時10分 (#4426606) 日記
    いやまさかFORTHじゃあるまいし
  • by Anonymous Coward on 2023年03月14日 14時53分 (#4426502)

    ネイティブなマシン語なら当たり前だよね?
    あとは最適化とかライブラリの出来次第。
    実際には多少遅くとも同等扱いなんでしょ。

    • by annoymouse coward (11178) on 2023年03月14日 16時19分 (#4426566) 日記

      > ネイティブなマシン語なら当たり前だよね?

      それは良くある勘違いです.当たり前ではありません.

      C/C++のコードに比べるとpythonのコードはコンパイル&最適化が難しいです.
      難しい理由の一つは,pythonは実行するまで変数の型が決まらないためです.これはネイティブなマシン語を吐くだけでは全く解決できない問題です.

      C/C++ふうに言えば,pythonでソースコード中に foo(x) という関数呼び出しがあった場合
      xの型はint型,unsigned int型,float型,std::string型,struct X,class Y,など無限の可能性があります.
      当然実行時には型の候補は有限で,実際の型は実行時には一つになります,ただし実行されるたびに型が変わる場合もあります.
      だからpythonインタプリタは実行時に毎回型チェックをやって,その都度CPUが実行するコードを切り替えています.
      ですから,仮に全パターンのマシン語を生成して,それを実行時に切り替えたところで,CPUの命令キャッシュがぐちゃぐちゃになるだけで何も問題は解決しません.

      これは実行時の問題なので,実行時コンパイル(JIT)を使わないと解決できません.
      つまり直接マシン語を吐く古典的方法ではなく,バイトコードをはいてバイトコードを効率よく実行する仕組みを別途用意する現代的方法で解決します.

      しかしまだその技術は確立されていません.だから現状のpythonは実行速度はまだ遅く,高速化の研究が盛んに行われているのです.

      言い換えると,まだ当たり前の域には到達してないから,python の処理系には伸びしろがあります.
      たとえば2022年10月にリリースされたPython 3.11は 3.10に比べて10~60%高速になってます.
      3.11の高速化はまさに上記のバイトコードを効率よく実行する仕組みの改良で
      https://github.com/markshannon/faster-cpython [github.com] の成果です.このプロジェクトの中の人たちも,まだ伸びしろがあると言っています.

      ここで注意すべきは,pythonはバージョンが3.11まで進んでるのに,これからも性能向上が見込める点です.それくらい今のpython処理系はクソなのです.

      親コメント
      • by Anonymous Coward

        >それくらい今のpython処理系はクソなのです.
        処理系というか、言語仕様からの"実行"の難しさだよね。
        それを分かったうえで、木に竹を接ぐようなことをしている。
        やっている連中は面白いからやっているのだろうけど、
        まったく筋が悪いことをやっているような気がするけど
        x86アーキテクチャと同じでそこにニーズがあるからやっていられるんだろうなぁ
        こんなこと
        まあ、袋小路に入らないで行き着く先を見てみたいですけどね。

      • by Anonymous Coward

        わざわざ向いていないことをどうにかしようとするために時間を割くよりは
        向いていることをやったほうがいいよ。

        実行速度を求めるならRustで書けばいいとおもうのよね。

      • by Anonymous Coward
        >それくらい今のpython処理系はクソなのです

        いい内容の書き込みだなぁと思いながら読んでたのに、これで全て壊された。
      • by Anonymous Coward

        > 当然実行時には型の候補は有限で,実際の型は実行時には一つになります,ただし実行されるたびに型が変わる場合もあります.

        型推論が重いのは事実だが、アルゴリズム自体は30年前にselfコンパイラで提案されている。

        整数オーバーフロー検出も、実行時プロファイルのAOTコンパイラへのフィードバックと値範囲解析とCPUの投機実行により、オーバーフローしなかったパスの速度低下はかなり~完全に抑えられる。これも20年くらい前からある技術。

        • by Anonymous Coward
          もしかしたら、型アノテーションが単なる注釈ではなく、コンパイル時に使われるようになる、という可能性もあるのかな。
        • by Anonymous Coward

          しかしC言語は「整数オーバーフローしたときの動作は未定義です」(=コンパイラーは整数オーバーフローが発生したときのことを一切考えなくていい)というチートを繰り出すからそれでも勝てないんだよな

          • by Anonymous Coward

            「ほとんどの場合はワード長におさまるが、たまにオーバーフローして多倍長整数で計算しなければならない」ような場合ならPythonが有利になります。Cだとオーバーフローの検出ができないので、ソフトウェア的に判断するか、最初から多倍長で計算するしかない。

            • by Anonymous Coward

              ソフトウェア的に判断すると言ってもそれはPythonの言語機能がやっていることと同等以上だからそれをもってPythonが有利と言われても意味不明ですね。むしろPythonは必要がなくてもそのチェックを外せない

              • by Anonymous Coward on 2023年03月14日 23時41分 (#4426842)

                たとえばx86にはオーバーフローフラグがあって、整数演算でセットされるから、次の命令で条件分岐するだけです。PyPyもそうしている。意味不明に思えるのはただの無知。
                加算がオーバーフローしうるなら

                add eax,edx
                jo _handle_overflow_and_switch_to_bignum

                高頻度パスには条件分岐だけ付け加えればよくて、これは投機実行でコストはほぼ0になる。
                ごく単純な仕組みだが、Cは言語レベルではオーバーフローを扱えないので生成不可能なコードになる。

                親コメント
              • by Anonymous Coward

                >> Cは言語レベルではオーバーフローを扱えないので生成不可能なコードになる。

                ずいぶん言語拡張されてるんだからオーバーフローで分岐できるような記述を追加すればいいのにね。
                構造化アセンブラなんて言われ方も有るんだし。

              • by Anonymous Coward on 2023年03月15日 0時59分 (#4426867)


                add eax,edx
                jo _handle_overflow_and_switch_to_bignum
                ... ; use eax

                高頻度パスがこうだとすると、オーバーフローハンドラは「オーバーフローしうる演算」それぞれと一対一で用意しますが、コードサイズは大きくなく、所詮一回しか実行しません(どれかが一つオーバーフローすると、全体をbignumで処理するコードに切り替えます)。
                オーバーフローしたという情報と、それを起こした演算についての知識から、正しい演算結果をbignumで構成することができます。x86なら乗算結果はedx:eaxに入ります(x64も同様)。それからbignum版のルーチンに移行して、戻ってきません。

                配列のインデックスなどはvalue range analysisという古くからある技術で、ワードに収まることがわかる場合がほとんどです。たとえばポインタと加減算するための値なら、決してオーバーフローはしません。これは大域的な解析なのでコンパイルは重くなります。

                親コメント
    • by Anonymous Coward

      当たり前ではないよ。
      Objective-CとかC/C++より遅いでしょ。

    • by Anonymous Coward

      Pythonは変数に型指定がないし多倍長整数を扱っているのでそれが速度にどれくらい影響するか。
      CやC++は、32ビットとか64ビット全体を整数を表現するために使い、オーバーフローは気にしない
      という実装ができるけど、Pythonではそうはいかないわけで。

      • by Anonymous Coward

        型指定はあるよ。入れたデータで型が指定される。
        動的型付け言語が静的型付け言語かの違い。

        まともな知識がないプログラマだと動的型付け言語には型がないと思ってる人がちらほらいる。

  • by Anonymous Coward on 2023年03月14日 15時31分 (#4426527)

    かなり前に「Lispを手続き型にしたらPythonになる」という記事を読んだことがある。
    Lispも速度の遅い言語で、コンパラを通しても思った程の速度は出なかったけど、今度のはどうだろう。
    (昔ABC言語なる良さげなプログラム言語を見付けて調べようと思ったら、その開発者が「あれは失敗だった」ってことで新しく作ったのがPythonだったのを知ってガクっと来た)

  • by Anonymous Coward on 2023年03月14日 15時37分 (#4426532)

    名前をOyaCodonと改名して頂きたい

    • by Anonymous Coward

      名前をOyaCodonと改名して頂きたい

      母と娘を何と見做すかそれが問題だ(マテ

  • by Anonymous Coward on 2023年03月14日 15時49分 (#4426540)

    Cを経由せずに直接コンパイルすることだけ?

  • by Anonymous Coward on 2023年03月14日 17時23分 (#4426614)

    実行時間のほとんどはC/C++で書かれたモジュールのものじゃないのか

    • by Anonymous Coward

      Python書き慣れるとそんなに遅くなく書けますよね。
      なんというか遅いコーディングを避ける方法がそれなりにある。

      • by Anonymous Coward

        Python特有のものってあるの?

  • by Anonymous Coward on 2023年03月14日 18時31分 (#4426648)

    昔からやってる技術だと思うのだけれど
    大騒ぎするような技術的課題が有ったのだろうか

    • by Anonymous Coward

      あの頃のBASICは、変数の型が浮動小数点と文字列しかなくて、名前空間も別れていたような気がするので、Pythonのように変数や引数の型が実行前に分からないということがなかったんじゃないかな。

      • by Anonymous Coward

        int%、single,double#,str$ だったかなぁ
        型はそれぞれありましたね。
        面倒なのは文字列が可変長なのでのGCだったような気が
        あとは配列長も実行時解決だったかしら
        とりあえずDEFINT A-Zで早くなるおまじないw

        • by Anonymous Coward

          配列はデフォルトで使えるのが10までで、それ以上使いたければDIM宣言が必要じゃなかったっけ?
          コンパイラとしてはDIMなしの配列が出てきたら何も考えずに10まで確保するのだと思う。

      • by Anonymous Coward

        ていうか64KBが大容量メモリだった時代にソースコードとバイナリを別々に保存するなんて贅沢が許されるわけがない。マイコンの言語がインタープリターだったのは必然

  • by Anonymous Coward on 2023年03月14日 19時26分 (#4426682)

    Python自身をコンパイルできるようになってからが本番

    • by Anonymous Coward

      OSが書けるようになってようやく一人前

      • by Anonymous Coward

        OSが書けるようになってようやく一人前

        いや待つんだsystemd-pythonになる方が先だろう

  • by Anonymous Coward on 2023年03月15日 1時00分 (#4426868)

    CoDen is new answers.

    という、かつてのNTTコミュニケーションズの思い出した。

    Think different.

    とどっちが先でしたっけ?

    • by Anonymous Coward

      NTTコミュニケーションズの「コピーを」思い出した。すみません。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...