On Sat, Jul 3, 2010 at 08:20, Maciej Fijalkowski wrote:
> On Sat, Jul 3, 2010 at 12:14 AM, Hakan Ardo wrote:
>> On Fri, Jul 2, 2010 at 11:21 PM, Maciej Fijalkowski wrote:
>>> General note - we consider 2x optimized C a pretty good result :) Details
>>> below
>>
>> As do I :) I just want to mak
On Sat, Jul 3, 2010 at 12:14 AM, Hakan Ardo wrote:
> On Fri, Jul 2, 2010 at 11:21 PM, Maciej Fijalkowski wrote:
>> General note - we consider 2x optimized C a pretty good result :) Details
>> below
>
> As do I :) I just want to make this as jit-friendly as possible
> without rely knowing what's
On Fri, Jul 2, 2010 at 11:21 PM, Maciej Fijalkowski wrote:
> General note - we consider 2x optimized C a pretty good result :) Details
> below
As do I :) I just want to make this as jit-friendly as possible
without rely knowing what's jit-friendly...
> Yes. We don't do loop invariant optimizat
On Fri, Jul 2, 2010 at 4:56 PM, Bengt Richter wrote:
> On 07/02/2010 11:35 AM Carl Friedrich Bolz wrote:
>> Hi Paolo,
>>
>> On 07/02/2010 02:08 PM, Paolo Giarrusso wrote:
> Unsupported claim is for example that fast interpreters are 10x
> slower than C.
>>> That's the only unsupported clai
On 07/02/2010 04:14 PM Amaury Forgeot d'Arc wrote:
> Hi,
>
> 2010/7/3 Bengt Richter :
>> 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 a
Hi,
2010/7/3 Bengt Richter :
> 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 a loop operating on img and have JIT use the info as assumed true
On 07/02/2010 11:35 AM Carl Friedrich Bolz wrote:
> Hi Paolo,
>
> On 07/02/2010 02:08 PM, Paolo Giarrusso wrote:
Unsupported claim is for example that fast interpreters are 10x
slower than C.
>> That's the only unsupported claim, but it comes from "The Structure
>> and Performance of Eï¬
General note - we consider 2x optimized C a pretty good result :) Details below
On Fri, Jul 2, 2010 at 1:59 PM, Hakan Ardo wrote:
> Hi,
> we got the simplest possible interpreter level implementation of an
> array-like object running (in the interplevel-array branch) and it
> executes my previous
[snip]
> the need for separate loads. In Python, instead, refcounting alone is
> a very expensive operation.
How does that apply to pypy?
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
On Fri, Jul 2, 2010 at 2:59 PM, Hakan Ardo wrote:
> Hi,
> we got the simplest possible interpreter level implementation of an
> array-like object running (in the interplevel-array branch) and it
> executes my previous example about 2 times slower than optimized C.
> Attached is the trace generated
Hi,
we got the simplest possible interpreter level implementation of an
array-like object running (in the interplevel-array branch) and it
executes my previous example about 2 times slower than optimized C.
Attached is the trace generated by the following example:
img=array(640*480); l=0;
On Fri, Jul 2, 2010 at 20:35, Carl Friedrich Bolz wrote:
> Hi Paolo,
>
> On 07/02/2010 02:08 PM, Paolo Giarrusso wrote:
Unsupported claim is for example that fast interpreters are 10x
slower than C.
>> That's the only unsupported claim, but it comes from "The Structure
>> and Performance
Hi Paolo,
On 07/02/2010 02:08 PM, Paolo Giarrusso wrote:
>>> Unsupported claim is for example that fast interpreters are 10x
>>> slower than C.
> That's the only unsupported claim, but it comes from "The Structure
> and Performance of Efficient Interpreters". I studied that as a
> student on VM, you
> To be fair it's not like it said "404 not found" to me
right, that is wrong
2010/7/2 Maciej Fijalkowski :
> To be fair it's not like it said "404 not found" to me
>
> On Fri, Jul 2, 2010 at 3:51 AM, wrote:
>> Ah, ok thanks. I had bookmarked the other page, so I just clicked and
>> assumed it
On Fri, Jul 2, 2010 at 10:55, wrote:
>> On Fri, Jul 2, 2010 at 2:26 AM, wrote:
>> >> On Fri, Jul 2, 2010 at 1:47 AM, Paolo Giarrusso
>> >
>> >> wrote:
>> >> > On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski
>> > wrote:
>> >> >> On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo wrote:
>> >> >>> OK,
To be fair it's not like it said "404 not found" to me
On Fri, Jul 2, 2010 at 3:51 AM, wrote:
> Ah, ok thanks. I had bookmarked the other page, so I just clicked and assumed
> it was broken
>
> Thanks,
> Ben
>
> -Original Message-
> From: Miquel Torres [mailto:tob...@googlemail.com]
> S
Ah, ok thanks. I had bookmarked the other page, so I just clicked and assumed
it was broken
Thanks,
Ben
-Original Message-
From: Miquel Torres [mailto:tob...@googlemail.com]
Sent: 02 July 2010 10:50
To: Young, Ben
Cc: pypy-dev@codespeak.net
Subject: Re: [pypy-dev] PyPy Speed
Hi Ben,
n
Hi Ben,
no, that is not the case, the new version has been online for a week
without problems.
The reason is the renaming of the "overview" to "changes". Maybe I
should have left the URL /overview/ active with a redirection to
/changes/, sorry. You would have seen that if you had checked the root
Ok thanks :)
-Original Message-
From: Maciej Fijalkowski [mailto:fij...@gmail.com]
Sent: 02 July 2010 10:28
To: Young, Ben
Cc: pypy-dev@codespeak.net
Subject: Re: [pypy-dev] PyPy Speed
Hey.
I know miquel was talking about rolling in new version. Apparently,
did not work :)
On Fri, Jul
Hey.
I know miquel was talking about rolling in new version. Apparently,
did not work :)
On Fri, Jul 2, 2010 at 3:26 AM, wrote:
> http://speed.pypy.org/overview/ seems to have been unavailable for the last
> couple of days. It gives a 500 whenever I visit it
>
>
>
> Ben Young - Senior Software
http://speed.pypy.org/overview/ seems to have been unavailable for the
last couple of days. It gives a 500 whenever I visit it
Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sung
On Fri, Jul 2, 2010 at 2:26 AM, wrote:
>> On Fri, Jul 2, 2010 at 1:47 AM, Paolo Giarrusso
>
>> wrote:
>> > On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski
> wrote:
>> >> On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo wrote:
>> >>> OK, so making an interpreter level implementation of array.array
>
Hi Fijal,
On Fri, Jul 02, 2010 at 02:19:02AM -0600, Maciej Fijalkowski wrote:
> By "better candidate" I mean that having JIT see _rawffi might mean
> some struggle for it to understand what's going on with raw pointers
> and writing array in interp-level would be better.
Ah, right.
Armin.
__
On Fri, Jul 2, 2010 at 2:17 AM, Armin Rigo wrote:
> Hi Fijal,
>
> On Thu, Jul 01, 2010 at 09:35:17AM -0600, Maciej Fijalkowski wrote:
>> The main reason why _rawffi.Array is slow is that JIT does not look
>> into that module, so there is wrapping and unwrapping going on.
>> Relatively easy to fix
Hi Alex,
On Fri, Jul 02, 2010 at 12:40:21AM -0500, Alex Gaynor wrote:
> FWIW one thing to note is that array
> uses the struct module, which is also pure python.
No: we have a pure Python version, but in a normally compiled pypy-c,
there is an interp-level version of 'struct' too.
A bientot,
A
Hi Fijal,
On Thu, Jul 01, 2010 at 09:35:17AM -0600, Maciej Fijalkowski wrote:
> The main reason why _rawffi.Array is slow is that JIT does not look
> into that module, so there is wrapping and unwrapping going on.
> Relatively easy to fix I suppose, but _rawffi.Array was not meant to
> be used lik
On Fri, Jul 2, 2010 at 1:37 AM, Hakan Ardo wrote:
> Hi,
> I've got a simple implementation of array now, wrapping lltype.malloc
> with no error checking yet (cStringIO was great help, thx). How can I
> test this with the jit? Do I need to translate the entire pypy or is
> there a quicker way?
>
>>
On Fri, Jul 2, 2010 at 1:47 AM, Paolo Giarrusso wrote:
> On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski wrote:
>> On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo wrote:
>>> OK, so making an interpreter level implementation of array.array seams
>>> like a good idea. Would it be possible to get the j
On Fri, Jul 2, 2010 at 09:27, Miquel Torres wrote:
> Hi Paolo,
>
> hey! I think it is a great idea. With logs you get both: correct
> normalized totals AND the ability to display the individual stacked
> series, which necessarily add arithmetically. But it strikes me,
> hasn't anyone written a pap
On Fri, Jul 2, 2010 at 09:47, Paolo Giarrusso wrote:
> On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski wrote:
>> On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo wrote:
>>> OK, so making an interpreter level implementation of array.array seams
>>> like a good idea. Would it be possible to get the jit
On Fri, Jul 2, 2010 at 08:04, Maciej Fijalkowski wrote:
> On Thu, Jul 1, 2010 at 1:18 PM, Hakan Ardo wrote:
>> OK, so making an interpreter level implementation of array.array seams
>> like a good idea. Would it be possible to get the jit to remove the
>> wrapping/unwrapping in that case to get b
Hi,
I've got a simple implementation of array now, wrapping lltype.malloc
with no error checking yet (cStringIO was great help, thx). How can I
test this with the jit? Do I need to translate the entire pypy or is
there a quicker way?
> there. In case of _rawffi, probably a couple of hints for the
Hi Paolo,
hey! I think it is a great idea. With logs you get both: correct
normalized totals AND the ability to display the individual stacked
series, which necessarily add arithmetically. But it strikes me,
hasn't anyone written a paper about that method already? or at least
documented it?
Anywa
On 02/07/10 09:28, Maciej Fijalkowski wrote:
> Fine by me. Can you fix test_package then? It assumes there is
> Python.h in include (which might not be there).
ah right... because when we run own-test translation didn't happen, so .h are
not there. Ok, I'll fix it later.
ciao,
Anto
On 02/07/10 08:45, Maciej Fijalkowski wrote:
> Hey.
>
> Any reason why we should copy .h files during translation and can't
> just have them there?
>
I talked with Amaury and he told me that he prefers to keep all the
cpyext-related files together, which I think makes sense. Moreover, we need
t
On Fri, Jul 2, 2010 at 1:21 AM, Antonio Cuni wrote:
> On 02/07/10 08:45, Maciej Fijalkowski wrote:
>>
>> Hey.
>>
>> Any reason why we should copy .h files during translation and can't
>> just have them there?
>>
>
> I talked with Amaury and he told me that he prefers to keep all the
> cpyext-relat
36 matches
Mail list logo
