A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-list/2005-September/348385.html below:

dual processor

dual processorSteve Jorgensen nospam at nospam.nospam
Mon Sep 5 15:26:28 EDT 2005
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.  Phyton was never designed to be a high performance
language, so why add complexity to its implementation by giving it
high-performance capabilities like SMP?  You can probably get a bigger speed
improvement for most tasks by writing them in C than by running them on 2
processors in an inerpreted language.

Instead of trying to make Python into a high-performance language,  why not
try to factor out the smallest possible subset of the program that really
needs the performance boost, write that as a library in C, then put all the
high-level control logic, UI, etc. in Python?  The C code can then use threads
and forks if need be to benefit from SMP.


More information about the Python-list mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4