sorry for the long delay in writing I have been a little busy over the last few days (maybe its been trying to keep up with all of eds commits!) ;-)
On Nov 3, 2007 4:43 AM, Andrew Perry <
ajperry@xxxxxxxxxxxxxx> wrote:
(This was a personal email I sent Edward recently, but he suggested the relax dev's may like to see it since it does raise an important issue to keep in mind for future design decisions)
many thanks it seems like a good Idea here as well
Not sure if you read the discussion linked via Slashdot about Python 3000, Bruce Eckel vs Guido,
here, here and
here.
I did and it is is very interesting. It does in a way invalidate the need for the thread based implementation I created in the in the multi branch for cpython before I read this. However there is another point to consider: this is _at the moment_ but may point to a future when the GIL (Global Interpreter Lock) free threading is possible.... (It is something python need to look at as machines
will (not even might) become massivley parallel in the near future).
I just discovered something important I never realized (or maybe discovered, then forgot again):
"I know
that true concurrency support -- the ability to run pieces of a program
on multiple processors -- is hard in a dynamic language. Although they
both have threads, neither Python nor Ruby is able to actually allocate
those threads to multiple processors. The
[snip]...
This is a good reason to have gone with a master-slave type model with independent processes in relax ... pythons threads apparently wouldn't help on a multi-CPU machine ! Yek !
Indeed! and this is good as it is what the multi branch does. The good news is several fold
1. even though threads are useless for speedup in cpython at the moment I have implimented a threads based version (which I will maintain despite is uselessness! Though I will have to document the problems and issue warnings) and we now know that the library can support threads (it was a worthwhile exercise as being able to use threads does affect the form of the library due to the issue of running in a shared address space)
2. Not all python implementations have a GIL. This iron python and jython both don't have a GIL (I am not sure about pypy) and there are quite encouraging indications about the competitive speed of ironpython (see
http://www.python.org/pycon/dc2004/papers/9/) and I believe jython under host spot can also in some cases out pace cpython due to byte code optimisation at runtime.
I hope this gives a good overview of the current status the multi branch with respect to threada
Andrew
On a related note to Andrew I wanted to re-implement the ssh tunnels code under the new library would you be able to give some pointers at some point as it looks 'tricky'
regards
gary
--
Postdoctoral Researcher, Trevor Lithgow Lab
Department of Biochemistry and Molecular Biology
Bio21 Molecular Science and Biotechnology Institute
30 Flemington Road, University of Melbourne
Parkville 3010, AUSTRALIA
Ph: +61 3 834442298 || Email:
ajperry@xxxxxxxxxxxxxx
----
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: Threads in Python