Hi, It seems complicated to add OpenMP in the code, I don't think many people have the knowlegde to do this, not mentioning the fact that there are a lotof Python calls in the different functions. The multicore Matlab does seems for more related to the underlying libraries than to something they did.
Matthieu 2008/3/22, David Cournapeau <[EMAIL PROTECTED]>: > > Anne Archibald wrote: > > > > There was some discussion of this recently. The most direct approach > > to the problem is to annotate some or all of numpy's inner C loops > > with OpenMP constructs, then provide some python functions to control > > the degree of parallelism OpenMP uses. This would transparently > > provide parallelism for many numpy operations, including sum(), > > numpy's version of IDL's total(). All that is needed is for someone to > > implement it. Nobody has stepped forward yet. > I am not really familiar with openMP (only played with it on toy > problems). From a built point of view, are the problems I could see > without knowing anything: > - compiler support: at source code level, open mp works only through > pragma, right ? So we will get warning for compilers not supporting > openmp if we just use pragam as is (this could be solved with macro I > guess). > - compiler flags and link flags: at least gcc needs flags for > compilation and linking code with open mp. This means detecting whether > the compiler supports it. > > This does not sound too bad, but this needs to work reliably on all > supported platforms. Of course, I can add this to numscons; adding it to > distutils would be a bit more work, but I can do it too if someone else > is willing to do the actual coding in the C sources. > > Now, the main concern I would have is the effectiveness of all this on > simple operations. I note that matlab 2007a, while claiming support for > multi-core, does not use multi-core for simple operations, only for FFT, > BLAS and LAPACK (where this should be possible right now if e.g. using > Intel MKL, am I right ?). Matlab 7.6 supports also things like > element-wise computation (a = sin(b)) > > > http://www.mathworks.com/products/matlab/demos.html?file=/products/demos/matlab/multithreadedcomputations/multithreadedcomputations.html > > Personally, I am wondering whether it would not be more worthwhile to > think first about sse and co, because it can give the same order of > increase in speed, without all the problems linked to multi-threading > (slower in mono-thread case, in particular). > > cheers, > > David > _______________________________________________ > Numpy-discussion mailing list > [email protected] > http://projects.scipy.org/mailman/listinfo/numpy-discussion > -- 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 [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
