- std::thread...too little, too late? - 7 Updates
| woodbrian77@gmail.com: Dec 24 09:09PM -0800 On Wednesday, December 24, 2014 5:35:36 AM UTC-6, Martijn Lievaart wrote: > sense as the result is very scalable and is actually what is done in most > high performance solutions. > M4 I use async IO and multiple process instances to minimize the need for threads. I think this approach scales well. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Mr Flibble <flibble@i42.co.uk>: Dec 25 04:15PM >> M4 > I use async IO and multiple process instances to minimize the > need for threads. I think this approach scales well. Multiple processes do not scale well at all which is why pthreads was invented. /Flibble |
| "Öö Tiib" <ootiib@hot.ee>: Dec 25 11:57AM -0800 On Thursday, December 25, 2014 6:15:28 PM UTC+2, Mr Flibble wrote: > > need for threads. I think this approach scales well. > Multiple processes do not scale well at all which is why pthreads was > invented. That reads too generic claim to be believable. Sounds skewed. Do you have any links to papers to point at? If to reason: 1) The 'fork()' is optimized into quite cheap on lot of platforms by using lazy copying on process data (CoW of virtual memory pages). It is still more expensive than spawning a thread but nothing to lament about. 2) Multithreading does waste lot of time to synchronize access to shared data, processes do not share data. 3) Ending a process with the likes of 'std::quick_exit' is efficient form of freeing a portion of unneeded resources. You got to use some custom 'allocator' with lot of discipline (I haven't met) to achieve anything competitive with a thread. So there are no clear benefit that multithreading beats multiprocessing always. Multiprocessing is efficient solution for number of problems. |
| Melzzzzz <mel@zzzzz.com>: Dec 25 10:34PM +0100 On Thu, 25 Dec 2014 11:57:43 -0800 (PST) > using lazy copying on process data (CoW of virtual memory pages). > It is still more expensive than spawning a thread but nothing to > lament about. Main reason for using threads is startup time. Other reason is that not all systems overcommit memory. > 2) Multithreading does waste lot of time to synchronize access > to shared data, processes do not share data. Second main reason to use threads is simpler IPC. > form of freeing a portion of unneeded resources. You got to use > some custom 'allocator' with lot of discipline (I haven't met) > to achieve anything competitive with a thread. If there are no memory leaks I can't see why is this problem with threads? In C++, just throwing exception is usually enough to exit from thread... > So there are no clear benefit that multithreading beats > multiprocessing always. Multiprocessing is efficient solution > for number of problems. Only thing that is bad for threads and goes in favor of processes is memory fragmentation and therefore steady growth of memory usage. All long running threaded programs have that problem. |
| Mr Flibble <flibble@i42.co.uk>: Dec 25 09:53PM On 25/12/2014 19:57, Öö Tiib wrote: > using lazy copying on process data (CoW of virtual memory pages). > It is still more expensive than spawning a thread but nothing to > lament about. Most forked child processes will use most of their memory as the parent process usually doesn't do much and the child process typically calls exec rendering your point invalid. My assertion remains intact: processes do not scale well, threads do. /Flibble |
| "Chris M. Thomasson" <no@spam.invalid>: Dec 25 02:58PM -0800 > "Melzzzzz" wrote in message news:20141225223439.505a880d@maxa-pc... [...] > Only thing that is bad for threads and goes in favor of processes > is memory fragmentation and therefore steady growth of memory usage. All > long running threaded programs have that problem. Are you perhaps referring to memory allocators? In my experience, carefully written, long-running multi-threaded systems (e.e.g, a server), do not suffer from this. Can you perhaps be more precise? I have a little problem with the word "All" in your statement. Sorry... :^o |
| Melzzzzz <mel@zzzzz.com>: Dec 26 12:10AM +0100 On Thu, 25 Dec 2014 14:58:09 -0800 > server), do not suffer from this. Can you perhaps be more precise? I > have a little problem with the word "All" in your statement. > Sorry... :^o Ok, I generalized too much ;) But look for example gnome-shell process and firefox. They grow and grow ;) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment