Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pacbell!att!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.arch
Subject: Re: RISC bashing at USENIX (speed of graphics with SPARC)
Summary: Perhaps its the frame buffer's fault
Message-ID: <1747@vaxb.calgary.UUCP>
Date: 15 Jul 88 19:53:32 GMT
References: <6965@ico.ISC.COM> <936@garth.UUCP> <202@baka.stan.UUCP> <204@baka.stan.UUCP>
Distribution: na
Organization: U. of Calgary, Calgary, Ab.
Lines: 14

In article <204@baka.stan.UUCP>, landru@stan.UUCP (Mike Rosenlof) writes:

> ...In this isolated case, SPARC ( or at least this implementation
> by Fujitsu ) is not impressive, especially when comparing costs to a
> 68020 system.  This is one of the difficulties of very simple graphics
> like this, lots of data has to be moved around...

It's possible that we're all missing the point here. Could it be that
the time for simple graphics on both the 68020 system and the SPARC system
was dominated by the access time of the frame buffer? That no processor
of any speed could have speeded the graphics up?

Was the frame buffer the same in the two cases?

   Radford Neal