g'day.
Binary wheels for pygame on pypy for windows are available. https://github.com/pygame/pygame/issues/423 Instructions on how to install pypy on windows, if you want to play with it are here: http://renesd.blogspot.com/2018/03/windows-pypy-pygame-build-for-testing.html Am very interested to hear how things go? Homebrew mac: > brew install sdl sdl_image sdl_mixer sdl_ttf portmidi pypy pypy3 > pypy3 -m pip install pygame --pre > *Nixen. > pypy -m pip install pygame --pre > pypy -m pygame.examples.aliens On Tue, Mar 20, 2018 at 9:39 AM, René Dudfield <ren...@gmail.com> wrote: > 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, >> >> >> >
