On Fri, 19 Aug 2011 12:30:43 +0200, Michael Schnell wrote about Re: [fpc-devel] C++ gets language-internal concurrency support:
>On 08/17/2011 06:49 PM, David W Noon wrote: >> Perhaps the slower execution speed of CIL (.NET, >> Mono) byte code masks the context switching overheads and makes this >> practice look less inefficient. > >I doubt that this is the case. AFAIK, CIL code is not necessarily much >slower than native code. (Of course it can be much slower, especially >when garbage collection is necessary.) That is not my experience. While CIL byte code interprets much faster than Java byte code, it is still discernibly slower than native object code. [Or perhaps my C# is not that good.] >But when using a parallel loop "decently" i.e. for doing not too short >unrelated calculations with only so many parallel threads as >processors are available, this is supposed to grant a good speedup. My experience with OpenMP is that it is difficult to write a loop body large enough that context switching does not overwhelm the benefits of parallelism. >AFAIK with prism the parallel loop automatically is broken into as >many parallel threads as available processors, thus avoiding >additional context switches. Threads are not tied to processors. This is especially true in "managed" languages, where threads usually have process scope and consequently all run on the same CPU. [I.e. a thread with process scope cannot have CPU affinity distinct from that of the main thread in the process, whereas a thread with system scope can run wherever the operating system's CPU dispatcher sends it, possibly constrained by that thread's own CPU affinity mask.] The reason the "managed" languages typically use process scoped threads is that the threads are dispatched by the language's thread manager, not the operating system. This gives the thread manager total control over the threads, but it does mean that each thread is simply "called" in its turn and so runs on the same CPU as the thread manager; any request that would block the thread forces a return to the thread manager, which gives another thread a run, etc. I might do some experiments in C# to see if the thread manager creates threads with process scope or system scope, as it might be a bit smarter than Java's "green threads". -- Regards, Dave [RLU #314465] ======================================================================= david.w.n...@ntlworld.com (David W Noon) =======================================================================
signature.asc
Description: PGP signature
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
