[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] pygame with SDL2 proposal
Haha. "import pygumm" definitely does sound better. Seriously.
For *me* pypy is a non goal, and CFFI has some drawbacks. I know pypy also has plenty of upsides in certain cases... which has been mentioned a lot, so I won't repeat the good parts about it here.
This was my reasoning...
- CFFI is slower on CPython. CPython is what 99% of people use.
- People don't really contribute if something is in python which interfaces in C - and they only know python. This has been proven by other cffi and ctypes projects. Ctypes, and CFFI is a much rarer skill than standard platform tools. C still happens to be very widely known.
- CFFI has issues on weird platforms... like iOS.
- Cython, numba, numexpr are available. Numpy is not hard to install any more. These are faster than pypy in throughput, and latency.
- Shaders in GLSL are pretty damn amazing if you need cross platform CPU/GPU acceleration.
- pypy has jit warm up, jankiness because of jit and GC, and also doesn't work on weird platforms like iOS.
- Converting everything to shared libraries, and supporting pypy is a whole lot more effort. However, in general I support sending things upstream and separating the C/asm code from the python code. So that it's easier for other people to use them, and there is less maintenance on pygame itself. However, packaging up shared libraries for multiple platforms is a lot of work. If those shared libraries are not already packaged for the 24 platforms, that actually creates maintenance burden as well.
- pygame_cffi is slower on pypy than on CPython for many apps where the bottlenecks are already in the C/asm/platform code. Before the pypy project took funding, forked pygame, removed credits and copyright info, they were warned that blit was the bottleneck. So, like in a lot of things, it looks good in their benchmarks, but for real world things it doesn't perform so well - in many cases.
- pypy uses significantly larger amounts of memory. Which is important for some older, or low memory systems.
- pypy is slower than CPython where it matters for real time apps. Where pypy is faster, there are faster extensions available for CPython, and more appropriate for game JITs. Pypy has many performance cliffs, where it is really fast for some things after lots of warmup, but then for some magic un-obvious reason you fall into the valley of slow. The baseline pure python code performance is always faster in CPython when the jit can't work. Lower bound performance, and consistent performance turns out to be really important to real time apps. This means you can write a lot more code in python, without falling into the valley of slow.
Happy to take patches for pygame to help make it easier for anyone who wants to share code. Rect is mainly an SDL thing, with a whole bunch of niceties mostly at the python integration level. I'm not sure how to separate any of that really. There are pure python implementations of Rect, and perhaps you could use that to implement something in RPython for integration with pypy? But I think perhaps this runs into the case where integrating with C is slower in CFFI when there are lots of calls which take very little time. I'm sure the pypy CFFI people could help you there.
Again, there are definitely some good use cases for pypy, and CFFI. Even in games. Like in your game. But for me, and for the reasons above, I don't think it's a good idea for pygame. At the moment.
I like this trend where people have decided to work together to get things into the CPython project, rather than do forks.