Re: [pypy-dev] array performace?

2010-07-03 Thread Antonio Cuni
On 03/07/10 19:22, Paolo Giarrusso wrote: > I had 3 colleague students who implemented, for instance, a > Python-to-JVM bytecode compiler which was way faster than Jython. > Which was the trick? [cut] I'm ready to bet that they did not implement a Python compiler, but a simil-Python language that

Re: [pypy-dev] array performace?

2010-07-03 Thread Paolo Giarrusso
On Sat, Jul 3, 2010 at 16:20, William Leslie wrote: > On 3 July 2010 08:56, Bengt Richter wrote: >> On 07/02/2010 11:35 AM Carl Friedrich Bolz wrote: > Paolo recently bemoaned the > trend toward writing modules at interp level for speed* - I'm not > really sure if it is a trend now or not - but

Re: [pypy-dev] array performace?

2010-07-03 Thread Paolo Giarrusso
On Fri, Jul 2, 2010 at 23:16, Maciej Fijalkowski wrote: > [snip] > >> the need for separate loads. In Python, instead, refcounting alone is >> a very expensive operation. > > > How does that apply to pypy? I was talking about the original paper. -- Paolo Giarrusso - Ph.D. Student http://www.infor

Re: [pypy-dev] array performace?

2010-07-03 Thread William Leslie
On 3 July 2010 08:56, Bengt Richter wrote: > On 07/02/2010 11:35 AM Carl Friedrich Bolz wrote: > A thought/question: > > Could/does JIT make use of information in an assert statement? E.g., could we > write >     assert set(type(x) for x in img) == set([float]) and len(img)==640*480 > in front of

Re: [pypy-dev] Interpreter level array implementation

2010-07-03 Thread Paolo Giarrusso
On Sat, Jul 3, 2010 at 09:28, Armin Rigo wrote: > Hi Paolo, > > On Sat, Jul 03, 2010 at 08:58:34AM +0200, Paolo Giarrusso wrote: >> Isn't there some existing research about that in the 'tracing' >> community?  (...)   Not sure >> whether they do it also for Javascript, since there compilation time

Re: [pypy-dev] Interpreter level array implementation

2010-07-03 Thread Leonardo Santagada
On Jul 3, 2010, at 3:58 AM, Paolo Giarrusso wrote: > Another issue: what is i4 for? It's not used at all in the loop, but > it is reset to 27 at the end of it, each time. Doesn't such a var > waste some (little) time? This I found interesting. Do anyone know the answer? -- Leonardo Santagada sa

Re: [pypy-dev] Interpreter level array implementation

2010-07-03 Thread Carl Friedrich Bolz
Hi Paolo, 2010/7/3 Paolo Giarrusso : >> It requires thinking. It's harder to do because we don't know >> statically upfront how many paths we'll compile to assembler, but I >> can think about ways to mitigate that. > > Isn't there some existing research about that in the 'tracing' > community? As

Re: [pypy-dev] Interpreter level array implementation

2010-07-03 Thread Antonio Cuni
On 03/07/10 08:14, Hakan Ardo wrote: > What is a bridge? you might be interested to read the chapter of my PhD thesis which explains exactly that, with diagrams: http://codespeak.net/svn/user/antocuni/phd/thesis/thesis.pdf In particular, section 6.4 explains the difference between loops, bridge

Re: [pypy-dev] Interpreter level array implementation

2010-07-03 Thread Armin Rigo
Hi Paolo, On Sat, Jul 03, 2010 at 08:58:34AM +0200, Paolo Giarrusso wrote: > Isn't there some existing research about that in the 'tracing' > community? (...) Not sure > whether they do it also for Javascript, since there compilation times > have to be very fast, but I guess they did so in thei

Re: [pypy-dev] Interpreter level array implementation

2010-07-03 Thread Armin Rigo
Hi Alex, On Fri, Jul 02, 2010 at 03:12:19PM -0500, Alex Gaynor wrote: > In addition to the things you noted, I guess the int overflow check > can be optimized out, since i+=1 can never cause it to overflow given > that i is bounded at 640*480. I suppose in general that would require > more datafl