Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!jqj
From: jqj@cornell.UUCP (J Q Johnson)
Newsgroups: net.arch
Subject: Re: Re: I don't believe your statements about multiprocessors
Message-ID: <1775@cornell.UUCP>
Date: Thu, 16-May-85 06:38:28 EDT
Article-I.D.: cornell.1775
Posted: Thu May 16 06:38:28 1985
Date-Received: Fri, 17-May-85 01:16:38 EDT
References: <7202@Glacier.UUCP> <36900002@ima.UUCP> <579@lll-crg.ARPA>
Reply-To: jqj@cornell.UUCP (J Q Johnson)
Organization: Cornell Univ. CS Dept.
Lines: 11

I guess I believe that, at least in principal, a multiprocessor could
be preferable to an equivalent uniprocessor (= same aggregate througput,
same total cache, etc.).  The argument is that both multiprocessor and
uniprocessor suffer scheduler overhead, but that in some cases the
overhead on a multiprocessor will be less.  A trivial example is a
uniprocessor versus an n-fold multiprocessor running n completely 
independent tasks; presumably the scheduler overhead in that case will be
linear in the length of the task for the uniprocessor, but sublinear
(perhaps even a constant) for the multiprocessor (assumption here is
that scheduler only gets invoked when someone isn't currently running
but wants to be).