On Fri, May 14, 2010 at 06:03:46PM +0100, nigelsande...@btconnect.com wrote: > On Fri, 14 May 2010 15:05:44 +0100, B. Estrade <estr...@gmail.com> wrote: > > >On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com > >wrote: > >>On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - > >>rv...@isolution.nl > >><+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote: > >> > >> > >>> > >>>The support of threading should be completely optional. The threading > >>>support should not be active by default. > >> > >>I'd like to understand why you say that? > >> > >>Two reasons I can think of: > >> > >>1: Performance. The perception that adding support for threading will > >>impact the performance of non-threaded applications. > > > >I think that perhaps he's thinking of overhead associated with > >spawning and managing threads - even just one...so, if only 1 thread > >bound to a single core is desired, then I think this is a reasonable > >and natural thing to want. Maybe the core binding on an SMP box would > >be the more challenging issue to tackle. Then, again, this is the role > >of the OS and libnuma (on Linux, anyway)... > > > > Hm. Every process gets one thread by default. There is no overhead there.
I am not sure I undestand the context under which one process gets 1 thread. > > And spawning 1000 (do nothing but sleep) threads takes 0.171 seconds? Assuming this is a latency cost per 1000 threads, this could substantially impact an application. The goal is always to minimize overhead, so this is where I am coming from. And there's overhead not just form spawning, but from anything that requires some number of threads be synchronized - barriers, critical sections, atomic updates to memory, etc. And depending on the consistency model one enforces, there could also be implicit calls for each thread to flush out its cache in order to ensure the most up to date version of a shared object is seen by all. So if one is running a single process only, I think is reasonable to be concerned that it not be subject to this overhead unnecessarily. An additional concern related to not just overhead, would be data locality issues - you don't want your *single process migrating do difference cores where it's data would have to follow. The OS needs to know it is a distinct process and not to be regarded also as a thread (I would think..) Brett > > Buk. -- B. Estrade <estr...@gmail.com>
