<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Sep 15, 2010 at 13:56, Michael Schnell <span dir="ltr"><<a href="mailto:mschnell@lumino.de">mschnell@lumino.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im"> On 09/15/2010 12:46 PM, Michael Van Canneyt wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
What is so performance killing about process messages ?<br>
</blockquote></div>
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<div class="im">

<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
What do you think the OS does when switching threads ? A thread switch<br>
is much more expensive than a "process messages".<br>
</blockquote></div>
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.<div class="im">

<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
how do you make a program doing huge calculations use multiple CPUs<br>
which are the contrary of "of the past" ?<br>
</blockquote>
<br>
I didn't claim to have a better solution. I just observed that the<br>
very idea of threads is basically flawed.<br>
</blockquote></div>
That is why I started my answer with "OK" .)</blockquote><div><br>Gilad Ben Yosef gave a lecture about Process vs Threads last year : <a href="http://free-electrons.com/pub/video/2009/elce/elce2009-ben-yossef-threads-processes.ogv%20">http://free-electrons.com/pub/video/2009/elce/elce2009-ben-yossef-threads-processes.ogv </a><br>

<br>I recommend to watch it.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
These are not my words, but the conclusion of scientific research on<br>
the subject.<br>
</blockquote></div>
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.)<br>
<br>
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.<br>

<font color="#888888">
<br>
-Michael</font><div><div></div><div class="h5"><br>
<br>
--<br>
_______________________________________________<br>
Lazarus mailing list<br>
<a href="mailto:Lazarus@lists.lazarus.freepascal.org" target="_blank">Lazarus@lists.lazarus.freepascal.org</a><br>
<a href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus" target="_blank">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a><br>
</div></div></blockquote></div><br></div>