Re: Ideas for a Object-Belongs-to-Thread threading model (nntp: message 9 of 20)
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. If you don't use threads, the presence of the ability to use them if you need to will not affect you at all. The presence of Unicode support will have a far more measurable affect upon performance. And it will be unavoidable. 2: Complexity. The perception that the presence of threading support will complicate non-threaded apps. Again, the presence of Unicode support adds far more complexity to the mix that that for threading. But with either, if you choose not to use it, you shouldn't even be aware of its presence. Do you believe that Unicode support should be dropped? See also http://www.ibm.com/developerworks/linux/library/l-posix1.html and fathom why Threads are fun reads to me like how a drug dealer lures you to at least try it once. To me, that reads far more like some of the advocacy I've seen for Giving Blood. If your squeamish, get a friend to distract you, or listen to some good music whilst they put the needle in. Rather fork-join! For platforms where fork is native, it doesn't go away just because threads support is present. (Do Perl_6 hyper-operators need pthreads?) Buk.
Re: Ideas for a Object-Belongs-to-Thread threading model (nntp: message 9 of 20)
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. And spawning 1000 (do nothing but sleep) threads takes 0.171 seconds? Buk.
Re: Ideas for a Object-Belongs-to-Thread threading model (nntp: message 9 of 20)
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
Re: Ideas for a Object-Belongs-to-Thread threading model (nntp: message 9 of 20)
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)... If you don't use threads, the presence of the ability to use them if you need to will not affect you at all. The presence of Unicode support will have a far more measurable affect upon performance. And it will be unavoidable. 2: Complexity. The perception that the presence of threading support will complicate non-threaded apps. Again, the presence of Unicode support adds far more complexity to the mix that that for threading. But with either, if you choose not to use it, you shouldn't even be aware of its presence. Do you believe that Unicode support should be dropped? See also http://www.ibm.com/developerworks/linux/library/l-posix1.html and fathom why Threads are fun reads to me like how a drug dealer lures you to at least try it once. To me, that reads far more like some of the advocacy I've seen for Giving Blood. If your squeamish, get a friend to distract you, or listen to some good music whilst they put the needle in. Rather fork-join! For platforms where fork is native, it doesn't go away just because threads support is present. (Do Perl_6 hyper-operators need pthreads?) Buk. -- B. Estrade estr...@gmail.com
