[Lazarus] Threads in Lazarus code base

[ik]

On Wed, Sep 15, 2010 at 13:56, Michael Schnell <mschnell at lumino.de> wrote:

>  On 09/15/2010 12:46 PM, Michael Van Canneyt wrote:
>
>>
>> What is so performance killing about process messages ?
>>
> process message is a function call that obviously take some microseconds to
> run. Thus, if you do it very often, it degrades the overall performance, if
> you do it rather seldom, the latency of the other tasks the program needs to
> do degrades
>
>
>> What do you think the OS does when switching threads ? A thread switch
>> is much more expensive than a "process messages".
>>
> Of course the OS needs much more time to switch threads than process
> messages needs "program tasks". But the OS does not need to do polling.
> Threads are only switched when needed while process messages needs to be
> called very frequently for a decent latency and nearly all calls are in
> vain.
>
>
>>  how do you make a program doing huge calculations use multiple CPUs
>>> which are the contrary of "of the past" ?
>>>
>>
>> I didn't claim to have a better solution. I just observed that the
>> very idea of threads is basically flawed.
>>
> That is why I started my answer with "OK" .)


Gilad Ben Yosef gave a lecture about Process vs Threads last year :
http://free-electrons.com/pub/video/2009/elce/elce2009-ben-yossef-threads-processes.ogv
<http://free-electrons.com/pub/video/2009/elce/elce2009-ben-yossef-threads-processes.ogv%20>

I recommend to watch it.


>
>
>> These are not my words, but the conclusion of scientific research on
>> the subject.
>>
> There are several decent scientific research papers that bash threads.
> ("Migrating away from threads has been mentioned here recently for it's neat
> practical usefulness.)
>
> My impression is that regarding the OS-interface of a program that needs
> the said features (multiple "logical threads", performance, latency, making
> use of modern SMP systems, ...), threads are a necessity. But programming
> languages might be able to in many cases hide the dirty details from the
> programmer (e.g. "parallel" loops, see the Delphi Prism and/or .NET
> documentation on these issues.) If FPC could be enhances tn that direction
> it might be a decent improvement.
>
> -Michael
>
>
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20100915/7cd0abd1/attachment-0004.html>