Xref: utzoo comp.arch:8660 comp.sys.intel:738
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 overview (long)
Message-ID: <24752@amdcad.AMD.COM>
Date: 8 Mar 89 03:45:05 GMT
References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 35
Summary:
Expires:
Sender:
Followup-To:

In article <13322@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
| One problem with any chip which requires alligned data is that
| performance suffers when addressing bytes, to the point that a program
| may become impractical.

Bytes don't have alignment restrictions -- they are already byte-aligned ;-)

Most new processors require data to be aligned on "natural" boundaries,
i.e. bytes on byte boundaries, half-words on 16-bit boundaries, words on
32-bit boundaries, etc.  This is simply to avoid having to read more
than 1 word of memory on a load (with the associated trap headaches) and
build up the requested data.

|  One of the people here checked his Sun-30
| (68020) against his Sun-4 (SPARC). The three ran troff about 5x faster.
| This doesn't mean RISC is bad in a workstation, but it can have
| performance problems in software we take for granted.

What was the dataset and the specific machine types?  On "normal"
looking input, I find:

Sun 3/160:
snap3 time troff -t 2.t > /dev/null
5.6u 0.1s 0:05 99% 0+184k 0+8io 0pf+0w

Sun 4/110:
crackle2 time troff -t 2.t > /dev/null
2.2u 0.1s 0:03 69% 0+408k 1+8io 0pf+0w

Which shows the 4/110 2.5x faster than the 3/160.


	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)