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


Groups > comp.programming.threads > #1509

Re: Thread scaling in Windows

Date 2013-06-01 15:20 +0200
From Marcel Müller <news.5.maazl@spamgourmet.org>
Newsgroups comp.programming.threads
Subject Re: Thread scaling in Windows
References (2 earlier) <XnsA1D1132254871myfirstnameosapriee@216.196.109.131> <51a8ab52$0$6567$9b4e6d93@newsspool4.arcor-online.net> <XnsA1D1D5409B3C5myfirstnameosapriee@216.196.109.131> <51a90f46$0$6626$9b4e6d93@newsspool2.arcor-online.net> <XnsA1D271047667Amyfirstnameosapriee@216.196.109.131>
Message-ID <51a9f531$0$9502$9b4e6d93@newsspool1.arcor-online.net> (permalink)
Organization Arcor

Show all headers | View raw


On 01.06.13 10.06, Paavo Helde wrote:
>> Yes, this is a bit funny. If boost maps to pthreads and the windows
>> implementation of boost uses emulated pthreads, than I would not
>> wonder anymore. Emulating pthreads with the Win32 API is somewhat
>> complicated at some places and may require time consuming work
>> arounds. I had similar fun when porting PulseAudio to the OS/2 API,
>> which is almost the same than Win32.
>
> The boost::mutex class we have seems to use compiler intrinsics and SDK
> functions like _interlockedbittestandset and _InterlockedExchangeAdd. At
> least for the uncontented case these were the only functions triggered.

Hmm...

> I already replaced the refcounter mutex lock by InterlockedIncrement and
> InterlockedDecrement SDK functions, but this appeared to make no
> difference. Makes sense, as the mutex locks are using similar atomic
> operations.

... I think you do not find the bottleneck so far. There must be 
something really important going wrong.


>> Another option is to create an interface from the single threaded one
>> to the shared smart pointer. The basic idea is that a proxy object
>> that adapts the single threaded pointers can be initialized from the
>> shared pointer. This proxy acquires a new reference from the shared
>> location. But further instances of single threaded pointers only
>> increment a local reference counter in the proxy rather than the
>> global, shared counter. Only if that shared object goes out of scope,
>> the global reference counter is accessed again. This keeps memory
>> access thread-local as far as possible.
>
> Yes, that seems like a good idea.

Before you spent too much time in optimizing things far away from the 
critical path I would recommend to investigate further in finding the 
source of the problem. I have the feeling that you are far away from 
real problem. It might be something that you did not think of so far.

What about the following test: if running on Win with 24 cores is really 
that slow, try to runing in the debugger without any breakpoints. Just 
run. And from time to time press stop and investigate the call stacks of 
all 24 threads. Doing this a few times should point you to close to the 
place where the threads get stucked quite frequently with reasonable 
probability.
Running a profiler might give better results. But this is much more work.


Marcel

Back to comp.programming.threads | Previous | NextPrevious 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