Kent, Thanks for the link. I am just lazy (that's why I like Python over C/ CPP/ObjC when I can get away with it) and would prefer the lightweight (to design and code that is not as in process overhead) threads over separate application processes. But certainly you get more flexibility and power for the increased effort. TANSTAAFL. I'll give it a shot and see what it can do. Maybe spawning a number python interpreters (one for each processor core) and see what the cumulative pystone is though it would be an Apples to Oranges comparison...oh wait... <insert clever Apple pun here> ;-)
On Jan 21, 2008, at 5:33 AM, Kent Johnson wrote: > Daniel Lord wrote: >> My point was that, as I understand it, thanks to the GIL--Python >> cannot easily take advantage of multi-cores period even when the >> program uses multiple threads--it it is a limitation of the >> implementation of the language interpreter. I guess that tells us >> we ought to write multi-core code in C/C++/ObjC instead. Either >> that or Python's implementation needs to embrace threading more >> expansively. > > Or don't use threading for multiprocessing. Current best practice > seems to be to use a multiprocessing model to distribute Python > programs. There are quite a few add-on packages which support this: > http://wiki.python.org/moin/ParallelProcessing > > Kent _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
