headers
René Dudfield | 1 Mar 2010 11:15
Picon
Gravatar

Re: speed.pypy.org launched

On Fri, Feb 26, 2010 at 9:59 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
> Carl Friedrich Bolz, 25.02.2010 18:38:
>> On 02/25/2010 04:10 PM, Miquel Torres wrote:
>>> As some of you already know, there is a new performance site online:
>>> speed.pypy.org.
>> [...]
>>
>> I'm quite impressed, this is very cool work and a good improvement over
>> the current plots. Thanks for doing this!
>>
>> One thing that I would really find useful are error bars in the timeline
>> view. This would help us judge whether up-and-down movements are within
>> the margin of randomness, or whether it is a real effect. I don't know
>> how annoying they are to implement though, no clue whether the plot lib
>> supports that. There should be enough information about errors in the
>> json files, as far as I remember.
>
> The standard deviation is commonly considered meaningless for benchmark
> results. All that really matters is the fastest run, everything else is
> just fog.
>
> Read the docs on timeit, for example.
>
> Stefan
>

hi,

For some sets of problems, the first run is very important.  For
example, where you only want to process the particular data once.
(Continue reading)

Permalink | Reply | 1 comment |
headers
René Dudfield | 1 Mar 2010 11:18
Picon
Gravatar

Re: speed.pypy.org launched

On Mon, Mar 1, 2010 at 10:15 AM, René Dudfield <renesd <at> gmail.com> wrote:
>
> For others the Worst performance is the most important.  For example
> 'real time' like programs which require the runtime only takes at
> maximum N where N is measured.

um, this made no sense at all... oops!  Sorry, let me try again...

For others the Worst performance is the most important.  For example
'real time' like programs which require the runtime only takes at
maximum N.  Where N is an allocated time budget for that code.
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Maciej Fijalkowski | 2 Mar 2010 05:50
Picon

Release and tags

Hello.

Can we copy trunk -> dist for the release, so we don't block any new
development because of the release? There was the point of dist, even
if we forgot it completely.

Cheers,
fijal
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 3 comments |
headers
René Dudfield | 2 Mar 2010 16:51
Picon
Gravatar

gsoc for pypy...

hi,

gsoc is on again... for your information the python mailing list for it is here:
    http://mail.python.org/mailman/listinfo/soc2010-mentors

It would be good to have a wiki page(or blog post? ... err a text file available via http) of project ideas for pypy... if there are any pypy people mentoring that is.  With the pygame project last year, we found having a project page for suggestions of acceptable projects helped students pick things they were interested in, and things the project would be happy with.



cu

_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 8 comments |
headers
René Dudfield | 2 Mar 2010 19:06
Picon
Gravatar

Re: gsoc for pypy...

hello again.

To start the gsoc ideas list off...

- port jit to 64 bit (maybe too short for 3 month project, if so start on ARM after amd64?).
- speed up ctypes wrapper.
- GIL removal work.
- python2.6/2.7/py3k features.
- ctypes bindings for database adaptors (would be good for ironpython, jython, and even cpython too).
- faster ctypes module.  (by using jit?)
- cpython bridge module.  Either load pypy as cpython extension or the otherway around.  To allow gradual porting.
- ironclad port to pypy.  To allow loading cpython C extensions.  eg, ironpython can run numpy with this.
- revive javascript/flex backend.
- improvements to java/.net backend.
- AOT compilation research - to allow compiling to iphone for example.

I guess this list could also be put on a page looking for sponsors?  To give sponsors something concrete they can pay a contract for.  eg, 'approximately 2-3 months work(24,000 euros) to get X benefit, as well as a logo+link on our sponsors page... etc.'


Anyway... those are some of the areas I can think of from past discussions.  I'm sure pypy project members have a better idea of what would be good for gsoc students to work on?


cu,




On Tue, Mar 2, 2010 at 3:51 PM, René Dudfield <renesd <at> gmail.com> wrote:
hi,

gsoc is on again... for your information the python mailing list for it is here:
    http://mail.python.org/mailman/listinfo/soc2010-mentors

It would be good to have a wiki page(or blog post? ... err a text file available via http) of project ideas for pypy... if there are any pypy people mentoring that is.  With the pygame project last year, we found having a project page for suggestions of acceptable projects helped students pick things they were interested in, and things the project would be happy with.



cu

_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 7 comments |
headers
Maciej Fijalkowski | 2 Mar 2010 19:38
Picon

Re: gsoc for pypy...

Hey.

Thanks for posting that! I think it makes sense to discuss a bit
whether stuff makes or does not make sense.

On Tue, Mar 2, 2010 at 11:06 AM, René Dudfield <renesd <at> gmail.com> wrote:
> hello again.
>
> To start the gsoc ideas list off...
>
> - port jit to 64 bit (maybe too short for 3 month project, if so start on
> ARM after amd64?).

