i still don't understand why the jit can't also do a decent job on "easy" code. i can see that sse and, as you mention, the need for warm up would be an issue.

i still don't understand why the jit can't also do a decent job on "easy" code. i can see that sse and, as you mention, the need for warm up would be an issue. but if that is the case why not include ways to support sse and flag that assumptions about types are reliable in python? (or, if that's just too hard, make it easy to mix rpython and python - perhaps i am mistaken here but last time i looked that seemed to be completely undocumented and apparently hard). it's often the case in numerical code that there's some algorithm that you can't convert into standard matrix routines, but you still want it to run fast. when you're using BLAS + fortran (or c) that's not a problem. but here it will be. sure, that was also an issue with numpy - but why can't pypy be better than old numpy? [i am not trying to ask for the technically impossible here - i'm saying that numpy is not so amazingly different that rpython isn't going to be necessary for other projects. either make rpython accessible, or do numpy in some other way - what bugs me is the "we can use rpython because we're special, but you can't because you don't need the power" attitude]