Regarding fast SciPy. The problem is that you need to use ATLAS to tune the BLAS and LAPACK code to your system and then compile it yourself for your specific hardware. The standard libraries you get aren’t optimised for specific hardware. At least that is what I understand… I haven’t bothered doing this myself yet.

The problem is that the top level of scipy is in python. Thus when you call some scipy matrix operations from pyrex code it has to go from compiled C into the python interpreter and then through a few levels of python wrapper code before going into the compiled BLAS libraries to perform the computation. Same coming back out from a matrix operation. As interpreted python is around 100 times slower than C, this wrapper code kills the performance when making a large number of calls to small matrices. Ideally somebody should make a pyrex wrapper for BLAS to avoid this overhead…

Why not?
If you work for a customer, you can create separate installation for customer-platform, don’t you?

It’s not a criticizm – I suppose you’re more experienced in this area (and I’m not even novice yet)

Anyway:
1. Thanks. I will track your blog
2. I apologize for my English =)

If I have some nice ndarrays that I’m working with and want to do something like an efficient dot product then I’m going to hove to somehow cross from the ndarray world into the BLAS world. I guess that Numpy has to do a bit of magic to make this happen and that’s what slowing down the calls. I guess that I would have to essentially replicate this… which might end up being just as slow?

Maybe I should look into the guts of Numpy to see what is actually going on…

Also if your server is bogging down, you could offload visitors to the LJ feed, http://syndicated.livejournal.com/vetta_project_2/