Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #1502

Re: Thread scaling in Windows

Show all headers | View raw

On Thu, 30 May 2013 17:52:51 -0500, Paavo Helde
<myfirstname@osa.pri.ee> wrote:

>Marcel Müller <news.5.maazl@spamgourmet.org> wrote in news:51a7c499$0
>$6565$9b4e6d93@newsspool4.arcor-online.net:
>
>> On 29.05.13 19.31, Paavo Helde wrote:
>>> We have a portable C++ app using Boost mutexes and doing some memory 
>and
>>> cpu intensive calculations. The problem is it seems to scale much 
>better
>>> in Linux than in Windows.
>> 
>> Either the different boost mutex implementation is the key or you are 
>> doing a job in the mutex, that is synchronized on Windows but not on 
>> Linux, like File I/O including close.
>
>I/O is likely not the culprit here, there is relatively little of it, 
>just reading the source data into memory. 
>
>> Most likely you enter the mutexes very often during calculation. This 
>is 
>> bad practice. If you want to run in parallel, then run in parallel and 
>> do not talk to each other over an over.
>
>Mutexes are indeed entered quite often, but most of the cases there 
>should be no contention and the mutex is locked for a very short time, 
>like updating a shared object reference count by a smartpointer. I have 
>understood that mutex lock is next to harmless if there is no contention, 
>does this change in multicore? NUMA?


Acquiring an uncontended mutex is often still quite slow, as it
requires the locking CPU to acquire exclusive access to the relevant
cache line (which is at the time likely owned by a different CPU,
namely the prior one to obtain the lock).


>In the VTune Amplifier I see many "Synchronization context switches" 
>(about 1000 per second, 10 times more than "Preemption context 
>switches"). Are these caused by mutex lockings? Are these numbers too 
>large?
>
>It also tells me that the CPI rate (cycles per instruction retired) is 
>too high (1.691, ideal would be something like 0.25) and lists memory 
>stalls as the first possible cause.
>
>> 
>> Logging code can be the source of the problem as well as progress 
>> indicators that badly designed and updated too often as well as tasks 
>> that are too small.
>
>Minimal logging level, no GUI, no progress indicators. Tasks are very 
>large (maybe this causes problems instead?).
>
>> 
>> Another bottleneck might be I/O. If your jobs are I/O bound on the 
>> Windows machine, because the storage subsystem has not that high 
>> performance, you may run into the same problem.
>
>Sure, but in our case the jobs are definitely not I/O bound, rather 
>memory-bound. Everything is in memory (and there is plenty of it, only 
>some GB-s of the 32 GB total are used).


Memory management can be an area of quite high lock contention,
particularly in C++ code with many "new"s being executed.  Plugging
something like SmartHeap into your application is a simple fix if
that's a problem.

I'm not sure what boost::mutex is doing internally these days, but I
think they're doing their own lock-free structure plus a Windows event
object.  If they're not sharing that event object between mutexes, and
you're creating these mutex objects at a rapid rate, you could have
quite high overhead from the creating of the event objects.

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-29 12:31 -0500
  Re: Thread scaling in Windows Robert Miles <robertmilesxyz@gmail.com> - 2013-05-29 17:26 -0700
    Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-30 16:11 -0500
      Re: Thread scaling in Windows Gerald Breuer <Gerald.Breuer@googlemail.com> - 2013-05-31 03:44 +0200
        Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-31 00:29 -0500
  Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-05-30 23:28 +0200
    Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-30 17:52 -0500
      Re: Thread scaling in Windows Melzzzzz <mel@zzzzz.com> - 2013-05-31 04:18 +0200
      Re: Thread scaling in Windows Robert Wessel <robertwessel2@yahoo.com> - 2013-05-31 01:11 -0500
        Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-01 12:15 -0500
          Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-01 16:52 -0500
            Re: Thread scaling in Windows [SOLVED] Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-03 12:00 -0500
              Re: Thread scaling in Windows [SOLVED] Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-06-04 08:16 +0000
              Re: Thread scaling in Windows [SOLVED] Noob <root@127.0.0.1> - 2013-06-04 10:25 +0200
      Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-05-31 15:53 +0200
        Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-05-31 12:57 -0500
          Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-05-31 22:59 +0200
            Re: Thread scaling in Windows Paavo Helde <myfirstname@osa.pri.ee> - 2013-06-01 03:06 -0500
              Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-06-01 15:20 +0200
                Re: Thread scaling in Windows Drazen Kacar <dave@fly.srk.fer.hr> - 2013-06-02 06:35 +0000
            Re: Thread scaling in Windows Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-06-01 12:34 +0000
              Re: Thread scaling in Windows Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-06-01 15:09 +0200
                Re: Thread scaling in Windows Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-06-01 17:12 +0000

csiph-web