Date: Sun, 30 Mar 2003 12:47:34 -0800 From: Wes Peters <wes@softweyr.com> To: Jeff Roberson <jroberson@chesapeake.net>, Marc Olzheim <marcolz@stack.nl> Cc: arch@freebsd.org Subject: Re: 1:1 Threading implementation. Message-ID: <200303301247.34629.wes@softweyr.com> In-Reply-To: <20030326042114.H64602-100000@mail.chesapeake.net> References: <20030326042114.H64602-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 26 March 2003 01:23, Jeff Roberson wrote:
> 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?
If the gains are marginal it's probably not worth pursuing, especially not
up front. Make it work, then make it work right, then make it work
faster, right?
This does not mean your statement "if your application has more threads
than cpus it is written incorrectly" is correct. It is true only if
threads are being use to accelerate the application. On the contrary, it
is quite simple to postulate applications that are designed with threads
to accomplish discrete tasks that must run in parallel and which may or
may not compete with one another for resources (cpu, i/o, etc) depending
on the current task load.
--
Where am I, and what am I doing in this handbasket?
Wes Peters wes@softweyr.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303301247.34629.wes>