[pypy-dev] funding/popularity?

Dima Tisnek dimaqq at gmail.com
Tue Dec 21 22:22:15 CET 2010


yes, same problem, but the grind is not so aweful, surviveable even,
tried with opera and normal ff

On 21 December 2010 12:30, Miquel Torres <tobami at googlemail.com> wrote:
> It is weird that it happens as you de-select benchmarks.
>
> Does it happen with non-beta browsers?
>
>
> 2010/12/21 Dima Tisnek <dimaqq at gmail.com>:
>> Yes it does grind ff 4b7 to an almost halt, little cpu usage,
>> reasonable memory size and constant disk activity for several minutes,
>> very weird...
>> So far, the difference between browsers is so large that I doubt it's
>> dependent on data.
>> Also it seems to tirgger as I remove columns progressively, thus new
>> zero values should not appear, right?
>>
>> I'll invesitage some more...
>>
>> On 21 December 2010 01:06, Miquel Torres <tobami at googlemail.com> wrote:
>>> 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 <dimaqq at gmail.com>:
>>>> On 20 December 2010 19:21, William ML Leslie
>>>> <william.leslie.ttg at gmail.com> wrote:
>>>>> On 21 December 2010 11:59, Dima Tisnek <dimaqq at 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
>>>>
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> pypy-dev at codespeak.net
>>>> http://codespeak.net/mailman/listinfo/pypy-dev
>>>
>>
>



More information about the Pypy-dev mailing list