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
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
>
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
__
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,
>>
>
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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo