Re: [fpc-pascal] Optimal number of threads for SMP
On 09/15/2014 11:19 AM, Marco van de Voort wrote: too many threads increasing switching time and thus decreases performance Not only this. Additionally Linux tries to keep a thread/Task at the same CPU when re-scheduling the CPUs. By this the count of misses on the (primary) caches is decreased. AFAIK, cache misses can result in a huge degradation. Hence - depending on the task to be done - using more threads than CPUs might not be a good idea. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimal number of threads for SMP
On 09/18/2014 06:53 PM, Bernd wrote: If it reports 4 CPUs then you have exactly 4 CPUs. Correct from a algorithm POV, but not from a performance POV. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] PostMessage vs. QueueAsyncCall
Hi, In a previous email asking about PostMessage, Michael suggested I used QueueAsyncCall instead, because although it's OK to use PostMessage, but it is considered a Windows Legacy, or only for Delphi compatibility. However, in actual use, I feel that PostMessage does a better job for code separation. Because when use PostMessage, GUI (or main thread) related code are written in the main form, and the thread will not need to use the Forms unit. My question is, why cannot Lazarus just use PostMessage, but invent the QueueAsyncCall() method? What is the rationale, or, why PostMessage is considered windows-ish (read: not fit into LCL very well?), apart from the fact that it is a Windows API? Thanks, Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PostMessage vs. QueueAsyncCall
On 09/19/2014 11:20 AM, Xiangrong Fang wrote: Hi, In a previous email asking about PostMessage, Michael suggested I used QueueAsyncCall instead, In fact now that I know what you are trying to accomplish (a Thread Pool) I take back the suggestion of QueueAsyncCall, as same is supported by Lazarus (LCL) and not directly by fpc (RTL). As I feel that a ThreadPool should be working independently of the GUI, I would use TThread.Synchronize or TThread.Queue. In fact I did a TThreadPool component that works nicely for me. This is discussed in the Lazarus Forum (even though I think it should better be discussed here, as it does not use any Lazarus features. My question is, why cannot Lazarus just use PostMessage, but invent the QueueAsyncCall() method? Windows is a Message driven OS. This might be nice but other OSes don't support or force this paradigm. As fpc is supposed to be as portable as possible, it can't work Message driven under the hood, which is not supported by other OSes. To support Code ported from Delphi, PostMessage is provided by Lazarus in the LCL (but AFAIK, not by fpc, which can be used without Lazarus / LCL) -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PostMessage vs. QueueAsyncCall
On Fri, 19 Sep 2014 17:20:27 +0800 Xiangrong Fang xrf...@gmail.com wrote: [...] My question is, why cannot Lazarus just use PostMessage, but invent the QueueAsyncCall() method? What is the rationale, or, why PostMessage is considered windows-ish (read: not fit into LCL very well?), apart from the fact that it is a Windows API? Please ask Lazarus question on the Lazarus lists. PostMessage is a WinAPI function that sends an uint, and two pointer sized integers to a Windows Handle with a queue, even to another process. See here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644944%28v=vs.85%29.aspx The LCL emulates some parts of PostMessage on other widget sets. TApplication.QueueAsyncCall on the other side allows to call a method in the main thread with an optional data pointer. And the call can be removed from the queue. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
