I ran a python and pygame python ray tracer <https://geometrian.com/programming/projects/index.php?project=Ray-Tracer> by Ian Mallett. https://geometrian.com/programming/projects/index.php?project=Ray-Tracer
On PyPy - 18.6 seconds. On Python 2.7 - 9 minutes, 28.1 seconds 30x faster :) On Mon, Mar 19, 2018 at 4:25 PM, MrGumm <stabbingfin...@gmail.com> wrote: > Pretty cool, sir. Thank you. :) > > On 3/19/2018 2:19 AM, René Dudfield wrote: > > Hi, > > TLDR; I'm at the pypy sprint, and working through the remaining > pygame-on-pypy-cpyext issues. > https://youtu.be/WN1slc5O8os > > > Surprisingly to me... it's already usable. That is pygame (same one that > runs on cpython), works on pypy through its C extension API. pypy has good > support for the CPython API (through a recompile) now. > > There was an issue with events stopping keyboard/mouse/etc from working. > Lots of details in this issue describing the changes needed, so I hope > other extensions encountering this will find it useful. > https://github.com/pygame/pygame/issues/419 > > But now that's fixed, every pygame app I tried on it has worked. > > Why is this exciting? > > This is exciting to me because: > > - pure python code being fast on pypy(after warmup), also mixed with > the fast bits in C/asm. > - cpyext is getting faster in pypy. There is already work and > discussion towards it being faster than CPython. > - maintaining one pygame code base is easier than maintaining several > (pygame cffi/ctypes/cython, ...). > - with one code base it should be fast on both pygame, and pypy(in > time). > > Here's our old pal solarwolf from early 2000s running on pypy. > https://youtu.be/WN1slc5O8os > > Still lots of work to do (especially around PixelArray buffers and such). > Then of course, there is the issue of binary wheels, so that `*pip > install pygame*` works without needing to compile things from source. > > How is the speed? (when do we use this tool? Is it fast enough?) > > If your code is already quite well optimized, and not spending much time > in python, you can't expect to see an improvement. However, if you are > pushing boundaries in your python code, you can expect very good increases. > > Some examples where you can expect it to be faster: > > - if profiling and a pygame function (like blit) isn't at the top of > the slow bits. > - collision detection (if you aren't using fancy algorithms). > - a pure python ray caster. > - writing a music synthesizer in python python. > > Where it can be slower. > > - if you are going into C code for a lot of small operations. Like > when using rect. > > For me, I'm interested mostly in this for a physics art project which was > really slow, and also for a software music synth written in pure python. > Even more interesting is running pypy as a separate process for these > tasks, and run the gui process with CPython. > > > > ciao, > > >
