Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1509
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar
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