Not sure if it's too short. It's too short for core dev 3 month
project, but for student it's ideal.

> - speed up ctypes wrapper.

A bit hard, but also JIT-cooperation.

> - GIL removal work.

Hard/researchy

> - python2.6/2.7/py3k features.
> - ctypes bindings for database adaptors (would be good for ironpython,
> jython, and even cpython too).

that's not strictly pypy-related. I would like such projects to be
under PSF umbrella. Also there is a question of maintainability.

> - cpython bridge module.  Either load pypy as cpython extension or the
> otherway around.  To allow gradual porting.
> - ironclad port to pypy.  To allow loading cpython C extensions.  eg,
> ironpython can run numpy with this.

This is probably interesting, might also be a bit hard.

> - revive javascript/flex backend.

please no :)

> - improvements to java/.net backend.

Honestly, we had problems with maintability of new backends. Also .net
is sort of done (except .net bindings).

> - AOT compilation research - to allow compiling to iphone for example.

that's research, possibly interesting though.

>
> I guess this list could also be put on a page looking for sponsors?  To give
> sponsors something concrete they can pay a contract for.  eg, 'approximately
> 2-3 months work(24,000 euros) to get X benefit, as well as a logo+link on
> our sponsors page... etc.'

Sure. Although note that so far we did not get any feedback on
sponsoring blog post.

>
>
> Anyway... those are some of the areas I can think of from past discussions.
> I'm sure pypy project members have a better idea of what would be good for
> gsoc students to work on?

How about investigating (again) llvm jit backend?

Thanks for starting the discussion!

Cheers,
fijal
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 6 comments |
headers
Maciej Fijalkowski | 2 Mar 2010 20:01
Picon

Re: gsoc for pypy...

On Tue, Mar 2, 2010 at 11:56 AM, Benoit Boissinot
<bboissin+pypy <at> gmail.com> wrote:
> On Tue, Mar 2, 2010 at 7:38 PM, Maciej Fijalkowski <fijall <at> gmail.com> wrote:
>> Hey.
>>
>>> Anyway... those are some of the areas I can think of from past discussions.
>>> I'm sure pypy project members have a better idea of what would be good for
>>> gsoc students to work on?
>>
>> How about investigating (again) llvm jit backend?
>
> Is there a summary of what the problems were? I guess the lack of
> maturity of the JIT engine was one (as experienced by
> unladed-swallow).
>
> cheers,
>
> Benoit
>

Not written. Bugs and immaturity, yes. The precise issue we run into
was tail calls not working, but this one is supposed to be fixed by
now. Having US team on LLVM JIT team is certainly a big advantage.

I suppose next step is to try to push it and see what's next.

Cheers,
fijal
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 4 comments |
headers
Benoit Boissinot | 2 Mar 2010 19:56
Picon

Re: gsoc for pypy...

On Tue, Mar 2, 2010 at 7:38 PM, Maciej Fijalkowski <fijall <at> gmail.com> wrote:
> Hey.
>
>> Anyway... those are some of the areas I can think of from past discussions.
>> I'm sure pypy project members have a better idea of what would be good for
>> gsoc students to work on?
>
> How about investigating (again) llvm jit backend?

Is there a summary of what the problems were? I guess the lack of
maturity of the JIT engine was one (as experienced by
unladed-swallow).

cheers,

Benoit
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 5 comments |
headers
Armin Rigo | 2 Mar 2010 20:22
Favicon

Re: gsoc for pypy...

Hi,

On Tue, Mar 02, 2010 at 12:01:23PM -0700, Maciej Fijalkowski wrote:
> >> How about investigating (again) llvm jit backend?
> (...)
> I suppose next step is to try to push it and see what's next.

Yes, but I bet from experience that we're going to run after a few days'
work into the next issue.  We've already done that 3 or 4 times with
llvm, so now I'm honestly a bit fed up.  For comparison, gcc gives code
that is a bit slower but at least it is really a solid bug-free project.

A bientot,

Armin.
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 3 comments |
headers
Armin Rigo | 2 Mar 2010 20:35
Favicon

Re: gsoc for pypy...

Re-hi,

On Tue, Mar 02, 2010 at 08:22:51PM +0100, Armin Rigo wrote:
> Yes, but I bet from experience that we're going to run after a few days'
> work into the next issue.  We've already done that 3 or 4 times with
> llvm, so now I'm honestly a bit fed up.  For comparison, gcc gives code
> that is a bit slower but at least it is really a solid bug-free project.

Let me make this statement more precise: I mean for the non-JIT backends
of PyPy, using the llvm backend of PyPy gaves results that were
typically a little bit faster than using the C backend, when compiling
with llvm-gcc.  However, with the various generations of our JIT, using
a JIT llvm backend always ran into llvm bugs.

A bientot,

Armin.
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 2 comments |

Gmane