Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!husc6!harvard!spdcc!dyer
From: d...@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: XENIX 386 benchmark results
Message-ID: <127@spdcc.COM>
Date: Tue, 30-Jun-87 04:40:02 EDT
Article-I.D.: spdcc.127
Posted: Tue Jun 30 04:40:02 1987
Date-Received: Sat, 4-Jul-87 22:40:35 EDT
Reply-To: d...@spdcc.COM (Steve Dyer)
Distribution: world
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 34
Now that I have results for XENIX 386 along with my earlier figures,
this is a final posting of benchmarks of the Intel Inboard 386/AT,
for both XENIX 286 running in 16-bit memory and 32-bit memory and
XENIX 386 running in 32-bit memory.
At least from the Dhrystone benchmarks reported below, we're well
into Sun 3 territory, if not beyond! Quite amazing...
---------------------------------------
All tests were run on the same hardware and software environment,
with the exception of the replacement of the 286 for the 386 card,
under SCO XENIX 286 OS v. 2.1.3 with Development System v. 2.1.4
or SCO XENIX 386 OS and Development System beta test with beta update (6/16/87).
IBM PC/AT 8mhz IBM PC/AT with Intel Inboard 386/AT
at 16mhz, cache enabled
XENIX 286 XENIX 286 XENIX 286 XENIX 386
16-bit mem 16-bit mem 32-bit mem 32-bit mem
Drystone 1.0 no reg reg no reg reg no reg reg no reg reg
1278 1292 2293 2304 3429 3405 5259 5719
Drystone 1.1 1084 1094 1957 1963 2906 2893 4603 4922
Buchholz (sum of user & sys times in sec)
short cpu 0.3 0.2 0.1 0.1
medium cpu 3.3 1.9 1.2 0.5
long cpu *** *** (values out of range) 2.6
short I/O 0.9 0.6 0.4 0.1
I/O bound 3.1 1.9 1.4 0.5
long mixed 56.9 33.8 21.8 8.9
--
Steve Dyer
d...@harvard.harvard.edu
d...@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!ulysses!mhuxt!m10ux!braun
From: br...@m10ux.UUCP
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: Re: XENIX 386 benchmark results
Message-ID: <225@m10ux.UUCP>
Date: Wed, 1-Jul-87 14:25:33 EDT
Article-I.D.: m10ux.225
Posted: Wed Jul 1 14:25:33 1987
Date-Received: Fri, 3-Jul-87 05:45:05 EDT
References: <127@spdcc.COM>
Organization: AT&T Bell Labs, Murray Hill
Lines: 17
Summary: What size are ints?
After seeing the various benchmarks for 80286, 80386, and 68020's,
I have been wondering: What sizes are the integers used by each machine?
I assume that a 80[012]86 is using 16 bit integers. I would also suspect
taht a 68020 is benchmarked with 32 bit ints, since that's what you get
from Sun and the other 68020 workstation makers.
What about the 80386? Are most of these benchmarks done running
the same binary on a '386 as used on the '286? If so,
what happens to the '386's speed when it runs with 32 bit integers?
By the way, what support does the '386 have for 32 bit arithmetic
and 32 bit addressing? Is it a new bunch of instructions, or
a different mode for the cpu?
--
Doug Braun AT+T Bell Labs, Murray Hill, NJ
m10ux!braun 201 582-7039
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!bu-cs!m2c!spdcc!dyer
From: d...@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: Re: XENIX 386 benchmark results
Message-ID: <139@spdcc.COM>
Date: Thu, 2-Jul-87 21:45:36 EDT
Article-I.D.: spdcc.139
Posted: Thu Jul 2 21:45:36 1987
Date-Received: Sat, 4-Jul-87 08:56:09 EDT
References: <127@spdcc.COM> <225@m10ux.UUCP>
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 41
In article <2...@m10ux.UUCP>, br...@m10ux.UUCP writes:
> After seeing the various benchmarks for 80286, 80386, and 68020's,
> I have been wondering: What sizes are the integers used by each machine?
> I assume that a 80[012]86 is using 16 bit integers. I would also suspect
> taht a 68020 is benchmarked with 32 bit ints, since that's what you get
> from Sun and the other 68020 workstation makers. What about the 80386?
> Are most of these benchmarks done running the same binary on a '386 as
> used on the '286? If so, what happens to the '386's speed when it runs
> with 32 bit integers?
At least for "dhrystone", all integers are declared as "int", meaning that
the compiler chooses the natural size for its target architecture.
For XENIX 286 cc, int == 16 bits and for XENIX 386 cc, int == 32 bits.
Maybe my report wasn't clear enough (I thought it was), but I reported
results for both 286 objects and 386 objects running on the Intel 386
as well as baseline results for the 286 objects running on an 8mhz 286.
> By the way, what support does the '386 have for 32 bit arithmetic
> and 32 bit addressing? Is it a new bunch of instructions, or
> a different mode for the cpu?
This is interesting. First, both the 286 and 386 execute the same instructions
(the 386 has some extensions and new addressing modes, but this is generally
a true statement) but on the 386, the operand size can vary. The 386's
registers are analogous to the 8086, but the "general registers" (if they
can be called that) are potentially 32 bits wide. In real mode (and virtual-86
mode) the operand and address sizes are 16 bits by default, just like an 8086
or 286. In protected mode, the address and operand sizes are determined by the
D-bit in the segment descriptor for the code currently executing. If D==0,
then 16-bit addressing and operands are the default; if D==1, then all
addresses and operands are taken to be 32 bits wide. There are two opcode
prefixes which invert the current sizes of addresses and operands for that
instruction. These prefixes are most useful in a real mode DOS environment
to force 32-bit operations. They're generally unnecessary in a protected mode
environment, since the OS sets your code segment selector appropriately.
I could imagine some hacks to get 16-bit behavior in a 32-bit environment,
but they'd be certainly unusual.
--
Steve Dyer
d...@harvard.harvard.edu
d...@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!sri-unix!sri-spam!mordor!lll-tis!ptsfa!ihnp4!alberta!ubc-vision!fornax!bby-bc!john
From: j...@bby-bc.UUCP (john)
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: Re: XENIX 386 benchmark results
Message-ID: <130@bby-bc.UUCP>
Date: Fri, 3-Jul-87 14:00:18 EDT
Article-I.D.: bby-bc.130
Posted: Fri Jul 3 14:00:18 1987
Date-Received: Sat, 4-Jul-87 15:30:37 EDT
References: <127@spdcc.COM> <225@m10ux.UUCP> <139@spdcc.COM>
Organization: Burnaby, British Columbia, Canada
Lines: 19
> then 16-bit addressing and operands are the default; if D==1, then all
> addresses and operands are taken to be 32 bits wide. There are two opcode
> prefixes which invert the current sizes of addresses and operands for that
> instruction. These prefixes are most useful in a real mode DOS environment
> to force 32-bit operations. They're generally unnecessary in a protected mode
> environment, since the OS sets your code segment selector appropriately.
> I could imagine some hacks to get 16-bit behavior in a 32-bit environment,
> but they'd be certainly unusual.
So if you want to do 16 and 32 bit arithmetic in the same procedure all the
instructions with operands of one of the sizes has to be prefixed? Do any
of the existing compilers do this?
Are there instuctions for 16->32 and vice versa conversions along the
lines of CBW?
Assuming 32 bit wide memory is there any unusual speed penalties for
particular instuctions with 16/32 bit operands, e.g. are shifts faster
with one particualr size?
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!oliveb!intelca!mipos3!kds
From: k...@mipos3.UUCP
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: Re: XENIX 386 benchmark results
Message-ID: <826@mipos3.UUCP>
Date: Wed, 8-Jul-87 16:34:29 EDT
Article-I.D.: mipos3.826
Posted: Wed Jul 8 16:34:29 1987
Date-Received: Sat, 11-Jul-87 16:20:41 EDT
References: <127@spdcc.COM> <225@m10ux.UUCP> <139@spdcc.COM> <130@bby-bc.UUCP>
Reply-To: k...@mipos3.UUCP (Ken Shoemaker ~)
Organization: Intel, Santa Clara, CA
Lines: 31
In article <1...@bby-bc.UUCP> j...@bby-bc.UUCP (john) writes:
>So if you want to do 16 and 32 bit arithmetic in the same procedure all the
>instructions with operands of one of the sizes has to be prefixed?
yes...
>
>Are there instuctions for 16->32 and vice versa conversions along the
>lines of CBW?
yes, both sign extend and zero extend are provided
>Assuming 32 bit wide memory is there any unusual speed penalties for
>particular instuctions with 16/32 bit operands, e.g. are shifts faster
>with one particualr size?
nope, the rate of instruction execution shouldn't change. Of course, it takes
a clock to crack a prefix, so if you have lots of them, performance could
suffer. My guess as to why 32-bit code seems to run so much faster than 16-bit
code on the 386 has to do with the differences in the programming model between
16-bit and 32-bit code: 32-bit code is always "small" mode (i.e., no segment
register reloads), can do 32-bit arithmetic operations in a single instruction,
and register usage is more general in 32-bit code.
--
The above views are personal.
...and they whisper and they chatter, but it really doesn't matter.
Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California
uucp: ...{hplabs|decwrl|amdcad|qantel|pur-ee|scgvaxd|oliveb}!intelca!mipos3!kds
csnet/arpanet: k...@mipos3.intel.com
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!hoptoad!gnu
From: g...@hoptoad.uucp (John Gilmore)
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: Re: XENIX 386 benchmark results
Message-ID: <2413@hoptoad.uucp>
Date: Mon, 13-Jul-87 08:04:52 EDT
Article-I.D.: hoptoad.2413
Posted: Mon Jul 13 08:04:52 1987
Date-Received: Tue, 14-Jul-87 02:43:53 EDT
References: <127@spdcc.COM> <225@m10ux.UUCP> <139@spdcc.COM> <130@bby-bc.UUCP> <826@mipos3.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 24
k...@mipos3.UUCP (Ken Shoemaker) wrote:
> My guess as to why 32-bit code seems to run so much faster than 16-bit
>code on the 386 has to do with the differences in the programming model between
>16-bit and 32-bit code: 32-bit code is always "small" mode (i.e., no segment
>register reloads), ...
> --
> The above views are personal.
I construe this as a "personal" statement by an Intel chip designer
that the whole concept of memory models and segment registers is wrong
-- not only did it make life hell for programmers [who bought Intel
machines], but he points out that the generated code using those models
is much slower, even on their whizziest new chip.
The statement that 32-bit code is always "small mode" belies the
waffling in the 386 architecture manuals that extolls the virtues of
segment registers even in a 32-bit address space. They should have
been honest enough to describe them as a hack for 8086 compatability,
useless in other modes.
Welcome to reality, Intel! Glad to have you with us. And thanks for fixing it.
--
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu g...@postgres.berkeley.edu
Alt.all: the alternative radio of the Usenet.