Date: Wed, 26 Mar 2003 04:23:21 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Marc Olzheim <marcolz@stack.nl> Cc: Julian Elischer <julian@elischer.org> Subject: Re: 1:1 Threading implementation. Message-ID: <20030326042114.H64602-100000@mail.chesapeake.net> In-Reply-To: <20030326091826.GA79113@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Mar 2003, Marc Olzheim wrote: > On Wed, Mar 26, 2003 at 03:36:57AM -0500, Jeff Roberson wrote: > > First, if your application has more threads than cpus it is written > > incorrectly. For people who are doing thread pools instead of event > > driven IO models they will encounter the same overhead with M:N as 1:1. > > I'm not sure what applications are entirely compute and have more threads > > than cpus. These are the only ones which really theoretically benefit. I > > don't think our threading model should be designed to optimize poorly > > thought out applications. > > Might I suggest that there are 'nice' C++ ways of using thread-classes > where both the usual C++ dogmas of readability and reuseability make you > easily end up with more threads than cpus... > I think that from a userland's point of view, most programmers shouldn't > be caring less about how many cpus the machine has their core is running > on. Sure, but in these cases you're not likely to be using them in performance critical code. Which means you're not likely to be using all of the cpu.. Which means you're going to have to go block in the kernel anyway. And so, really what we're talking about is wasted memory here. Not even many cpu cycles. I think people who actually care about performance don't want the M:N overhead. 1:1 will be faster for them. For the rest, well, they didn't care about performance and so why should we work so hard to make it marginally faster for them? > With this (not limited to) C++ model in mind, the M:N way would be a > great thing to have. > > Zlo >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030326042114.H64602-100000>