Python threading (was: Re: global interpreter lock not working as it should)

[DIG]

Hi, Martin v. Lowis !

 On Fri, Aug 09, 2002 at 10:18:45AM +0200, Martin v. Lowis wrote:

> DIG <dig.list at telkel.net> writes:
> 
> > (By the way, your assumption about the increase of thread
> > performance in [1] is right for an ideal world. In the real world,
> > you should precise WHAT is an overall performance for you in YOUR
> > case, because (in my opinion) it is rare enough, when performance
> > can be defined as the number of instruction per time unit.
> 
> Most people do associate "performance" with the time that a certain
> task needs to complete on the computer - the smaller the time, the
> higher the performance.

So, we both were talking about effectiveness of the program, about overall performance, not about processor frequency nor instruction per time unit.

That is why in my post (just after cited block) was added the following: 

  * And even so, I think, you were talking about effectiveness of you program
  * and the whole system -- how effectively you use the performance of your
  * processor, your system to solve your problem.)

Of course, I meant that overall performance. And it hardly can be described as "number of instruction per time unit" because it is not completely clear -- "what instructions ?" And in any case the performance of your _processor_ will be the same (with or without threads). But the effectiveness of your _program_ depends on the relative quantity of instructions for complete your task (i) to total number of instruction (I) per time unit (Eff=i/I).

And if faster switching can increase "i", then faster switching can increase the overall performance.

Imagine completely abstract task: 
Your program have two input and one output channels. Both input channels produce "random" (not necessarily random in strict term) sequences of data like "AABBABBBABABABABAB ..." and "ACACACACCCCACACA ..." (where A, B, and C are blocks of data). And your program must combine only As from both sequences and put them into output channel. Performance of your processor is the same, but effectiveness is very depend on how fast is the switch between the threads (to collect all As and to put them into the output).

> There are other non-functional aspects too, like responsiveness,
> maintainability, etc.

Of course.

[... skipped ...]

> > As Dave said in [7], the big question is: how this patch would
> > affect existing applications (if applied) ? The same question, I
> > suppose, is asked before ANY change in python interpreter.
> 
> The big question is: where is the need for such a feature?

I gave you abstract example above. I suppose we can find something like this in the real world.


Regards,

-- 
DIG (Dmitri I GOULIAEV)