Re: [pypy-dev] just saw: speed.pypy.org reports 4x faster

2011-07-18 Thread Phyo Arkar
So This is really happening in 1.6 or Speed.pypy bug? On 7/19/11, Maciej Fijalkowski wrote: > On Mon, Jul 18, 2011 at 11:30 PM, Massa, Harald Armin wrote: >> I recommend to wrap the code and release it with the subtitle "the 4 times >> faster release" > > I like codenames more. Like PyPy 1.6 "Ki

Re: [pypy-dev] just saw: speed.pypy.org reports 4x faster

2011-07-18 Thread Maciej Fijalkowski
On Mon, Jul 18, 2011 at 11:30 PM, Massa, Harald Armin wrote: > I recommend to wrap the code and release it with the subtitle "the 4 times > faster release" I like codenames more. Like PyPy 1.6 "Kickass Panda" > Best wishes, > Harald > -- > GHUM GmbH > Harald Armin Massa > Spielberger Straße 49 >

[pypy-dev] just saw: speed.pypy.org reports 4x faster

2011-07-18 Thread Massa, Harald Armin
I recommend to wrap the code and release it with the subtitle "the 4 times faster release" Best wishes, Harald -- GHUM GmbH Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 Amtsgericht Stuttgart, HRB 734971 - persuadere. et programmare __

Re: [pypy-dev] PyPy at last infinitely fast

2011-07-18 Thread Miquel Torres
Ok, it is fixed now. AND branch support is in. Results saved with branch other than "default" will be available in the comparison view. Got to talk to fijal yet to see how we should benchmark branches... Ciao! Miquel 2011/7/18 Antonio Cuni : > On 18/07/11 21:37, Miquel Torres wrote: >> Hi, >> >

Re: [pypy-dev] PyPy at last infinitely fast

2011-07-18 Thread Antonio Cuni
On 18/07/11 21:37, Miquel Torres wrote: > Hi, > > speed.pypy.org currently shows a very encouraging performance picture > for PyPy: it is "infinite times faster than CPython". No, it is note > yet April 1st. hooray! We finally finished pypy :-) > Codespeed creates the front page plots using the

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Maciej Fijalkowski
On Mon, Jul 18, 2011 at 2:34 PM, Antonio Cuni wrote: > On 18/07/11 14:10, Carl Friedrich Bolz wrote: >> offtopic, but I still want to point out that translate is indeed terribly >> messy. I've been reading traces some more, and it's quite >> scary. E.g. we have lltype._struct.__init__ has a CALL_F

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Maciej Fijalkowski
On Mon, Jul 18, 2011 at 1:58 PM, Armin Rigo wrote: > Hi Anto, > > On Mon, Jul 18, 2011 at 12:28 PM, Antonio Cuni wrote: >> What can we conclude? That "compiling the loops" is uneffective and we only >> care about compiling single functions? :-( > > Or, conversely, that compiling single functions

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Armin Rigo
Hi Anto, On Mon, Jul 18, 2011 at 2:34 PM, Antonio Cuni wrote: > Also, we have a speedup of ~2-2.5x which is more or less what you would expect > by "just" removing the interpretation overhead. It probably indicates that we > have lrge room for improvements, but I suppose that we already knew

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Antonio Cuni
On 18/07/11 14:10, Carl Friedrich Bolz wrote: > offtopic, but I still want to point out that translate is indeed terribly > messy. I've been reading traces some more, and it's quite > scary. E.g. we have lltype._struct.__init__ has a CALL_FUNCTION > bytecode that needs more than 800 traces operatio

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Antonio Cuni
On 18/07/11 13:58, Armin Rigo wrote: > Or, conversely, that compiling single functions is ineffective and we > only care about compiling the loops? No. > > I expect that on a large and messy program like translate.py, after a > while, either approach should be fine. Still, there are cases where

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Carl Friedrich Bolz
On 07/18/2011 01:58 PM, Armin Rigo wrote: Hi Anto, On Mon, Jul 18, 2011 at 12:28 PM, Antonio Cuni wrote: What can we conclude? That "compiling the loops" is uneffective and we only care about compiling single functions? :-( Or, conversely, that compiling single functions is ineffective and w

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Armin Rigo
Hi Anto, On Mon, Jul 18, 2011 at 12:28 PM, Antonio Cuni wrote: > What can we conclude? That "compiling the loops" is uneffective and we only > care about compiling single functions? :-( Or, conversely, that compiling single functions is ineffective and we only care about compiling the loops? No

Re: [pypy-dev] Benchmarks

2011-07-18 Thread Antonio Cuni
On 17/07/11 22:15, Maciej Fijalkowski wrote: > I think to summarize we're good now, except spitfire which is to be > investigated by armin. > > Then new thing about go is a bit "we touched the world". Because the > unoptimized traces are now shorter, less gets aborted, less gets run > based on fun

Re: [pypy-dev] win64

2011-07-18 Thread Christian Tismer
On 7/18/11 10:15 AM, Armin Rigo wrote: Hi Christian, A quick poll about the 'win64 test' branch. Is it going fine? If ll2ctypes is continuing to give you troubles, I'd suggest to move on; keep in mind that ll2ctypes is only used for testing. I would recommend that your priority should be to p

[pypy-dev] win64

2011-07-18 Thread Armin Rigo
Hi Christian, A quick poll about the 'win64 test' branch. Is it going fine? If ll2ctypes is continuing to give you troubles, I'd suggest to move on; keep in mind that ll2ctypes is only used for testing. I would recommend that your priority should be to pass the tests in pypy/rpython/test/ and p