Now, I didn't know that. That's cool because I have a new dual core Intel Mac Pro. I see I have some learning to do with multithreading. Thanks. --- Anne Archibald wrote:

On 17/04/07, Lou Pecora wrote:

...

You should probably look over your code and see if you can eliminate loops by using the built in vectorization of NumPy. I've found this can really speed things up. E.g. given element by element multiplication of two n-dimensional arrays x and y replace,

z=zeros(n) for i in xrange(n): z[i]=x[i]*y[i]

with,

z=x*y # NumPy will handle this in a vector fashion

Maybe you've already done that, but I thought I'd offer it.

It's also worth mentioning that this sort of vectorization may allow you to avoid python's global interpreter lock.

Normally, python's multithreading is effectively cooperative, because the interpreter's data structures are all stored under the same lock, so only one thread can be executing python bytecode at a time. However, many of numpy's vectorized functions release the lock while running, so on a multiprocessor or multicore machine you can have several cores at once running vectorized code.

Anne M. Archibald _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org

http://projects.scipy.org/mailman/listinfo/numpy-discussion

-- Lou Pecora, my views are my own. --------------- "I knew I was going to take the wrong train, so I left early." --Yogi Berra __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Ii get what you are saying, but I'm not even at the Stupidly Easy Parallel level, yet. Eventually. Thanks. --- Anne Archibald wrote:

On 17/04/07, Lou Pecora wrote:

...

Now, I didn't know that. That's cool because I have a new dual core Intel Mac Pro. I see I have some learning to do with multithreading. Thanks.

No problem. I had completely forgotten about the global interpreter lock, wrote a little multithreading tool that ran my code in three different threads, and got just about a 2x speedup on a dual-core machine. Then someone reminded me about the GIL and I was puzzled... your results will certainly depend on your code, but I found it useful to have a little parallel-for-loop idiom for all those cases where parallelism is stupidly easy.

Anne _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org

http://projects.scipy.org/mailman/listinfo/numpy-discussion

-- Lou Pecora, my views are my own. --------------- Great spirits have always encountered violent opposition from mediocre minds. -Albert Einstein __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Very nice. Thanks. Examples are welcome since they are usually the best to get up to speed with programming concepts. --- Anne Archibald wrote:

On 17/04/07, Lou Pecora wrote:

...

I get what you are saying, but I'm not even at the Stupidly Easy Parallel level, yet. Eventually.

Well, it's hardly wonderful, but I wrote a little package to make idioms like:

[cut] -- Lou Pecora, my views are my own. --------------- Great spirits have always encountered violent opposition from mediocre minds. -Albert Einstein __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On 18/04/07, Sebastian Haase wrote:

Hi Anne, I'm just starting to look into your code (sound very interesting - should probably be put onto the wiki) -- quick note: you are mixing tabs and spaces :-( what editor are you using !?

Agh. vim is misbehaving. Sorry about that. I just took another look at that code and added a parallel_map I hadn't got around to writing before, too. I'd be happy to stick it (and test file) on the wiki under some open license or other ("do what thou wilt shall be the whole of the law"?). It's certainly not competition for ipython1, though, it's mostly to show an example of making threads easy to use. Anne

Hi Anne, Your reply to Lou raises a naive follow-up question of my own...

Normally, python's multithreading is effectively cooperative, because the interpreter's data structures are all stored under the same lock, so only one thread can be executing python bytecode at a time. However, many of numpy's vectorized functions release the lock while running, so on a multiprocessor or multicore machine you can have several cores at once running vectorized code.

Are you saying that numpy's vectorized functions will perform a single array operation in parallel on a multi-processor machine, or just that the user can explicitly write threaded code to run *multiple* array operations on different processors at the same time? I hope that's not too stupid a question, but I haven't done any threaded programming yet and the answer could be rather useful... Thanks a lot, James.

I would say that if the underlying atlas library is multithreaded, numpy operations will be as well. Then, at the Python level, even if the operations take a lot of time, the interpreter will be able to process threads, as the lock is freed during the numpy operations - as I understood for the last mails, only one thread can access the interpreter at a specific time - Matthieu 2007/4/17, James Turner :

Hi Anne,

Your reply to Lou raises a naive follow-up question of my own...

...

Normally, python's multithreading is effectively cooperative, because the interpreter's data structures are all stored under the same lock, so only one thread can be executing python bytecode at a time. However, many of numpy's vectorized functions release the lock while running, so on a multiprocessor or multicore machine you can have several cores at once running vectorized code.

Are you saying that numpy's vectorized functions will perform a single array operation in parallel on a multi-processor machine, or just that the user can explicitly write threaded code to run *multiple* array operations on different processors at the same time? I hope that's not too stupid a question, but I haven't done any threaded programming yet and the answer could be rather useful...

