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: About threads in python Date: Mon, 25 Apr 2011 20:31:27 +0100 Organization: University of Bergen Lines: 21 Message-ID: References: <47d21fd4-22d3-4ee0-bdc2-a3643af4fc9e@t16g2000vbi.googlegroups.com> NNTP-Posting-Host: vannskorpion.bccs.uib.no X-Trace: toralf.uib.no 1303759737 75227 129.177.20.20 (25 Apr 2011 19:28:57 GMT) X-Complaints-To: abuse@uib.no NNTP-Posting-Date: 25 Apr 2011 19:28:57 GMT User-Agent: slrn/pre1.0.0-18 (Linux) Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:3989 On Fri, 22 Apr 2011 12:19:56 -0700 (PDT), sturlamolden wrote: : To optimise computational code, notice that Python itself : gives you a 200x performance penalty. That is much more : important than not using all 4 cores on a quadcore processor. : In this case, start by identifying bottlenecks using the : profiler. Then apply C libraries or these or rewrite to Cython. : If that is not sufficient, you can start to think about using : more hardware (e.g. multithreading in C or Cython). This advice : only applies to computational code though. And not necessarily even there. The extra programmers to recode in C come with more than a 200x cost factor. It is almost trivial to make a multithread map implementation which could have exploited umpteen core box were it not for GIL. That would be a cheap gain. It matters little that you could gain 100x more at 200x cost ... Besides, the bottleneck is likely to be deeply embedded in some library like numpy or scipy already. -- :-- Hans Georg