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.js: Now faster than CPython
OK OK, I couldn't resist that title but it probably goes a bit far. Let me try for a little more nuance: PyPy.js: Now faster than CPython, on a single carefully-tuned benchmark, after JIT warmup. It has been the better part of a year since I first started hacking on PyPy.js, an experiment in bringing a fast and compliant python interpreter to the web. I've been pretty quiet during that time but ha
PyPy.js Update: A Proof-of-Concept JIT
Two weeks ago I hatched a plan to port Python to the Web Platform by using Emscripten to translate PyPy into JavaScript. My hope is to produce something than can run in the browser with performance comparable to a standard Python interpreter, a hope which hinges on two key ingredients: PyPy's powerful just-in-time compiler, which can optimize the hot loops of your program into efficient native cod
PyPy.js: First Steps
I've been spending a lot of time in JavaScript land lately. It's not totally unexpected – when I first applied for a job with Mozilla, I was warned only semi-jokingly that "they hire all the best Python programmers and then force them to write JavaScript". I've no deep love or hate for it as a language, but JavaScript is pretty interesting to me as a platform, as a kind of runs-everywhere lowest-c
PyPy 2.1 beta
We're pleased to announce the first beta of the upcoming 2.1 release of PyPy. This beta contains many bugfixes and improvements, numerous improvements to the numpy in pypy effort. The main feature being that the ARM processor support is not longer considered alpha level. We would like to thank the Raspberry Pi Foundation for supporting the work to finish PyPy's ARM support. You can download the Py
10 years of PyPy
From a software engineering perspective, 10 years is indistinguishable from infinity, so I don't care what happens 10 years from now -- as long as you don't blame me. :-) - Guido van Rossum, Python creator. 10 years is indeed a long time. PyPy was created approximately 10 years ago, with the exact date being lost in the annals of the version control system. We've come a long way during those 10 ye
Wikipedia processing. PyPy vs CPython benchmark — Robert Zaremba blog
Wikipedia processing. PyPy vs CPython benchmark Lately I’ve done some data mining tasks on Wikipedia. It consist of: processing enwiki-pages-articles.xml Wikipedia dump storing pages and categories into mongodb using redis for mapping category titles I made a benchmark on a real tasks for CPython 2.7.3 and PyPy 2b. Libraries I used: redis 2.7.2 pymongo 2.4.2 Furthermore CPython was supported by: h
Stand back... I'm going to try science! : Blog – @kgriffs
Slow Website? Check out Luhnar for an easy way to speed up your client's Django, WordPress, or other CMS-based or custom site. www.luhnar.com The majority of benchmarks posted on the web are derived from testing simple “hello world” apps. Although certainly better than nothing, these tests tell us little about real-world performance. Ideally, one would compare multiple implementations of a non-tri
Announcing Topaz, an RPython powered Ruby interpreter
Announcing Topaz, an RPython powered Ruby interpreter Hello everyone Last week, Alex Gaynor announced the first public release of Topaz, a Ruby interpreter written in RPython. This is the culmination of a part-time effort over the past 10 months to provide a Ruby interpreter that implements enough interesting constructs in Ruby to show that the RPython toolchain can produce a Ruby implementation f
Topaz, a new Ruby written in Python on top of RPython
From the announcement blog post: Topaz is written in Python on top of the RPython translation toolchain (the same one that powers PyPy). Its primary goals are simplicity and performance. Because Topaz builds on RPython, and thus much of the fantastic work of the PyPy developers, it comes out of the box with a high performance garbage collector, and a state of the art JIT (just-in-time) compiler. W
PyPy 2.0 beta 1
We're pleased to announce the 2.0 beta 1 release of PyPy. This release is not a typical beta, in a sense the stability is the same or better than 1.9 and can be used in production. It does however include a few performance regressions documented below that don't allow us to label is as 2.0 final. (It also contains many performance improvements.) The main features of this release are support for AR
Py3k status update #7
This is the seventh status update about our work on the py3k branch, which we can work on thanks to all of the people who donated to the py3k proposal. The biggest news is that this month Philip started to work on py3k in parallel to Antonio. As such, there was an increased amount of activity. The py3k buildbots now fully translate the branch every night and run the Python standard library tests.
Multicore Programming in PyPy and CPython
Hi all, This is a short "position paper" kind of post about my view (Armin Rigo's) on the future of multicore programming in high-level languages. It is a summary of the keynote presentation at EuroPython. As I learned by talking with people afterwards, I am not a good enough speaker to manage to convey a deeper message in a 20-minutes talk. I will try instead to convey it in a 250-lines post... T
NumPyPy progress report - running benchmarks
An important thing to notice is the data dependency of the inline version causes a huge slowdown for the C versions. This is not a severe disadvantage for us though -- the brain-dead Python version takes longer and PyPy is not able to take advantage of the knowledge that the data is independent. The results are in the same ballpark as the C versions -- 15% - 170% slower, but the algorithm one choo
PyPy Sudden Death Calendar 27日目 - JVM Backend に完敗した件を受けて - プログラマのネタ帳
昨日の PyPy Sudden Death Calendarにて[twitter:@rokujyouhitoma]総帥が挑戦した PyPy の JVM Backend での失敗と、その後の Skype での議論をまとめて一エントリまかなえそうです。 なのでとりあえず書いてみました。 PyPy Sudden Death Calendar 27日目です。 そもそも何で失敗したの? 失敗したときのログはこんな感じ。 (_)ike-no-MacBook-Air% java -jar ./ook-jvm.jar Exception in thread "main" java.lang.VerifyError: (class: pypy/ConstantInit_0, method: constant_init signature: ()V) Expecting to find long on sta
jvmバックエンドに完敗 PyPy Advent Calendar 26日 + 1日目（27日目？） - rokujyouhitoma's blog
まさかのPyPy Advent Calendar 2011 26日 + 1日目（27日目？）。 この記事はaodagさんのpypy cliバックエンドに完敗 aodag's posterousにインスパイヤされて書かれてます。 結論書くとjvmバックエンドに完敗:( 追記 この記事での敗北はid:shomah4aさんが勝利を収めました。 下記がそのまとめ記事です。 PyPy Sudden Death Calendar 27日目 - JVM Backend に完敗した件を受けて プログラマのネタ帳 事前準備 以前、PyPyのRPythonToolChainで実装したOok!を使います。 hg clone https://bitbucket.org/rokujyouhitoma/lang-ook PyPyでOok!を実装してみた。 rokujyouhitomaの日記 RPythonToolCh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why shouldn't I use PyPy over CPython if PyPy is 6.3 times faster?
『RPythonで書かれたRuby処理系Topazで遊ぶ』へのコメント
Welcome to Topaz — Topaz 0.1 documentation
Python performance the easy(ish) way