Problem in threading

[Gurpreet Sachdeva]

I have written a code to figure out the difference in excecution time
of a func before and after using threading...

#!/usr/bin/env python
 
import threading
import time
loops = [5000,5000]
 
def loop(self, nsec):
for i in range(1,nsec):
t=i*5000
s=t/10*15555
 
def main():
threads = []
nloops = [0,1]
for i in nloops:
print '\nSpawning Thread',i,' value: ',loops[i]
t = threading.Thread(target=loop,args=(i, loops[i]))
threads.append(t)
 
for i in nloops: # start threads
threads[i].start()
 
for i in nloops: # wait for all
threads[i].join
 
if __name__ == '__main__':
start = time.clock()
loop(1,5000)
print 'Time Taken: ', time.clock()-start
start = time.clock()
main()
print 'Time Taken: ', time.clock()-start
 

Some times this code executes and some times it hangs to death :o(
Am I am doing something wrong?? Also the difference of time is not much...
How do we best optimize our task by using threads... please help...

Thanks and Regards,
Gurpreet Singh

[Alex Martelli]

Gurpreet Sachdeva <gu***************@gmail.com> wrote:

for i in nloops: # wait for all
threads[i].join

Missing () after 'join'.
Alex

[Duncan Booth]

Gurpreet Sachdeva wrote:

Also the difference of time is not much...
How do we best optimize our task by using threads... please help...

For most tasks splitting the processing into separate threads will result
in an increase in the total time to complete the task. The only times when
it may result in a decrease in the running time are when the time the task
takes does not entirely depend on the time taken by the CPU, or when
multiple CPU's are involved.

Unfortunately the latter case isn't handled well by Python, so don't expect
multiple CPU's to help speed up a multi-threaded Python program by very
much. That leaves the former case: if your task has to stop and wait for
something else to happen (e.g. data to be read from a network, or to be
read from a disc file), then splitting it into multiple threads may allow
the waits to be overlapped with useful processing which could result in an
overall decrease in processing time.

A good use of threads is to improve responsiveness of a system. For example
if you ensure that GUI processing happens on a separate thread from some
CPU intensive computation then you can ensure that the GUI remains
responsive while the computation is running. It won't make the computation
complete any faster (in fact it will probably be slower), but the user will
remain happier. Similarly network applications are usually multi-threaded
so that all requests get a fair chance to complete instead of having to
wait for the slowest to complete before others can run.

If you do have multiple processors available and want to speed up a Python
program then you probably have to look at multiple processes rather than
multiple threads. Alternatively you could move parts of the processing out
of the Python environment by rewriting inner loops in C and releasing the
interpreter lock, but that isn't usually the best option.

[Mike Meyer]

Duncan Booth <du**********@invalid.invalid> writes:

That leaves the former case: if your task has to stop and wait for
something else to happen (e.g. data to be read from a network, or to
be read from a disc file), then splitting it into multiple threads
may allow the waits to be overlapped with useful processing which
could result in an overall decrease in processing time.

If you're on a Unix-like system, you'll use less aspirin if you do
this kind of thing with async I/O and the select module. If you're on
Windows, the restrictions on what you can select on make it much less
useful. Python's threading models is pretty primitive. You get the C
model (which is error-prone), the Java model (in 2.4, and also
error-prone), or Queues. Queues aren't error-prone, but result in the
same kind of behavior as you get with select: start I/O, do computing
while I/O is going on, block until I/O is complete.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Peter Hansen]

Mike Meyer wrote:

Python's threading models is pretty primitive. You get the C
model (which is error-prone), the Java model (in 2.4, and also
error-prone), or Queues.

Can you please expand on your words above? I have no idea
what you are talking about with the "Java model" and your
implication that it is something new in Python 2.4. As
far as I know, nothing significant with respect to threads
has changed in Python recently.

-Peter

[Gurpreet Sachdeva]

I wrote:

Also the difference of time is not much...
How do we best optimize our task by using threads... please help...

Duncan Booth Wrote:The only times when it may result in a decrease
in the running time... are when the time the task...when
multiple CPU's are involved. I fotgot to mention that I am running that script on a 4 node Open SSI
cluster with 8 processors to do the job...
Unfortunately the latter case isn't handled well by Python Very Strange!
A good use of threads is to improve responsiveness of a system. For example
if you ensure that GUI processing happens on a separate thread from some
CPU intensive computation then you can ensure that the GUI remains
responsive while the computation is running. It won't make the computation
complete any faster (in fact it will probably be slower), but the user will
remain happier. Similarly network applications are usually multi-threaded
so that all requests get a fair chance to complete instead of having to
wait for the slowest to complete before others can run.
So That means blindly using threads on any process won't help!
probably have to look at multiple processes rather than
multiple threads.
How do I do that??? Does that mean forking the processes or does that
mean to change the entire architecture to do small tasks in different
processes???
Alternatively you could move parts of the processing out
of the Python environment by rewriting inner loops in C

Any reference/documentation for that???

Thanks and Regards
Gurpreet

