Beatrice Düring wrote:
> Sorry for not having responded on this issue even prior to your email.
>
> We have had discussions some of us to go for a sprint in end week of
> October,
> probably in Germany, where we would focus on clean-up work/refactoring and
> also to discuss plans for a 1.1 release (scope, content, time). The
> sprint plan need to
> be discussed in the upcoming week with a sprint announcement going out.
>
> _My guess_ is that the JIT of course would also be involved in the scope
> of that sprint
> (clean up/refactoring) and that the 1.1 release would also contain
> results from such a clean up.
>
> Some of the reasons for the "silence" in the JIT area is partly because
> of people having vacation
> and post-eu sabbaticals, we have been going to conferences such as
> (Europython, Dyla) to do
> talks about the JIT to get input as well as focusing on getting external
> functions, RPython and
> PyPy to work more smoothly (which was feedback from users and would be
> pypy-users
> at Europython in Vilnius). But yes - we might have been better at
> expressing this.
>
> If i might ask - what are the use cases you are thinking about when
> talking about the JIT
> (and/or the JIT generator?).
I cannot speak for Garry, but I myself would be interested in pypy for
numerical computing in python. Basically, there are cases where numpy is
not enough and require coding in C. The two cases I am thinking are:
- recursive algorithms: this means many functions calls, which are
too expensive in python (eg: imagine you have a two buffers of many
float x, and you want to compute f(x[i], [y[i], nu[i]) = x[i+1] = x[i] +
nu[i] * (x[i] - y[i]); even using ctypes for the trivial computation in
C kills performances because of the many calls)
- algorithms which require many temporaries to be efficient in numpy.
Both of them, if my understanding is right, would be perfect exemples of
easy to optimize using JIT.
David
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev