dyer@spdcc.COM (Steve Dyer) (06/21/87)
This is a reposting of benchmarks of the Intel Inboard 386/AT,
this time with new results on the speed of the board fully loaded
with 32-bit memory. Earlier results simply reported results using
16-bit memory on the AT bus. As you can see by the results below,
the difference is quite startling! Earlier results indicated a
ratio of 1.7/1 in average CPU speed -- with the 32-bit memory expansion,
this has increased to better than 2.6/1 compared with a stock 8mhz AT.
At least from the Dhrystone benchmarks reported below, we're beginning
to edge into Sun 3 territory...
---------------------------------------
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.
Note that this is a test of the execution speed of 286 16-bit instructions.
The Inboard used in this test has no memory of its own other than its cache.
IBM PC/AT 8mhz IBM PC/AT with Intel Inboard 386/AT
at 16mhz, cache enabled
16-bit mem 32-bit mem
Drystone 1.0 no reg reg no reg reg no reg reg
1278 1292 2293 2304 3429 3405
Drystone 1.1 1084 1094 1957 1963 2906 2893
Buchholz (sum of user & sys times in sec)
short cpu 0.3 0.2 0.1
medium cpu 3.3 1.9 1.2
long cpu *** *** (values out of range)
short I/O 0.9 0.6 0.4
I/O bound 3.1 1.9 1.4
long mixed 56.9 33.8 21.8
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyerm5@bobkat.UUCP (Mike McNally ) (06/24/87)
In article <122@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: > IBM PC/AT 8mhz IBM PC/AT with Intel Inboard 386/AT > at 16mhz, cache enabled > > 16-bit mem 32-bit mem > >Drystone 1.0 no reg reg no reg reg no reg reg > 1278 1292 2293 2304 3429 3405 >Drystone 1.1 1084 1094 1957 1963 2906 2893 Why is the with-register-variables time for the 32-bit version *slower* than the without-register-variables time? Isn't that sort-of strange? -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
ralf@b.gp.cs.cmu.edu (Ralf Brown) (06/29/87)
In article <1176@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally (Man from Mars)) writes: >In article <122@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: > > IBM PC/AT 8mhz IBM PC/AT with Intel Inboard 386/AT > > 16-bit mem 32-bit mem > >Drystone 1.0 no reg reg no reg reg no reg reg > > 1278 1292 2293 2304 3429 3405 > >Drystone 1.1 1084 1094 1957 1963 2906 2893 > >Why is the with-register-variables time for the 32-bit version *slower* >than the without-register-variables time? Isn't that sort-of strange? >-- >Mike McNally, mercifully employed at Digital Lynx --- No, its not strange when you consider that Dhrystone is not register- intensive. Saving the registers used for register variables on entry to a procedure and restoring them at exit takes time (PUSH/POP). If the register variable is not referenced often enough that the reduced access time to the variable makes up for the overhead of pushing and popping the register. The time savings for access to a register variable may be as little as three or four clock cycles (depending on wait states), while pushing and popping take 8 to 10 clocks (again, dep on wait states). Thus, if the register variable is accessed less than four times, you have a net increase in execution time. BTW, Turbo C with all optimizations on shows the same effect on an AT when running Dhrystone. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ARPA: RALF@B.GP.CS.CMU.EDU USnail: Ralf Brown AT&T: (412) 268-3053 (school) Computer Science Department Carnegie-Mellon University DISCLAIMER? Who ever said I claimed anything? Pittsburgh, PA 15213 "I do not fear computers. I fear the lack of them..." -- Isaac Asimov
dyer@athena.mit.edu (Steve Dyer) (06/30/87)
>Why is the with-register-variables time for the 32-bit version *slower* >than the without-register-variables time? Isn't that sort-of strange? Sure is, but that's what I got. I'm not sure why; perhaps it has to do with alignment of the variables (note that the results came from the SAME objects--the only difference was whether the 286 program was running in 16-bit memory or 32-bit memory). I'll be posting XENIX 386 results in a day or two; stay tuned... Steve Dyer dyer@harvard.HARVARD.EDU dyer@spdcc.COM aka {harvard,wanginst,ima,ihnp4,bbn,halleys}!spdcc!dyer
rick@pcrat.UUCP (Rick Richardson) (07/07/87)
In article <52@b.gp.cs.cmu.edu>, ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: > In article <1176@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally (Man from Mars)) writes: > >Why is the with-register-variables time for the 32-bit version *slower* > >than the without-register-variables time? Isn't that sort-of strange? > No, its not strange when you consider that Dhrystone is not register- > intensive. > The time savings for access to a register variable may be > as little as three or four clock cycles (depending on wait states), while > pushing and popping take 8 to 10 clocks (again, dep on wait states). Thus, > if the register variable is accessed less than four times, you have a net > increase in execution time. This is all highly compiler/processor dependant, of course. The original published Dhrystone was in Ada, and when I did the translation, I added the register decl's. Naturally, they are (were) optimized for the compiler/processor I was using at the time: an 8088 running Venix 2.0. I'm embarrassed to say that the choices I made and implementation I used were not far-sighted enough to avoid anamolies such as the above. Luckily, compilers are getting smart enough in reg allocation to cover my mistakes! not very -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) seismo!uunet!pcrat!ri<26
jschafer@csd4.milw.wisc.edu (Jack C Schafer) (07/22/87)
I'm looking for a civil engineering software package. This package must deal with conective geometry. The software should be designed to deal with surveyor information, close loops, and(or) do spirals. I am also looking for road project management packages. Any information would be appreciated. Thanks Jack
brian@asci.UUCP (Brian Douglass) (07/24/87)
In article <2530@uwmcsd1.UUCP> jschafer@csd4.milw.wisc.edu.UUCP (Jack C Schafer) writes: > > I'm looking for a civil engineering software package. This >package must deal with conective geometry. The software should be designed >to deal with surveyor information, close loops, and(or) do spirals. I am >also looking for road project management packages. > Any information would be appreciated. > Try the Army Corps of Engineers. They have all kinds of software for Civil Engineering, Hydrology, and sorts of other type of Construction Engineering. In particular most of it comes out of some place like Vicksburg Missippi, I think, I don't remember. Whether it is for sale or not, I don't know, but it may be public domain because it was developed for or by the Government, and therefore might be available under the Freedom of Information Act, but I'm just guessing. Brian Douglass Applied Systems Consultants, Inc. (ASCI) P.O. Box 13301 Las Vegas, NV 89103 Office: (702) 733-6761 Home: (702) 871-8182 brian@asci.uucp UUCP: {akgua,ihnp4,mirror,psivax,sdcrdcf}!otto!jimi!asci!brian "I speak only for myself as writer first, systems analyst second, and whatever the hell else I am third" Me