Mike Meyer wrote:
See 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 Jav
Peter Hansen <[EMAIL PROTECTED]> 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 tal
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
"It's me" <[EMAIL PROTECTED]> 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.
(...)
Interestin
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 proces
>>> 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 t
"Gurpreet Sachdeva" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> 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
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
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 tha
Duncan Booth <[EMAIL PROTECTED]> 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 usef
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
You haven't split the task between the threads here.
loops should be set to [2500,2500] for a correct comparison.
On a single processor system, a tight loop like the one you are
testing will at best show the same time as the non-threaded case. Most
likely the threaded version will take more time o
>threads[i].join()
Oh thanks I corrected that but still the time taken after using thread
is more without using them
Please Advice...
Thanks,
Gurpreet Singh
--
http://mail.python.org/mailman/listinfo/python-list
Gurpreet Sachdeva <[EMAIL PROTECTED]> wrote:
> for i in nloops: # wait for all
> threads[i].join
Missing () after 'join'.
Alex
--
http://mail.python.org/mailman/listinfo/python-list
Gurpreet Sachdeva wrote:
>for i in nloops: # wait for all
>threads[i].join
threads[i].join()
--
http://mail.python.org/mailman/listinfo/python-list
15 matches
Mail list logo