[It's me]

"Gurpreet Sachdeva" <gu***************@gmail.com> wrote in message
news:ma**************************************@pyth on.org...

So That means blindly using threads on any process won't help!

It depends on what "help" means to you. Both Windows and Unix (and it's
variances) are considered "thread-weak" OSes. So, using thread will come
with some cost. The long gone IBM OS/2 is a classic example of a
"thread-strong" OS.

Still, a good use of thread would be, for example, a name-pipe server. See
for instance:

http://www-106.ibm.com/developerwork...,l=252,p=pipes

Here you will see a performance improvement when threads are being used.

The example you listed isn't a good use of thread for performance
improvement sake.

[Gurpreet Sachdeva]

>>> So That means blindly using threads on any process won't help!

It depends on what "help" means to you.
Help means to improve processing speed in achieving a particular
task... *Help* here also means that I have a processor farm, how do I
best use them to get maximum processing speed out of them...
The example you listed isn't a good use of thread for performance

The example was a dummy one to become friendly with Threads and to
understand the working/power of them... The example which will be
finally used with threads take 5 Days to complete... I want to convert
that in few hours!

Long Journey ahead...

Thanks,
Garry

[Steve Holden]

Gurpreet Sachdeva wrote:

So That means blindly using threads on any process won't help!
It depends on what "help" means to you.

Help means to improve processing speed in achieving a particular
task... *Help* here also means that I have a processor farm, how do I
best use them to get maximum processing speed out of them...

And that's the crux of your problem.

Firstly, you've discovered that attempts to partition a task using
threads won't work well with a compute-intensive algorithm, since
multiple threads will simply contend against each other for CPU in a
single process.

This is not assisted by Python's use of a global interpreter lock (GIL)
to ensure thread-safety.

A thread can release the GIL, but typically it will do this only when
it's involved in some blocking operation. This means that threading can
be useful to speed up network operations, for example, but even then you
might get a better speedup using explicitly asynchronous techniques
based on non-blocking sockets.

The example you listed isn't a good use of thread for performance

The example was a dummy one to become friendly with Threads and to
understand the working/power of them... The example which will be
finally used with threads take 5 Days to complete... I want to convert
that in few hours!

In that case you definitely need to be looking at multiprocess
algorithms if you are sticking with Python. Since each process has its
own copy of the interpreter, they each also have their own GIL, and so
the operating system will be able to schedule the processes in parallel
on separate CPUs.
Long Journey ahead...

Indeed, but an interesting one, no doubt. Good luck.

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[David Bolen]

"It's me" <it***@yahoo.com> writes:

It depends on what "help" means to you. Both Windows and Unix (and it's
variances) are considered "thread-weak" OSes. So, using thread will come
with some cost. The long gone IBM OS/2 is a classic example of a
"thread-strong" OS.

(...)

Interesting - can you clarify what you perceive as the differences
between a thread-weak and thread-strong OS? If given the choice, I
would probably refer to Windows (at least NT based systems, let's
ignore 9x) as thread-strong, and yes, often think of Windows as
preferring thread based solutions, while Unix would often prefer
process based.

Windows is far more efficient at handling large numbers of threads
than it is processes, with much less overhead and there is lots of
flexibility in terms of managing threads and their resources. Threads
are first class OS objects at the kernel and scheduler level (waitable
and manageable).

I can't think of anything offhand specific that OS/2 did with respect
to threads that isn't as well supported by current Win32 systems.

-- David

[It's me]

That's an OT topic. :=)

There were lots of discussions about this topic in the old days. No need
to dive into it again.

Windows context switching overhead is very high. You would be lucky to get
it down to the mid-30ms. OS/2 can get it down to less then 10. And for
OS/2, thread swithing time is only a few machine instructions....OT.OT.
"David Bolen" <db**@fitlinxx.com> wrote in message
news:ua***********@fitlinxx.com...

"It's me" <it***@yahoo.com> writes:

It depends on what "help" means to you. Both Windows and Unix (and it's variances) are considered "thread-weak" OSes. So, using thread will come with some cost. The long gone IBM OS/2 is a classic example of a
"thread-strong" OS.

(...)

Interesting - can you clarify what you perceive as the differences
between a thread-weak and thread-strong OS? If given the choice, I
would probably refer to Windows (at least NT based systems, let's
ignore 9x) as thread-strong, and yes, often think of Windows as
preferring thread based solutions, while Unix would often prefer
process based.

Windows is far more efficient at handling large numbers of threads
than it is processes, with much less overhead and there is lots of
flexibility in terms of managing threads and their resources. Threads
are first class OS objects at the kernel and scheduler level (waitable
and manageable).

I can't think of anything offhand specific that OS/2 did with respect
to threads that isn't as well supported by current Win32 systems.

-- David

[Mike Meyer]

Peter Hansen <pe***@engcorp.com> writes:

Mike Meyer wrote:

Python's threading models is pretty primitive. You get the C
model (which is error-prone), the Java model (in 2.4, and also
error-prone), or Queues.

Can you please expand on your words above? I have no idea
what you are talking about with the "Java model" and your
implication that it is something new in Python 2.4. As
far as I know, nothing significant with respect to threads
has changed in Python recently.

See <URL: http://docs.python.org/lib/module-threading.html > which
clearly has the words "New in 2.4" on it. It also says that the
threading module is loosely based on the Java model. I may have
misinterpreted what the "New in 2.4" applies to, which means that the
comment about the Java model being new in 2.4 would be wrong.

As for error-prone, both models require the programmer to always
obtain locks around critical sections, and to obtain them in an order
that prevents deadlocks, and release them in an order that prevents
starvation.

There are threading models that don't require the programmer to get
the locking right. In those, you basically declare an object as
running on a different thread, and the compiler provides the
appropriate locks for each method. I went looking for a reference to
one such method, but couldn't turn it up, partly because I don't
recall whether I saw it on usenet or a mail list.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Peter Hansen]

Mike Meyer wrote:

See <URL: http://docs.python.org/lib/module-threading.html > which
clearly has the words "New in 2.4" on it. It also says that the
threading module is loosely based on the Java model. I may have
misinterpreted what the "New in 2.4" applies to, which means that the
comment about the Java model being new in 2.4 would be wrong.

You have misinterpreted that. The "New in 2.4" part is not
so much "on" that page as it is "in" it, and specifically
it is right in the section on the new-to-2.4 class "local".

The rest of the threading module is basically unchanged since
a number of versions ago, but thanks for your clarification. :-)

-Peter