[fpc-devel] C++ gets language-internal concurrency support

[David W Noon]

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.noon at ntlworld.com (David W Noon)
=======================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110819/15f3385b/attachment.sig>