PyPy3 2.4.0を使ってみた - 偏った言語信者の垂れ流し
最近、仕事でPyPy3を試したりしているので、メモを書き残しておく。 PyPy - Welcome to PyPy インストール 今回はUbuntu 14.04LTSで試した。PyPy3はPPAリポジトリに無いので、Linux向けのコンパイル済みバイナリをダウンロードして使うことにした。 利用するときは、virtualenvでpypy3用の環境を作っている。 $ wget https://bitbucket.org/pypy/pypy/downloads/pypy3-2.4.0-linux64.tar.bz2 $ bzip2 -dc pypy3-2.4.0-linux64.tar.bz2|tar xf - $ sudo mv pypy3-2.4.0-linux64 /opt/ $ sudo ln -s /opt/pypy3-2.4.0-linux64/bin/pypy3 /usr/bin/
偏った言語信者の垂れ流し
Djangoフレームワークのテンプレートの継承について、基本的な内容です。 base.html というファイルを作って、共通部分をまとめる話。 検索用に記事をまとめておきます。 ※この記事は 力強くアウトプットする日の 20240301 のアウトプットです。 テンプレートの継承 Djangoのドキュメントに例と説明があります。 テンプレートの継承 - Djangoドキュメント Djangoのテンプレートには『継承』という仕組みがあります。 どのようなときに利用するか HTMLでウェブサイトを作る場合、複数のページでヘッダー部とフッター部を共通にすることがよくあります。 また、サイドバー、レイアウトなど、複数ページに渡って共通の構造とするパターンがとても多いです。 こうした構造のときにテンプレート継承がうまくハマります。 例 base.html: <html> <head> <meta ch
PyPy を本番に導入した
計画したのは半年以上前、検証は 2 ヶ月かかった。 結果的には CPU 使用率は半分になり性能は倍になった。もちろん、本番で、だ。 これから徐々に CPython 環境を PyPy 環境へと置き換えていく。PyPy の最大の魅力はその性能だろう。性能が大きく上がるため、既存環境にかかっているサーバ費用を削減することが出来る。 ただ、注意して欲しいのは PyPy はとてつもなくメモリーを消費する。 Python 環境でパフォーマンス向上を狙うには PyPy はとてもよい選択肢だと思う。とても安定しているし、互換性が本当に高い。 Python + Django という環境で、2 倍性能を上げることはそうそう出来ない。 ただ、PyPy が最後の砦ではあるので、これ以上のパフォーマンスを望む場合は言語を変更する必要がある。Golang なのか Elixir なのか。 PyPy を導入したことで、次
RPythonを用いたPyrlangのいくつかの実験
PyrlangはRPythonで書かれたErlang BEAMバイトコードインタープリタです。 Pyrlangでは、BEAMの約２５％の命令を実装しました。現在Pyrlangがサポートしている機能は、整数の計算、クロージャ、例外処理や、アトム（atom）、リスト、組みへのいくつかの操作、ユーザーモジュール、及びシングルコア上のマルチプロセスです。Pyrlangはまだ開発している最中です。 BEAMとPyPyのVMには、いくつか違うところがあります： • BEAMはレジスタVMですが、PyPyのVMはスタックVMです。 • BEAMには、伝統的なコールスタックがありません。BEAMのYレジスタの振る舞いとコールスタックと似ていますが、時折他の変数を保存することもあります。 • BEAMには、言語レベルとOSレベルのスレッドがありません。言語レベルのプロセスのみを持っています。このような
そして PyPy へ
もう仕事で Python を触ることはテストくらいしか無いだろうと思っていたところに、ふと面白い相談をされた。 PyPy を使った既存の Python アプリケーションの高速化だ。PyPy は簡単に言ってしまうと早い Python で、JIT 使ったりしてる。 問題がそもそも処理速度が遅いとかその辺だったので Golang とかに書き換えればいいのだが、コスト面から言ってちょっと距離があるので、いい機会だということでほとんどコードを書き換えずに済む PyPy を使って見ることにした。 Python アプリと言っても JSON 受け取ったり戻したりするウェブアプリなので、たいした構成では無い。 Nginx + uWSGI + PyPy 2.5.0 + Django 1.7 + PyMySQL + MySQL 5.6 PyPy 2.5.0 がちょうど出て、PyMySQL もこなれて来た事を教え
初めての RPython Toolchain - Elliptium
タイトルは釣りっぽく見えるかもしれませんが, 理論にばっかり興味あったので, RPython をちゃんと触るのは初めてです. 発端 理論派で手を動かすのが億劫な俺が実装書いてみようと思った動機は, PyPy Sudden Death Calendar 27日目 - JVM Backend に完敗した件を受けて にある話にあります. ここでは ootype によって JVM 用に変換されたクラスがしっちゃかめっちゃかだ, ということを追っています. なんでこんなことになっているのか分からないので, まずは簡単なインタプリタを例に RPython Toolchain の動きを追っていく計画です. プログラム仕様 このプログラムの仕様はすごく簡単で, 各行の先頭に暗黙の echo があるものとして動作します. プログラミング言語 ECHO とでも呼びましょうか. 実装 さっきのブログエントリの筆
流行りのJITコンパイラは嫌いですか? — PyPy Advent Calendar 2011 v1.0 documentation
流行りのJITコンパイラは嫌いですか?¶ PyPy Advent Calendar 12/23担当の RYO @ 修論提出1ヶ月前です。 いよいよ明日はクリスマスイブですね。 リア充の方もそうでない方も、当記事に目を留めて頂き誠にありがとうございます。 本記事では、他の皆さんが扱われているような実用的なネタとは異なる PyPyの内側の話、特にPyPyのJITコンパイラに関する話題を扱いたいと思います。 したがって、本記事の情報は業務等の役にはまったく立ちませんのでご容赦願います。 さて、この記事をお読みになっている方々の殆どは、 PyPy = JITのおかげで早くなった事で有名なPythonの処理系 という認識をお持ちだと思います。 確かにこの認識は間違ってはいないのですが、 実はPythonにJITを乗せる事で高速化を図る処理系はPyPyだけではなく、 その殆どがPyPyが今程の有名なも
Shibu's Diary: RPythonを使ってechoサーバを作る
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by brewbooks under CC BY-SA PyPy Advent Calenderの第二回目のバトンが回って来ました。こんかいは時間がないので、さらっと。 RPython用のライブラリ、rlibを探る冒険その2 rlibを探検してみるエントリーの第二弾です。アドベントカレンダーの中では、shomah4aさんがclibffiというモジュールを使って、Cで書かれたライブラリの関数を呼び出していました。 初めての方もいるかもしれないので、軽く関連情報をおさらいしてみましょう PyPyは、Pythonで書かれたPythonインタプリタである。 Pythonで書かれたといっても、CPythonの上で実行されるわけではなく、RPython Toolchainという
PyPy Advent Calendar 15日目 - 低レベルっぽいことをやってみる - プログラマのネタ帳
PyPy Advent Calendar 15日目を担当する二周目の[twitter:@shomah4a]です。だんだんとネタもなくなってきました。 でもね、 rlib 探すと色々面白いものがあるんだね。 というわけで今回はなんとなく目についた pypy.rlib.clibffi についてです。 ※まとめのあとに追記しました ※libm っておかしくね? って言われたので修正。動いていた理由は不明 ffi ってなによ? ffi とは、Foreign Function Interface と呼ばれるもので、日本語に訳すと他言語関数インタフェイスというらしいです。 要は別の言語の関数を呼び出すための仕組みです。 clibffi の場合は Python から C の関数を呼ぶものです。 そもそも C の関数を呼べないことにはソケット通信もできませんし、スレッドも立てられません。 この clibf
RPython can be faster than C
(yes, C as in language, not c as in speed of light). I looked recently at the great computer language shootout, for some benchmarks and to make some speed comparisons. I use this benchmark, modified it to be rpythonic-enough and compared speeds. The code is here (the only change from the Python version was to create a class instead of tuple, so actually this version is more OO). Also the benchmark
Shibu's Diary: PyPyよりも5倍高速な最速のPython処理系
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 今出張で、サン・フランシスコに来ています。街はもうクリスマスムードで、楽しげな雰囲気がただよっています。期間限定のアイススケートのリンクが公園にできていたり、ngmoco:)のオフィスの入っているビルにもイルミネーションが飾られていたりします。 PyPy advent calendar に参加しています。@aodagからバトンを受け取りました。今日のこのネタはアドベントカレンダーの記事です。 PyPyはご存知でしょうか？その怪しげな(Pythonらしくイヤラシい)名前にもかかわらず、なんだかよく分からないパフォーマンスを叩き出しているPython処理系です。1.6でもすでにCPythonよりも早かったのですが、1.7ではさらに改善されています。 ですが、このPyPyよりも速いP
Plotting using matplotlib from PyPy
Big fat warning This is just a proof of concept. It barely works. There are missing pieces left and right, which were replaced with hacks so I can get this to run and prove it's possible. Don't try this at home, especially your home. You have been warned. There has been a lot of talking about PyPy not integrating well with the current scientific Python ecosystem, and numpypy (a NumPy reimplementat
Python in Python: The PyPy System
(March 2, 2011) Armin Rigo discusses the research he has done to implement Python in Python. The new project, titled PyPy, can increase the speed at which programs run, as well as reduce the total memory that they use. He hopes that it can help advance the field of computer science as we move deeper into the 21st century. Stanford University: http://www.stanford.edu/ School of Engineering: htt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PyPy Build
Emerge Technology: pypy1.7は本当に速いのか?もう一度試してみた