Will multithreading make python less popular?
tim.wintle at teamrubber.com
Fri Feb 20 00:16:32 CET 2009
On Thu, 2009-02-19 at 12:18 -0800, Paul Rubin wrote:
> If such
> speedups were useless or unimportant, we would not have blown our hard
> earned cash replacing perfectly good older hardware, so we have to
> accept the concept that speed matters and ignore those platitudes that
> say otherwise.
Kind of agree (although I use a netbook at lot at the moment, and I
don't use that because of speed-ups!)
> It used to be that new computers were faster than the old ones because
> they ran at higher clock rates. That was great, no software changes
> at all were required to benefit from the higher speed. Now, they get
> the additional speed by having more cores. That's better than nothing
> but making use of it requires fixing the GIL.
My opinion on this (when talking about personal computers rather than
servers) is that:
Computers *appear* faster now because they have more cores - you can
have one doing the fancy GUI effects of Compiz etc. in the background,
while the other core actually does the work.
Actual speedups aren't that related to either clock speed or cores at
the moment, they're related to the switch to 64-bit processors, the
massive increases in RAM and the increase in system bus speeds and other
IO (and of course graphics cards). I suspect that the next common
increase will be solid state hard disks.
e.g. I used to expect my computer to be paging all the time, although
I'd try to reduce it - these days I'm really upset when I see I've had
to page *anything* to disk!
Another massive increase (which I am willing to pay more for with the
work I do) is the processor cache - at first it was amazing when we got
significant level2 cache advertised on pc equipment, now I can fit
massive amounts of code into my 4mb level-2 cache *on my laptop*! That's
a huge impact for numerical work.
Multiple cores scale processing power linearly at best with the number
of cores (since you're normally going to be IO based at some point).
Perhaps the GIL will be relaxed a bit, but it's not going to have a
More information about the Python-list