50
汎用kumAGI @kumagi
PythonのJITコンパイラを実装するだけなら実装に用いる言語はPythonである必要は無いわけだけれど、Rubiniusといいその言語の処理系をその言語自身で作ることの意義って具体的に何があるんですか?実行の為にCPythonやCRubyを別に必要とすると考えると欠点しか…?
ぽんこつ@本骨システム @ponkotuy
pypyはPythonの実行環境をPythonで作ってる。ある言語の実行環境をその言語そのもので実装することは意義がある、って言ってたな、pypyでは [Mimas]
汎用kumAGI @kumagi
@ponkotuy 意義がある、という発言までは聞いたことがあります。その意義がわからないだけで。
ぽんこつ@本骨システム @ponkotuy
@kumagi むー、言語の実用性を保証する、とかかなぁ?
汎用kumAGI @kumagi
@ponkotuy それならPythonによるRuby処理系やRubyによるPython処理系が有っても不思議はないのに見かけないのは一体?
ぽんこつ@本骨システム @ponkotuy
@kumagi うーん、PythonistaがPythonの処理系実装するのにRuby選ぶのは不思議なんだけどなーw PythonistaがRubyの処理系実装したくなるか、っていうのも含めて
汎用kumAGI @kumagi
@ponkotuy 好みの問題、という事ですか?
ぽんこつ@本骨システム @ponkotuy
@kumagi じゃないかな。言語の選択ってある程度絞ったらあとは好みの問題、っていう側面結構ありそうだし、RubyとPythonの違いを考えると尚更
rayfill @rayfill
@kumagi より高級な言語で実装することでいろんな概念の実装が楽にできるメリットとかはあるんじゃないでしょうか?
汎用kumAGI @kumagi
@rayfill 実装が楽にできても遅くなったら意味がないですしJITコンパイラを作るのが楽だとは思えないです。
kinaba @kinaba
@kumagi 「今さらCとかの低級言語で言語処理系書くのしんどい書きたくない」という問題を解消するという意義があるのでは。では処理系を記述する言語に何を選ぶかというと、Pythonの処理系作る人の得意な言語はPythonでしょうし、Rubyも然りで。他の言語選ぶよりも自然な気が
natsutan @natsutan
@kinaba あーそれで俺LispはLispで書かれるのか。ちょっと目から鱗。
汎用kumAGI @kumagi
@kinaba 「処理系の実装のハードルを下げる」という事でしょうか。個人的にはC言語でPython処理系を書くよりもPythonでPythonのJITコンパイラを書くほうがしんどいんじゃないかと想像するのですが。
kinaba @kinaba
@kumagi え、そうでしょうか。Cで書くよりもPythonで書く方が難しくなるポイントがあまり思い当たらないのですが (型がない…とかは好みの問題だと思うのでさておくとして)。
汎用kumAGI @kumagi
@kinaba 同じものを作り上げるなら遙かにPythonの方が簡単だと思いますが、それでもJITコンパイル付き処理系を書くというのはハードルが更に高そうに見えます。元よりJITコンパイラを作りたくて、その為の一番簡単そうな選択肢がその言語自身、という事でしょうか。
SODA Noriyuki @n_soda
@kinaba @kumagi レキシカルアナライザだけは、Cで書いた方がPythonより簡単なような(Cは十分速くて、素直に書けばOKなので)。もっとも、Java VMくらいの速度が出れば素直に書くのに十分な性能なので、僕がPythonの性能を見くびりすぎかもしれませんが。
GNUE(鵺) ☘ @gnue
@finalfusion @natsutan @kinaba @kumagi ん、もともとは缶切り(別の言語やコンパイラ)がなくても缶が開けるようにってことだと思ったけど。ま、Python の JIT がそこまで考えてやってるかどうかは知らないけど
中村 実 @nminoru_jp
@kumagi @rayfill hogehogeランタイムのJITコンパイラをhogehoge言語で書いてhogehogeランタイム上で動作させることによって、JITコンパイラ自身もJITコンパイルされて高速化されるのです (`・ω・´)
kinaba @kinaba
@kumagi PyPyは必ずしもPython処理系だけじゃなくて「JITコンパイラつき処理系をお手軽に作るためのランタイム」なので、それが作りたいものであって、「そのお手軽に作るための記述言語」はどうせなら自分自身にしておいた方が自分自身も高速化できるし悪くないと思うのです
汎用kumAGI @kumagi
@kinaba 特定の処理系に依存しないJITコンパイラ!!そんな途方もないものを作ってたんですね。なるほど、氷解しました。ありがとうございます。
kinaba @kinaba
@kumagi Prolog とか JavaScript (のサブセット) とか Brainfuck とか色々処理系がPyPyのレポジトリか別レポジトリだったかに入ってます (Pyrologについては割と色々資料も http://t.co/2JHs72P0)
汎用kumAGI @kumagi
@kinaba な、なにこれすごい怖い…!
残りを読む(9)

コメント

順三朗 @junzabroP 2011年11月2日
もともとPyPyの作者が以前からPythonのJIT駆動による高速化に取り組んでおり、PyPyによってPythonのself hostingを実現し、Pythonの仕様改善に貢献したという経緯をkumagiさんは勉強してから発言したほうがいいと思う。
汎用kumAGI @kumagi 2011年11月2日
理解してからだと逆に「なんでだろう?」という発言をできないと思うので、つまりこういうまとめが発生するような事態をそもそも作るべきではないということでしょうか?
順三朗 @junzabroP 2011年11月2日
一知半解ということで、周りの人から断片的に情報を得ても、一次情報に当たらないとその実態がつかめないことがよくあります。今回のPyPyの件では、公式サイトをざっと読んだほうが理解が進んだのではないでしょうか。
順三朗 @junzabroP 2011年11月2日
つぶやくことにもまとめることにも意義があり、それを否定しているわけではありません。ただ、人から話を聞いて分かったつもりになるというのも怖いよね、という話がしたかっただけです。
汎用kumAGI @kumagi 2011年11月2日
すいません、その意図をまとめると「勉強してから発言したほうがいいと思う」という事になるのでしょうか?
Tsuyoshi CHO @tsuyoshi_cho 2011年11月3日
さらにいうと、PyPyは場合によってCPythonより早くなる、という結果がでてたような(ああ、ソース探すorz)
汎用kumAGI @kumagi 2011年11月3日
@tsuyoshi_cho ありがとうございます。今でも手元でvirtualenvを用いてCPythonとPypyをとっかえひっかえしながらベンチマークを取って遊んでいます。4倍ほど速くなるケースもあって面白いです。
ログインして広告を非表示にする
ログインして広告を非表示にする