Ten years of PyPy
morepypy.blogspot.de
morepypy.blogspot.de
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.
> 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".
Of course, this was a couple years ago, and I don't have access to that codebase anymore. Things might've changed since then...
That being said, if your code is mostly IO-bound or calls into foreign-language libraries, PyPy's speedup of the Python code of course won't help much with your wall time.
I'm definitely not saying that PyPy won't do better than 15x speedup on number crunching code, just pointing out that in the context of NumPyPy a 15x speedup is not very relevant if you want PyPy to be a viable alternative to, say, Julia.
(Disclaimer: I'm a Cython dev)
So pypy speed ups aren't very good in comparison to the best you can achieve using other techniques... but you can mostly use the same tricks in pypy as you can in CPython to get those results there too :)
For stuff that I tried pypy was universally faster than Cython on non-type annotated code and mostly faster on type-annotated code from cython benchmarks.
How common is this in EU projects?
EU money on education are wasted so much. On the other hand infrastructural funds are handled more or less OK.
That's barely true. Although there is some certain amount of buzzwords in every proposal (that's kind of bread an butter for tech people anyway), they are far from what OP says. Sometimes there is some overpromising, but those things are usually secondary aspects, rather than the core idea. Most of the results are beeing used as some developed components by participating companies, some of the work is dropped, and a lot of work is open sourced and few projects are really successful. But that's research anyway. Not all work lead to success here.
I see two very different views here: one thing is to have technical jargon that looks like buzzwords to the uninitiated, another is to have to include, in the proposal, features that you won't implement so that the project is accepted, as mentioned in the original post.
Good work guys.
Was it tested or anyone used it in production to run Dj 1.4? Dj 1.5?