[Numpy-discussion] Fast threading solution thoughts

Matthieu Brucher matthieu.brucher@gmail....
Thu Feb 12 08:24:46 CST 2009

2009/2/12 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
> Matthieu Brucher wrote:
>>> No - I have never seen deep explanation of the matlab model. The C api
>>> is so small that it is hard to deduce anything from it (except that the
>>> memory handling is not ref-counting-based, I don't know if it matters
>>> for our discussion of speeding up ufunc). I would guess that since two
>>> arrays cannot share data (COW-based), lock handling may be easier to
>>> deal with ? I am not really familiar with multi-thread programming (my
>>> only limited experience is for soft real-time programming for audio
>>> processing, where the issues are totally different, since latency
>>> matters as much if not more than throughput).
>> It's not even a matter of multithread programming, in mono-core
>> programming, the same issue can arise.
> Which issue ?

Sorry, I was refering to my last mail, but I sent so many in 5 minuts ;)
In C, if you have to arrays (two pointers), the compiler can't make
aggressive optimizations because they may intersect. With Fortran,
this is not possible. In this matter, Numpy behaves like C (everyone
heard about the different a[indices] += a[other_intersecting_indices]
issues), Matlab is more like Fortran.

Information System Engineer, Ph.D.
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

More information about the Numpy-discussion mailing list