Hi Dima, > 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.
Well, speed.pypy is actually fast in all modern browsers. The problem you are referring to is probably caused by a bug in the javascript plotting library (jqPplot) that is triggered in the comparison view when there are some results with 0 values. It only appears for some plot types, but it is very annoying because it grinds the browser to a halt like you say. Is that what you meant? We are looking into it, and will fix that library if necessary. Cheers, Miquel 2010/12/21 Dima Tisnek <[email protected]>: > On 20 December 2010 19:21, William ML Leslie > <[email protected]> wrote: >> On 21 December 2010 11:59, Dima Tisnek <[email protected]> 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 > > 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 >> > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