Thanks a lot,

James.

_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

On 4/17/07, Robert Kern wrote:

Matthieu Brucher wrote:

...

I would say that if the underlying atlas library is multithreaded, numpy operations will be as well. Then, at the Python level, even if the operations take a lot of time, the interpreter will be able to process threads, as the lock is freed during the numpy operations - as I understood for the last mails, only one thread can access the interpreter at a specific time -

ATLAS doesn't *underlie* much of numpy at all. Just dot() and the functions in linalg, nothing else.

Hi, I don't know much about ATLAS -- would there be other numpy functions that *could* or *should* be implemented using ATLAS !? Any ? -Sebastian

On 18/04/07, Robert Kern wrote:

Sebastian Haase wrote:

...

Hi, I don't know much about ATLAS -- would there be other numpy functions that *could* or *should* be implemented using ATLAS !? Any ?

Not really, no.

ATLAS is a library designed to implement linear algebra functions efficiently on many machines. It does things like reorder the multiplications and additions in matrix multiplication to make the best possible use of your cache, as measured by empirical testing. (FFTW does something similar for the FFT.) But ATLAS is only designed for linear algebra. If what you want to do is linear algebra, look at scipy for a full selection of linear algebra routines that make fairly good use of ATLAS where applicable. It would be perfectly possible, in principle, to implement an ATLAS-like library that handled a variety (perhaps all) of numpy's basic operations in platform-optimized fashion. But implementing ATLAS is not a simple process! And it's not clear how much gain would be available - it would almost certainly be noticeably faster only for very large numpy objects (where the python overhead is unimportant), and those objects can be very inefficient because of excessive copying. And the scope of improvement would be very limited; an expression like A*B+C*D would be much more efficient, probably, if the whole expression were evaluated at once for each element (due to memory locality and temporary allocation). But it is impossible for numpy, sitting inside python as it does, to do that. Anne M. Archibald

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anne Archibald wrote:

It would be perfectly possible, in principle, to implement an ATLAS-like library that handled a variety (perhaps all) of numpy's basic operations in platform-optimized fashion. But implementing ATLAS is not a simple process! And it's not clear how much gain would be available - it would almost certainly be noticeably faster only for very large numpy objects (where the python overhead is unimportant), and those objects can be very inefficient because of excessive copying. And the scope of improvement would be very limited; an expression like A*B+C*D would be much more efficient, probably, if the whole expression were evaluated at once for each element (due to memory locality and temporary allocation). But it is impossible for numpy, sitting inside python as it does, to do that.

numexpr (in the scipy sandbox) does something like this: it takes an expression like A*B+C*D and constructs a small bytecode program that does that calculation in chunks, minimising temporary variables and number of passes through memory. As it is, the speed is faster than the python expression, and comparable to that of weave. I've been thinking of making a JIT for it, but I haven't had the time :) - -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJbvTN9ixZKFWjRQRAi+WAJ9HmeCTeB59Jso5vlVzbgHQ0TDj9ACfdKWy jYEnsRYau8T5BVAKnZJWpLk= =75Jc -----END PGP SIGNATURE-----

Sebastian Haase wrote:

On 4/17/07, Anne Archibald wrote:

...

On 18/04/07, Robert Kern wrote:

...

Sebastian Haase wrote:

...

Hi, I don't know much about ATLAS -- would there be other numpy functions that *could* or *should* be implemented using ATLAS !? Any ? Not really, no. ATLAS is a library designed to implement linear algebra functions efficiently on many machines. It does things like reorder the multiplications and additions in matrix multiplication to make the best possible use of your cache, as measured by empirical testing.

So, this means that 'matrixmultiply' could / should be using ATLAS for the same reason as 'dot' does - right ?

matrixmultiply() is just a long-deprecated alias to dot(). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

Sebastian Haase wrote:

Does ATLAS/BLAS do anything special for element wise multiplication and alike - if for example the data is not aligned or not contiguous?

Nothing that ATLAS optimizes, no. They focus (rightly) on the more complicated matrix operations (BLAS Level 3, if you are familiar with the BLAS levels). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

On 17/04/07, Francesc Altet wrote:

Finally, don't let benchmarks fool you. If you can, it is always better to run your own benchmarks made of your own problems. A tool that can be killer for one application can be just mediocre for another (that's somewhat extreme, but I hope you get the point).

And, also important, don't forget that the time you usually care about is the time until you obtain a correct solution of your problem - which includes the time to write the code and the time to debug the code. I find that it's extremely rare that the extra time it takes to write highly-optimized code is worth the time it saves to run. Anne M. Archibald