Mailman 3 March 2011 - pypy-dev

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton March 9, 2011

March 9, 2011

Thank you very, very much. I am sorry if I was short with you last night, I was very tired. This is great. I am fine with saying that the geometric mean is X times faster. I'd like to come up with a good way to say that we are faster on real programs, not just contrived examples, but this will take work and thought. Maybe some of the people who are on this list but not at pycon can come up with something. Thank you very much. I'm very happy now. Laura

2 1

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton March 9, 2011

March 9, 2011

In a message of Tue, 08 Mar 2011 20:20:06 +0100, Miquel Torres writes: >Ok, I just committed the changes. > >They address two general cases: >- You want to know how fast PyPy is *now* compared to CPython in >different benchmark scenarios, or tasks. >- You want to know how PyPy has been *improving* overall over the last re >le= >ases > >That is now answered on the front page, and the reports are now much >less prominent (I didn't change the logic because it is … [View More]something I >want to do properly, not just as a hack for speed.pypy). >- I have not yet addressed the "smaller is better" point. > >I am aware that the wording of the "faster on average" needs to be >improved (I am discussing it with Holger even now ;). Please chime in >so that we can have a good paragraph that is informative and short >enough while at the same time not being misleading. > >Miquel The graphic is lovely. you have a sÃpelling error s/taks/task/. Many of us are at PyCon now, so working on wording may not be something we have time for now. I am not sure that the geometric mean of all benchmarks give you anything meaningful, so I would have avoided saying anything like that. More specifically, I think that there is a division between some highly mathematical programs, where you might get a speedup of 20 to 30 times CPython, and the benchmarks whcih I find much more meaningful, those that represent actualy python programs -- where I think we are typically only between 2 and 3 times faster. The only reason to have some of the benchmarks is because they are well known. So people expect them. But doing very well on them is not actually all that significant -- it would be easy to write something that is great and running these contrived, synthetic benchmarks, but really lousy at running real python code. And I don't think that you can use the geometric mean to prove a thing with this. So I think talking about it makes us look bad -- we are making claims based on either bad science, or pseudo-science. And I want the 'lestest results' stuff gone from the front page. It's as misleading as ever. And I have done a poll of developers. it's not just me. Nobody finds it valuable. Because things stay red forever, we all ignore it all the time and go directly to the raw results of runs, which is what we are interested in. This also tells us of improvements, which we are also interested in, because unexpected improvements often mean something is very wrong. The whole thing has the same problem as those popup windows 'do you really want to delete that file? confirm y/n'. You get used to typing y. Then you do it when you meant not to save the file. The red pages get ignored for precisely the same reason. We're all used to all the red, which generally refer to problems which were already fixed, and thus are things that we _should_ ignore. So we end up ignoring it all, all of the time. So it therefore doesn't serve its purpose of reminding developers of anything. The general public, however, reads the thing and thinks -- latest results, pypy has just gone to hell, look at all those slowdowns. Explaining that they aren't current, or latest results, but instead 'sometime in the past when we were bad once' is getting irritating. Can you please move it someplace else so I don't have to have this conversation with pycon attendees any more? Later, when pycon is over, we can discuss and work out a better design for informing developers that a given build may have broken things. This way is not working. Laura [View Less]

5 9

[PATCH] Fix segmentation fault on parsing empty list-assignments
by Greg Price March 9, 2011

March 9, 2011

This same patch is on bitbucket at https://bitbucket.org/price/pypy, where I've sent a pull request. Holger Krekel suggested on IRC that I send mail here. If others have different preferences for how to submit a patch, let me know. Before this patch, "[] = []" would abort the interpreter, with a segmentation fault if in pypy-c. A segmentation fault is always bad, but in this case further the code is valid Python, if not very useful. (In my commit message on bitbucket, I incorrectly said it … [View More]

2 1

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton March 9, 2011

March 9, 2011

In a message of Wed, 09 Mar 2011 09:26:29 +0100, Miquel Torres writes: >I see. > >There is an easy solution for that, at least for the moment: enabling >zooming. I just did that, and you can now use zooming in a timeline >plot to select a narrower yaxis range or just view a particular area >in detail. A single click resets the zoom level. > >If that is not enough, we can discuss a better solution when you have mor >e time. This is terrific. Thank you very much. Laura

1 0

Basic math ops
by Timothy Baldridge March 9, 2011

March 9, 2011

In my interpreter, I have several primitive wrapper objects: IntObject, FloatObject, etc. Currently I'm planning to create functions for every combination: def add_int_float(i, f): return FloatObject(i.int_value() + f.float_value()) then I'd need some sort of dispatch code that would say if isinstance(arg1, IntObject) and isinstance(arg2, FloatObject): return add_int_float(arg1, arg2) It seems like pypy should have something to do this already. I saw some information on this but … [View More]

3 2

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton March 9, 2011

March 9, 2011

In a message of Tue, 08 Mar 2011 18:17:17 +0100, Miquel Torres writes: >you mean this timeline, right?: >http://speed.pypy.org/timeline/?ben=3Dspectral-norm > >Because the December 22 result is so high, the yaxis maximum goes up >to 2.5, thus having less space for the more interesting < 1 range, >right? yes > >Regarding mozilla, do you mean this site?: http://arewefastyet.com/ >I can see their timelines have some holes, probably failed runs... I was seeing … [View More]

2 1

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton March 9, 2011

March 9, 2011

In a message of Tue, 08 Mar 2011 09:10:32 +0100, Miquel Torres writes: >Hi, > >I finished the changes to the speed.pypy.org home page last night, but >alas!, I didn't have time to deploy. I will do it later today and will >then ping you back. > >The extra info provided is really nice as an overview, you will see ;-) > > Ah good. Thank you very much. We spent yesterday afternoon with the Mozilla engineers, and I got to talk to the person who maintains the benchmarks … [View More]

6 7

Amusing graph
by Dan Stromberg March 8, 2011

March 8, 2011

I thought there might be some people here who'd be interested in this graph: http://stromberg.dnsalias.org/~dstromberg/backshift/ It shows pypy performing very well when compared to a number of other Python runtime systems, including cpython+cython (2 and 3) and cpython+psyco (just 2 of course). It's just one part (the critical section) of one application, but still...

1 0

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton March 8, 2011

March 8, 2011

In a message of Fri, 04 Mar 2011 19:34:15 +0100, Miquel Torres writes: >Hi, > >just a quick note to Laura and the rest to let you know that I am >working on the issues you raised, and expect to have everything nailed >down this weekend, just in time for PyCon. > >Miquel Thank you very much. Laura

2 1

GIL in non-Python languages
by Timothy Baldridge March 7, 2011

March 7, 2011

I'm in the process of writing a PyPy based Clojure interpreter/JIT. One of the man tenants of Clojure is immutability, and one of the other tenants is extreme co-currency. Starting soon I'd like to start experimenting with co-currency in my interpreter. For those who aren't familiar with Clojure, let me give an example: (def my-agent (agent "Hello")) (send my-agent #(str %1 " World")) Send then takes the current state of my-agent and then calls the given lambda function, passing it the … [View More]

3 3