4) Myabe allow to speed my code up (JIT), or make Python as fast as possible. But this is rather a long term goal. Generally, I don't see why my code written in C and the same code written in Python, not using much dynamic features, couldn't be the same fast. (Of course I understand why now it is slower, Python is interpreted, etc. But I mean in principle. Python can have as much information about my code as the C compiler.) I use Python for devising new numerical algorithms, and than I need to rewrite them by hand to fortran for speed. It's a pain.
6) Allow efficient threading? CPython has the GIL (for good technological reasons). Generally pypy can improve how to do things in parallel in python. Currently, one needs to use pympi, pypar, or something.
These two together are, in my mind, where PyPy can really shine. Performance on par with CPython is critical to be taken seriously, but CPython's difficulties with the GIL mean I can only make it scalable at about 60% to 65% of the traditional efficiency (on pystones at least). That gap gives PyPy enough room to surpass CPython on scalable performance. -- Adam Olsen, aka Rhamphoryncus
Adam Olsen wrote:
4) Myabe allow to speed my code up (JIT), or make Python as fast as possible. But this is rather a long term goal. Generally, I don't see why my code written in C and the same code written in Python, not using much dynamic features, couldn't be the same fast. (Of course I understand why now it is slower, Python is interpreted, etc. But I mean in principle. Python can have as much information about my code as the C compiler.) I use Python for devising new numerical algorithms, and than I need to rewrite them by hand to fortran for speed. It's a pain.
6) Allow efficient threading? CPython has the GIL (for good technological reasons). Generally pypy can improve how to do things in parallel in python. Currently, one needs to use pympi, pypar, or something.
These two together are, in my mind, where PyPy can really shine. Performance on par with CPython is critical to be taken seriously, but CPython's difficulties with the GIL mean I can only make it scalable at about 60% to 65% of the traditional efficiency (on pystones at least). That gap gives PyPy enough room to surpass CPython on scalable performance.
We are confident that we can surpass CPython's speed with the help of the JIT. As for free threading, the big prerequisite for that is a GC that plays well with threads. Boehm is not very good in this respect. After this is done we can think about how to insert locking operations in an automatic way to reduce the likelyhood of errors (this is currently already done for releasing the GIL around external function calls). Then there will probably be a huge amount of painful debugging :-) Cheers, Carl Friedrich
We are confident that we can surpass CPython's speed with the help of the JIT. As for free threading, the big prerequisite for that is a GC that plays well with threads. Boehm is not very good in this respect. After this is done we can think about how to insert locking operations in an automatic way to reduce the likelihood of errors (this is currently already done for releasing the GIL around external function calls). Then there will probably be a huge amount of painful debugging :-)
I remembered other few remarks to point out: 1) Current pypy in Debian doesn't have modules: thread, ctypes. Thread is needed for py.test, ctypes for plotting facilities in sympy. Ondrej
Carl Friedrich Bolz wrote: ...
We are confident that we can surpass CPython's speed with the help of the JIT. As for free threading, the big prerequisite for that is a GC that plays well with threads. Boehm is not very good in this respect. After this is done we can think about how to insert locking operations in an automatic way to reduce the likelyhood of errors (this is currently already done for releasing the GIL around external function calls). Then there will probably be a huge amount of painful debugging :-)
I'm actually no longer convinced that it makes soo much sense to get rid of the GIL. Python's data model is not made for free threading. Have you had a look into http://www.parallelpython.com/ ? Might be a starting point into threads with disjoint interpreters and some locking just for data exchange. cheers - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
On 9/17/07, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
Adam Olsen wrote:
4) Myabe allow to speed my code up (JIT), or make Python as fast as possible. But this is rather a long term goal. Generally, I don't see why my code written in C and the same code written in Python, not using much dynamic features, couldn't be the same fast. (Of course I understand why now it is slower, Python is interpreted, etc. But I mean in principle. Python can have as much information about my code as the C compiler.) I use Python for devising new numerical algorithms, and than I need to rewrite them by hand to fortran for speed. It's a pain.
6) Allow efficient threading? CPython has the GIL (for good technological reasons). Generally pypy can improve how to do things in parallel in python. Currently, one needs to use pympi, pypar, or something.
These two together are, in my mind, where PyPy can really shine. Performance on par with CPython is critical to be taken seriously, but CPython's difficulties with the GIL mean I can only make it scalable at about 60% to 65% of the traditional efficiency (on pystones at least). That gap gives PyPy enough room to surpass CPython on scalable performance.
We are confident that we can surpass CPython's speed with the help of the JIT. As for free threading, the big prerequisite for that is a GC that plays well with threads. Boehm is not very good in this respect. After this is done we can think about how to insert locking operations in an automatic way to reduce the likelyhood of errors (this is currently already done for releasing the GIL around external function calls). Then there will probably be a huge amount of painful debugging :-)
I'm confident CPython will provide a language-level solution to locking. This does mean waiting over a year from this point though. -- Adam Olsen, aka Rhamphoryncus
participants (4)
-
Adam Olsen -
Carl Friedrich Bolz -
Christian Tismer -
Ondrej Certik