To thread or not to thread

[Sidd]

Hello,
I was recently reading an article on threading in python and I
came across Global Interpreter Lock,now as a novince in python I was
cusrious about

1.Is writing a threaded code in python going to perform well than a
normal python code.If so on what basis can it performance be measured.

2.Is writing a threaded code in python better than a code written in
C/C++ using PTHREADS.

If someone can comment on these questions, it would be great.

 

[Grant Edwards]

I was recently reading an article on threading in python and I
came across Global Interpreter Lock,now as a novince in python
I was cusrious about

1.Is writing a threaded code in python going to perform well
than a normal python code.

It's sort of a corrolary to Amdahls law: on a single CPU
machine, optimally written multi-threaded code will always
perform worse than optimally written single-threaded code.
[Where performance is in terms of CPU efficiency.]

However, it may be very difficult to write optimal
single-threaded code, and much easier to write (nearly) optimal
multi-threaded code. So, in practice, multi-threaded code
often performs better for certain classes of problems.

If so on what basis can it performance be measured.

That's up to whoever is doing the measuring.

2.Is writing a threaded code in python better than a code
written in C/C++ using PTHREADS.

Define "better".

On a multi-CPU machine you can get much more parallelism for
compute-intensive tasks using C/pthreads than you can using
Python threads.

It's also a lot easier to write buggy code containing race
conditions using C/pthreads.

 

[Fuzzyman]

Some people are of the opinion that threads are evil.....

Best Regards,

Fuzzy
http://www.voidspace.org.uk/python

 

[James Richards]

Hello,
I was recently reading an article on threading in python and I
came across Global Interpreter Lock,now as a novince in python I was
cusrious about

1.Is writing a threaded code in python going to perform well than a
normal python code.If so on what basis can it performance be measured.

My last "real" experience with python threads was a while back, on a P-2.
That experience suggested that creating "lots" of threads (a few hundred)
caused some serious performance impacts. I determined, in that instance,
that it was better to write my own implementation to simulate threads.
I had set of classes that pretended to be threads. I had another class
which actually did all the threading for them. It was pretty ugly.

2.Is writing a threaded code in python better than a code written in
C/C++ using PTHREADS.

I agree with the earlier. Define "better." Do you really have a heavily
multi-threaded app? Are these threads all CPU-intensive, or do you just
have a bunch of threads which need some arbitrary scheduling? Is it really
worth re-writing in PTHREADS? Or could you buy a new server and save a few
months in development time by writing your own scheduling?

It all depends on your situation.

If someone can comment on these questions, it would be great.

Heh. You're on Usenet. *Anyone* can comment on these questions.
You should have asked for *useful* comments. ;-)

 

[snacktime]

Hello,
I was recently reading an article on threading in python and I
came across Global Interpreter Lock,now as a novince in python I was
cusrious about

1.Is writing a threaded code in python going to perform well than a
normal python code.If so on what basis can it performance be measured.

2.Is writing a threaded code in python better than a code written in
C/C++ using PTHREADS.

If someone can comment on these questions, it would be great.

If you want performance with an application that does a lot of
concurrent activity, you might take a look at
http://www.twistedmatrix.com which is an event driven framework for
python.
Much better performance than threads with a lot less memory and cpu
usage. Although it does have a bit of a learning curve. In my own
experience it would be faster then a comparable application written
in C using pthreads. We have an application written in twisted that
processes financial applications via bank networks, and at a steady
100tps I get about 1% cpu usage. We tested it up to around 1000tps
before our database server started to get a bit overloaded. Twisted
never used more than 20% of the cpu though.

Chris