dual processor

Jorgen Grahn jgrahn-nntq at algonet.se
Tue Sep 6 19:22:19 CEST 2005

On Mon, 05 Sep 2005 21:43:07 +0100, Michael Sparks <ms at cerenity.org> wrote:
> Steve Jorgensen wrote:
>> I don't get that.  Python was never designed to be a high performance
>> language, so why add complexity to its implementation by giving it
>> high-performance capabilities like SMP? 
> It depends on personal perspective. If in a few years time we all have
> machines with multiple cores (eg the CELL with effective 9 CPUs on a chip,
> albeit 8 more specialised ones), would you prefer that your code *could*
> utilise your hardware sensibly rather than not.
> Or put another way - would you prefer to write your code mainly in a
> language like python, or mainly in a language like C or Java? If python,
> it's worth worrying about!

Mainly in Python, of course. But it still feels like a pretty perverted idea
to fill a SMP system with something as inefficient as interpreting Python

   (By the way, I don't understand why a computer should run one program at
   a time all the time. Take a time-sharing system where lots of people are
   logged in and do their work. Add a CPU there and you'll have an immediate
   performance gain, even if noone is running programs that are optimized
   for it!)

I feel the recent SMP hype (in general, and in Python) is a red herring. Why
do I need that extra performance? What application would use it? Am I
prepared to pay the price (in bugs, lack of features, money, etc) for
someone to implement this?  There's already a lot of performance lost in
bloatware people use everyday; why are we not paying the much lower price
for having that fixed with traditional code optimization?

I am sure some applications that ordinary people use could benefit from SMP
(like image processing). But most tasks don't, and most of those that do can
be handled on the process level. For example, if I'm compiling a big C
project, I can say 'make -j3' and get three concurrent compilations. The
Unix shell pipeline is another example.


  // Jorgen Grahn <jgrahn@       Ph'nglui mglw'nafh Cthulhu
\X/                algonet.se>   R'lyeh wgah'nagl fhtagn!

More information about the Python-list mailing list