[pypy-dev] support for 64-bit processors and eliminating global state

[Maciej Fijalkowski]

Hi.

In general, we try hard not to make hard assumptions, so the transition to
64 bit should be generally smooth. However, we have limited resources and
we're generally volunteer run. For example, my laptop does not support 64bit,
which makes it significantly harder for me to work on (that being one example).

So, 64bit support is put on the second plan, but not because we plan to hardcode
32bit everywhere, but simply because our resources are limited. If you want to
push for it by donating time/money you're welcome to do so.

It's nice to hear what you're doing, however full paper would be much better
than the abstract. Is there a way to obtain it somehow else?

PS. I also did some stuff, like this, by lazily constructing numpy expressions
and compiling them to assembler, so I'm personally interested in hearing more.

Cheers,
fijal

On Wed, Sep 30, 2009 at 10:27 AM, Jeff Anderson-Lee
<jonah at eecs.berkeley.edu> wrote:
> I'm new to pypy but would encourage the development folks to apply some
> focus towards two things: support for both 32 and 64-bit processors and
> eliminating global state including the GIL.
>
> The near future of mainstream processors is multi-core x86_64.  For the
> short-term both 32-bit and 64-bit platforms will be around.  Code that
> makes "naked" assumptions about word size will break and needs to be
> re-factored to hide the word-size dependencies.   Similarly code that
> assumes a single thread of execution or uses a GIL to protect global
> state will make efficient use of modern processors.  Any language or
> system that cannot make the transition to 64-bit multi-core will start
> to loose ground to those that do.
>
> At the Parallel Computing Laboratory (UC Berkeley) one of the projects
> we are working on is called SEJITS which stands for Selective Embedded
> Just in Time Specialization.  The idea is that one can extend a
> self-introspecting modern scripting language for calling native coded
> modules (e.g. C) at selected points for handling specialized operations
> (e.g. vector/matrix operations using tuned SIMD or CUDA code).  You can
> see the abstract of a recent SEJITS paper at
> http://pmea.ac.upc.edu/program.html (session 1a) but unfortunately the
> paper is not online yet.
>
> Both Python and Ruby are being looked at as potential target languages
> for SEJITS work.  Both have sufficient introspection facilities to
> support selective JIT operations.  Python has an advantage in having
> been used by the scientific community for longer than Ruby with more
> established users.  I'd love to see this work integrate with pypy.  At
> the moment the folks involved are targeting CPython.
> In any case, I think the transition to multi-core/multi-threaded 64-bit
> machines is a potential watershed of major importance which it would
> behoove pypy-dev folks to keep in mind.
>
> Respectfully.
>
> Jeff Anderson-Lee
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>