Mailman 3 November 2011 - pypy-dev

Re: [pypy-dev] [pypy-commit] pypy ppc-jit-backend: setarrayitem and getarrayitem offsets are immediate values.
by Maciej Fijalkowski Nov. 16, 2011

Nov. 16, 2011

Unless I'm missing something offset for get/setarrayitem are not necesarilly intermediate values On Mon, Nov 14, 2011 at 9:27 PM, edelsohn <noreply(a)buildbot.pypy.org> wrote: > Author: edelsohn > Branch: ppc-jit-backend > Changeset: r49414:3a6600bf032a > Date: 2011-11-14 14:27 -0500 > http://bitbucket.org/pypy/pypy/changeset/3a6600bf032a/ > > Log: setarrayitem and getarrayitem offsets are immediate values. > > diff --git a/pypy/jit/backend/ppc/… [View More]

2 1

Detecting pypy vs cpython runtime
by Blaine Nov. 15, 2011

Nov. 15, 2011

Hi everyone. I have a cellular automata framework in C++ and I use cython and cpython to run it. I found out that if I port it to pure python and run it with pypy, it's close to the same performance as the C++ version. (about 2x as slow, compared to 20x as slow when using pure python + cpython). When I throw in other overheads with pure python libraries, using the pure python and pypy is much faster than cpython with the C++ library, all things equal. What I'd like to do is detect if pypy or … [View More]

3 4

Developer selection for Py3k and Numpy
by Carl Friedrich Bolz Nov. 15, 2011

Nov. 15, 2011

Hi all, Now that we are getting in some money for our Py3k [1] and Numpy [2] funding proposals (thank you very very much, for everybody who contributed!) it is time to think more concretely about the actual execution. Therefore I want to ask for PyPy developers that are interested in getting paid for their work on the first steps of the Numpy or Py3k proposals to step forward. To be applicable you need to be an experienced PyPy developer who worked in this area before (Numpy) or on the Python … [View More]

7 9

pypy now on pythonanywhere.com :)
by Harry Percival Nov. 10, 2011

Nov. 10, 2011

Howdy PyPy developers! Just a quick announcement - we've just made pypy (1.6) available as a console type on www.pythonanywhere.com (which is a browser-based console/ide/hosting thingummy*) <http://www.pythonanywhere.com> cheers, Harry * anyone who went to pycon uk might remember my "excitable" talk on the subject. anyone who went to europython might remember my "shockingly poor" talk on the subject... -- Harry Percival Developer harry(a)resolversystems.com +44 (0) 20 3051 2751 … [View More]

3 3

jit-targets
by Hakan Ardo Nov. 10, 2011

Nov. 10, 2011

Hi, the idea behind the jit-targets branch is to generalize the concept of unrolling into something that makes sens for bridges aswell. Below I try to describe the goals of this intention. The jit-targets branch will be a first step towards this goal. First, we need a new way to model traces. A trace now consists of several parts separated by a new ResOperation called LABEL. Labels are inserted into the trace at strategic places (different startegies could be inverstigated). The label has a … [View More]TargetToken descr that describes the place at which it is inserted. It includes * A list of all live variables (the label arguments) * A VirtualState describing the live virtuals * A short preamble that can be inlined to jump to the label A JUMP ResOperation now has a TargetToken as a descr and it will always jump to the label with the same TargetToken. Such a jump is only legal if the VirtualState at the jump matches the VirtualState of the TargetToken and the short preamble has been inlined. Each JitCellToken will contain a list of TargeTokens that corresponds to the same greenkey (but with different VirtualStates). When we produce a new trace, we will trace until we discover a JitCell with a JitCellToken. The VirtualState at the end of the trace is comapred to the VirtualState of all the TargetTokens listed. If one of them matches, it's short preamble is inlined to produce a jump to it. If none matches we insert a label into the trace and continue tracing. To handle traces that loop back on themselfs we make sure that a label is inserted at the merge point. For loops this will produce the same effect as unrolling, but with twice as much tracing as both the first and second iterations are traced. We can however detect such loops and inline the produced trace instead of continue traceing without chaning this new concept. Also it will make it straight forward to unroll into more than 2 iterations if that would make sens. The optimizeopt optimizer will be passed trace parts that can start and/or end with a label, but there with be no intermediate labels. If the trace-part ends with a label, the state of the optimizer that would previously be passed from the preamble to the loop will now instead be saved on this label. If the trace-part starts with a label the corresponding state will be imported from it. If a box produced in one trace-part is reused in the following trace-part it will be added as an argument to the intermediate label. Also resops to produce the box will be added to the short preamble of that label. The logic here on how to import boxes from previous trace-parts is the same as what was previous used to import boxes from the preamble into the loop. The jit-targets branch implementes the framework described above. To not make it too big a leap from where we are today it then uses a policy of where to insert labels and when to force virtuals that will make it produce as similiar results as possible to what we have today. That becomes a somewhat complex policy. I do however believe that simpler policies (such as what's hinted about above) will be even more effective here. That would allow for things to be simplified and cleaned up a bit. Also, experimenting with inserting labels at say the first jit_merge_point discovered when tracing a bridge would allow us to join the controllflows of a loop with lots of paths back together. That will however probably be the topic of future branches... -- Håkan Ardö [View Less]

1 0

BUG! file.readlines
by ZZZ 654321 Nov. 4, 2011

Nov. 4, 2011

经过测试, 我发现在 windows 下, pypy 的任意版本, 执行下面操作, 会占用很高的 CPU, 并且速度很慢, 测试样本为 20 Ｍ左右的文本文件. Cpython 下面测试很快希望可以解决一下, 谢谢. >>> f01= file('aaa.txt', 'r' ) >>> a01= f01.readlines(); #就是这里 >>> f01.close()

3 2

404 and DEBUG=True on speed.pypy.org
by Davide Setti Nov. 4, 2011

Nov. 4, 2011

Hi, If i click on the permalink link on http://speed.pypy.org/timeline/#/?exe=3,6,1,5&base=2+472&ben=grid&env=1&rev… i get: http://speed.pypy.org/timeline/?exe=3%2C6%2C1%2C5&base=2%2B472&ben=grid&env… DEBUG=True is not good... Regards. -- Davide Setti code: http://github.com/vad

2 1

BUG! file.readlines
by HY Nov. 4, 2011

Nov. 4, 2011

经过测试, 我发现在 windows 下, pypy 的任意版本, 执行下面操作, 会占用很高的 CPU, 并且速度很慢, 测试样本为 20 Ｍ左右的文本文件. Cpython 下面测试很快希望可以解决一下, 谢谢. >>> f01= file('aaa.txt', 'r' ) >>> a01= f01.readlines(); #就是这里 >>> f01.close()

1 0

Oops!
by mark.pearse＠skynet.be Nov. 2, 2011

Nov. 2, 2011

Hi Fellow Sprinters, Only when I got to Copenhagen airport and started doing a bit of preparation did I remember that the old Powerbook that am bringing has PPC architecture. I assume this will be impractical for use at the sprint, so has someone got a spare x86 machine, preferably linux or Mac that I could borrow for the sprint? Thanks, Mark

2 1

Late for sprint
by Maciej Fijalkowski Nov. 2, 2011

Nov. 2, 2011

hi I'm a bit late for sprint, since there was an accident on warsaw airport and most flights are cancelled. ETA tomorrow around 2pm Cheers, fijal PS. Don't wait for me with dinner :)

1 0