Xref: utzoo comp.arch:8808 comp.sys.intel:765
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!ames!xanth!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!hpda!hpwala!cfisun!ima!spdcc!merk!alliant!jeff
From: jeff@Alliant.COM (Jeff Collins)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 Multiprocessing
Message-ID: <3032@alliant.Alliant.COM>
Date: 14 Mar 89 15:56:49 GMT
References: <494@ircam.UUCP>
Reply-To: jeff@alliant.Alliant.COM (Jeff Collins)
Organization: Technology Partners, Inc.
Lines: 24

In article <494@ircam.UUCP> elind@ircam.ircam.fr (Eric Lindemann) writes:
>I'm interested here mainly in performance issues. Let's leave the issue
>of cache coherency, and the lack of i860 hardware support for it, out 
>of the discussion for the time being.

	The performance issues associated with bus timing will be interesting
to know, but the i860 performance in a multiprocessor will also be effected by
the cache coherency schemes that are employed.  If the part does not have
external bus watchers (I haven't heard this stated yet, only implied), then
it seems to be that the performance will be severely hampered.

	I may be missing something, but I have looked at a number of
microprocessors with an aim to putting them in a multiprocessor.  The
conclusion that I, and my hardware friends, came to was that if a
microprocessor has an internal cache and no external invalidate logic, then
the only way to use the part in a symmetric multiprocessor is to disable the
internal data cache.  Internal I-caches have the same problems when you start
to consider debuggers, but there are work arounds and performance isn't
critical in these cases.

	What really confuses me is all of the activity aimed at putting these
parts in a multiprocessor.  I admit that the part is amazingly fast, but is it
really an appropriate part for a multiprocessor - or even for a general
purpose processor? (I had to make some controversial statement :^)