Mailman 3 March 2011 - pypy-dev

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 09 Mar '11

09 Mar '11

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 09 Mar '11

09 Mar '11

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 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

5 9

[PATCH] Fix segmentation fault on parsing empty list-assignments
by Greg Price 09 Mar '11

09 Mar '11

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 only affects invalid Python, like "[] += []".) Greg diff -r eb44d135f334 -r 0db4ac049ea2 pypy/interpreter/astcompiler/asthelpers.py --- a/pypy/interpreter/astcompiler/asthelpers.py Tue Mar 08 11:14:36 2011 -0800 +++ b/pypy/interpreter/astcompiler/asthelpers.py Wed Mar 09 03:26:54 2011 -0800 @@ -40,9 +40,10 @@ return self.elts def set_context(self, ctx): - for elt in self.elts: - elt.set_context(ctx) - self.ctx = ctx + if self.elts: + for elt in self.elts: + elt.set_context(ctx) + self.ctx = ctx class __extend__(ast.Attribute): diff -r eb44d135f334 -r 0db4ac049ea2 pypy/interpreter/astcompiler/test/test_compiler.py --- a/pypy/interpreter/astcompiler/test/test_compiler.py Tue Mar 08 11:14:36 2011 -0800 +++ b/pypy/interpreter/astcompiler/test/test_compiler.py Wed Mar 09 03:26:54 2011 -0800 @@ -70,6 +70,9 @@ st = simple_test + def error_test(self, source, exc_type): + py.test.raises(exc_type, self.simple_test, source, None, None) + def test_long_jump(self): func = """def f(x): y = 0 @@ -98,11 +101,13 @@ self.simple_test(stmt, "type(x)", int) def test_tuple_assign(self): + yield self.error_test, "() = 1", SyntaxError yield self.simple_test, "x,= 1,", "x", 1 yield self.simple_test, "x,y = 1,2", "x,y", (1, 2) yield self.simple_test, "x,y,z = 1,2,3", "x,y,z", (1, 2, 3) yield self.simple_test, "x,y,z,t = 1,2,3,4", "x,y,z,t", (1, 2, 3, 4) yield self.simple_test, "x,y,x,t = 1,2,3,4", "x,y,t", (3, 2, 4) + yield self.simple_test, "[] = []", "1", 1 yield self.simple_test, "[x]= 1,", "x", 1 yield self.simple_test, "[x,y] = [1,2]", "x,y", (1, 2) yield self.simple_test, "[x,y,z] = 1,2,3", "x,y,z", (1, 2, 3)

2 1

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 09 Mar '11

09 Mar '11

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 09 Mar '11

09 Mar '11

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 that seemed specific to the Python interpreter. What's the recommended procedure on this? Is there a way to tell pypy "this object wraps a single value, so keep it unwrapped if you can", or does pypy figure that out automagically? Thanks, Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)

3 2

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 09 Mar '11

09 Mar '11

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 something else, and I don't have a url. I think that what I was seeing is what they use to make the arewefastyet.com site. >I see a problem with the approach you suggest. Entering an arbitrary >maximum yaxis number is not a good thing. I think the onus is there on >the benchmark infrastructure to not send results that aren't >statistically significant. See Javastats >(http://www.elis.ugent.be/en/JavaStats), or ReBench >(https://github.com/smarr/ReBench). I don't think you understand what I want. Sorry if I was unclear. I am fine with the way that the benchmarks are displayed right now, but I want a way to dynamically do there and say, I want to throw away all data that is higher than a certain figure, or lower than a certain one, because right now I am onoy interested in results in a certain range. I'm not looking to change what the benchmark says for everybody who looks at it, or change how it is presented in general. I just want a way to zoom in and only see results in the range that interests me. You and anybody else might have a different range that interests you, and you should be free to get this as well. >Something that can be done on the Codespeed side is to treat >differently points that have a too high stddev. In the aforementioned >spectral-norm timeline, the stddev "floor" is around 0.0050, while the >spike has a 0.30 stddev, much higher. A "strict" mode could be >implemented that invalidates or hides statistically unsound data. The problem is that I want to throw away arbitrary amounts of data regardless of whether they are statistically significant or not, on the basis of I know what I want to see, and this other stuff is getting in the way or being distractingÃ. >Btw., I had written to the arewefastyet guys about the possibility of >configuring a Codespeed instance for them. We may yet see >collaboration there ;-) > >Miquel Laura

2 1

Re: [pypy-dev] Change to the frontpage of speed.pypy.org
by Laura Creighton 09 Mar '11

09 Mar '11

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 for tracemonkey. He had timelines very much like ours. There is one feature he has that I would like to have. Take a look at the timeline for spectral.norm. There are two spikes there. Mozilla has lines like that too, though mostly it is because their jit decides that the whole benchmark is bogus and optimises out all the code. So it takes 0 time. oops. At any rate, aside from knowing that something went horribly wrong with that rev, you don't really need to know how wrong. And by making the graph display up to that point means that the dots where things really do matter get crammed closer together than would otherwise be the case. So he had a mode where things wehre displayed with an arbitrary value at the bottom (in our coase it would be the top) which he could specify. Then the graph would be replotted, with the outliers off the graph, but making it easier to read the dots for the more normal cases. Any chance we could do that too? Laura

6 7

Amusing graph
by Dan Stromberg 08 Mar '11

08 Mar '11

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 08 Mar '11

08 Mar '11

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 07 Mar '11

07 Mar '11

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 current state of the agent (%1 points to the first argument of the lambda). The lambda simply then concats the two strings together. So here's the deal. My entire interpreter is 100% thread safe. All my variables are either immutable, or local to the given function. But from what I'm hearing on IRC, it sounds like that a GIL will be automatically generated in my interpreter after I run it through PyPy. I know ripping the GIL out of Python is a major deal. But how about my project? If I start with the concept of a GIL-less interpreter, will PyPy get in my way? If so, how can I get it to "back-off" a bit? Thanks, Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)

3 3