pypy-dev

Download

pypy-dev@python.org

January 2011

28 participants
22 discussions

funding/popularity?
by Dima Tisnek Jan. 2, 2011

Jan. 2, 2011

On 20 December 2010 19:21, William ML Leslie <william.leslie.ttg(a)gmail.com> wrote: > On 21 December 2010 11:59, Dima Tisnek <dimaqq(a)gmail.com> wrote: >> More visibility for performance achievements would do >> good too. > > Where are pypy's performance achievements *not* visible, but should be? for example http://shootout.alioth.debian.org/ doesn't say which pypy version is used, what options, doesn't have performance figures for multithreaded/multicore … [View More]also benchmarks are kinda small, most of them are not docuemented, and I couldn't find any info if the same python code was used for cpython and pypy (both shootout and speed pypy) or interpreter-specific verions were used, that is each tweaked for best performance given the known tradeoffs for each implementation.further the most standard benchmarks, pystone, etc. completely ignore the fact that real world programs are large and only a few small paths are execured often. another temp problem with speed pypy is that it's terrubly slow in ff beta. it also occasionally grinds in stable ff and opera, but I guess this can be forgiven for the sake of simplicity / developer effort. if you google for 'python performance' you don't get a single link to pypy on the first page, as a matter of fact, codespeak is poorly indexed, it took me quite some time to get some of my questions answered with a search. also if you look up 'pypy gc' you get a page on codespeak, but to interpret what the data actually means is so far beyond me. a good overview is found in the mainling list http://codespeak.net/pipermail/pypy-dev/2010q1/005757.html then again slowspitfire and spambayes bits are outdated by now. the definitive good thing about pypy is that it's much easier to find out about its inner workings than that of cpython! hopefully a bit more of end-user stuff get known. let's call it pypy public outreach (feature request) > >> Sidetracking... one day when pypy jit/gc/etc are all worked out, how >> hard would it be to use same techniques and most of backends for some >> unrelated language that doesn't have jit yet, e.g. php? > > You know that pypy already has implementations of other languages, > right - Scheme, Javascript, Prolog, IO and smallTalk? They aren't > integrated with the translated pypy-c, but they show that it is not > too difficult to write a runtime for any dynamic language you choose. Oh I didn't know there were so many, and I mistakenly though that js was a target, not implmented langauge. In any case I read somewhere that js support was retired... > >> And how hard >> would it be to marry two dynamic languages, so that modules from one >> could be used in the other? Or that modules written in rpython could >> be used in several langs? > > It's in the "interesting problems" bucket, and the effort required > depends on the level of integration between languages you want. There > are several projects already attempting to do decent integration > between several languages, besides the approach used on the JVM, there > are also GNU Guile, Racket, and Parrot, among others. It might be > worth waiting to see how these different projects pan out, before > spending a bunch of effort just to be an also-ran in the > multi-language runtime market. > > However, implementing more languages in rpython has the side-effect of > propagating the l * o * p problem: it introduces more and more > implementations that then have to be maintained, so good > cross-language integration probably belongs /outside/ pypy itself, so > existing runtimes can hook into it. Makes perfect sense, after all any given other language hardly has the same data model as python. > > But it would be an interesting experiment (to marry the various > interpreters pypy ships with), if you wanted to try it. > > My two cents. > > -- > William Leslie > [View Less]

5 13

1.4.1 threading
by Dima Tisnek Jan. 1, 2011

Jan. 1, 2011

Hi, Somehow I'm getting exactly same performance in threaded and non-threaded code (I would expect at least some speedup), Is threading not there in this pypy release in practice or am I missing some argument to pypy? the test case is cpu-bound in python, and possibly gc-bound too

8 17