dual processor

[Jeremy Jones]

Michael Sparks wrote:

>Steve Jorgensen wrote:
>
>  
>
>>On 05 Sep 2005 10:29:48 GMT, Nick Craig-Wood <nick at craig-wood.com> wrote:
>>
>>    
>>
>>>Jeremy Jones <zanesdad at bellsouth.net> wrote:
>>>      
>>>
>>>> One Python process will only saturate one CPU (at a time) because
>>>> of the GIL (global interpreter lock).
>>>>        
>>>>
>>>I'm hoping python won't always be like this.
>>>      
>>>
>>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. 
>
Ummmm....not totally.  It depends on what you're doing.  If what you're 
doing is not going to be helped by scaling across a bunch of CPUs, then 
you're just as well off if Python still has the GIL.  Sort of.  Steve 
brings up an interesting argument of making the language do some of your 
thinking for you.  Maybe I'll address that momentarily....

I'm not saying I wish the GIL would stay around.  I wish it would go.  
As the price of computers goes down, the number of CPUs per computer 
goes up, and the price per CPU in a single system goes down, the ability 
to utilize a bunch of CPUs is going to become more important.  And maybe 
Steve's magical thinking programming language will have a ton of merit.

>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.
>  
>
I'm not picking on you.  Trust me.  But let me play devil's advocate for 
a sec.  Let's say we *could* fully utilize a multi CPU today with 
Python.  What has that bought us (as the amorphous "we" of the Python 
community)?  I would almost bet money that the majority of code would 
not be helped by that at all.  I'd almost bet that the vast majority of 
Python code out there runs single threaded and would see no performance 
boost whatsoever.  Who knows, maybe that's why we still have the GIL.

>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? 
>
There are benefits to writing code in C and Java apart from 
concurrency.  Most of them are massochistic, but there are benefits 
nonetheless.  For my programming buck, Python wins hands down.

But I agree with you.  Python really should start addressing solutions 
for concurrent tasks that will benefit from simultaneously utilizing 
multiple CPUs.

>If python,
>it's worth worrying about!
>
>If it was python (or similar) you might "only" have to worry about
>concurrency issues. If it's a language like C you might have to worry
>about  memory management, typing AND concurrency (oh my!).
>(Let alone C++'s TMP :-)
>
>Regards,
>
>
>Michael
>  
>
JMJ