Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!uio.no!nntp.uib.no!svn.schaathun.net!not-for-mail From: Hans Georg Schaathun Newsgroups: comp.lang.python Subject: Re: client-server parallellised number crunching Date: Wed, 27 Apr 2011 19:28:06 +0100 Organization: University of Bergen Lines: 23 Message-ID: References: <8ikj88-bs1.ln1@svn.schaathun.net> <1cel88-0d3.ln1@svn.schaathun.net> <90ll88-1h3.ln1@svn.schaathun.net> NNTP-Posting-Host: vannskorpion.bccs.uib.no X-Trace: toralf.uib.no 1303930028 47981 129.177.20.20 (27 Apr 2011 18:47:08 GMT) X-Complaints-To: abuse@uib.no NNTP-Posting-Date: 27 Apr 2011 18:47:08 GMT User-Agent: slrn/pre1.0.0-18 (Linux) Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:4149 On Thu, 28 Apr 2011 00:58:22 +1000, Chris Angelico wrote: : thousand threads? a couple of million? In Python, it'll probably end : up pretty similar; chances are you won't be taking much advantage of : multiple CPUs/cores (because the threads will all be waiting for : socket read, or the single thread will mostly be waiting in select()), : so it's mainly a resource usage issue. Probably worth testing with : your actual code. For my own application, the performance issue is rather negligible. I don't have more than about 50 idle CPU-s which I can access easily, and even if I had, it would always stop at 6-7000 functions calls to evaluate. In the current test runs using 4 clients and one master on a quad-core, the master never uses more than around 7% of a core, and that includes some simple post-processing as well as com's. In short, my philosophy is that it works, so why change it? But, I am aware that some more technical adept programmers think otherwise, and I am quite happy with that :-) -- :-- Hans Georg