Ten years of PyPy

Re:Ten years of PyPy by fijal on Thursday February 28, 2013 @05:38PM (#5301594)

You should complain. There is a myriad of reasons why PyPy won't go very fast, for example you're using C extensions. Usually what happens if you have code where parts go insanely fast and parts go insanely slow. Once you identify it, sometimes it is just replacing the library (like pgsql2 -> pgsql2cffi or so) and stuff flies. But it all depends on your workload and the stack a lot. R&D is typically needed to get good speedups. For most RW examples, 2-10x are to be expected.

Shameless plug - if your stuff is not open source and you can't be bothered to do the profiling yourself, there is typically an option to hire someone to do it for you. Get in touch.

[ Parent | on HN ]

Re:Ten years of PyPy by legutierr on Friday March 01, 2013 @06:56AM (#5303826)

Could you explain what you meant when you wrote:

> Another option we tried was using RPython to write CPython C extensions. Again, it turned out RPython is a bad language and instead we made a fast JIT, so you don't have to write C extensions.

On the surface it would seem that using RPython would be a boon to authors of C extensions, so this surprises me. It is also kind of shocking to hear the authors of such a great project basically condemn the language that it was written in (and really, the original raison d'etre of the project itself) as "bad".

[ Parent | on HN ]

Re:Ten years of PyPy by fijal on Friday March 01, 2013 @07:57AM (#5303994)

Whether RPython is a good or a bad language is a subjective fact and it should not be related to the fact whether I wrote it or not right? It's good for what it does (writing VMs), or at least better than writing them in C++ including JIT by hand, but it's much worse than Python. Hence using it for a general purpose project is a bad bad idea and you should use Python instead.

[ Parent | on HN ]