> What do you mean by compiling incompatible? It is my understanding > that (for example) Framewave (but also IPP) come in different flavors > (32bit, 64bit) which of course must be compiled in at compile time. > But which CPU is available and which features it delivers is indeed > done at runtime (framewave: fwStaticInit()), the choice of how to > implement things with which assembler code is then up to the framewave > library. > I do not consider it a good idea to write a own dispatcher library > into numpy to choose which opcode to use.
This would enable the detection at runtime of the fast libraries and the choice of the best one. It will indeed be an additional dispatcher, but not every numerical library has such a dispatcher, and the dispatcher only works for one library and not for the whole Python module. > Or do it get you completly wrong? Is your intention to make a plugin > architecture in the sense of: copy some directory with libs and config > in your site-packages and then your multiplications are much faster? I > would consider such a framework a bit overengineered, since speedy > calculations are a nice feature for every numpy user. You have to detect the presence of the library. If there are no such framework, you have to compile the module again (and for scipy under Windows, it is not simple). So developing a good plugin framework will help people code fast libraries plugins if it is possible, there will be only one module and not one for Intel/AMD/Atlas/CUDA/... thus less bugs, ... Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
