Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!nsc!srm From: srm@nsc.UUCP (Richard Mateosian) Newsgroups: net.works,net.micro.16k Subject: Re: 32032 UNIX Message-ID: <2347@nsc.UUCP> Date: Mon, 11-Feb-85 15:36:06 EST Article-I.D.: nsc.2347 Posted: Mon Feb 11 15:36:06 1985 Date-Received: Tue, 12-Feb-85 06:23:08 EST References: <357@topaz.ARPA> <320@terak.UUCP> <278@petrus.UUCP> <5040@utzoo.UUCP> Reply-To: srm@nsc.UUCP (Richard Mateosian) Organization: National Semiconductor, Sunnyvale Lines: 34 Xref: watmath net.works:906 net.micro.16k:198 Summary: In article <5040@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Another relevant question is, does your memory have zero wait states? >People I trust tell me that the 32016's performance deteriorates >*SHARPLY* when wait states are introduced -- it's much worse than >you would expect, and in particular it's not linear in the number of >wait states. Obviously, behavior under wait states depends a lot on particular programs. Here is one data point taken from one of my Wescon papers. The program is a small benchmark that uses memory heavily. Bus use is 82% on the NS32016, 57% on the NS32032, both at 0 wait states. Given below are execution times in seconds at 0, 1 and 2 wait states: 0 ws 1 ws 2 ws ---- ---- ---- NS32032 32.7 36.0 39.3 NS32016 43.7 49.4 55.0 Ratio 1.34 1.37 1.4 Execution speed of the NS32016 is 88.5% at 1 ws, 79.5% at 2 ws. Execution speed of the NS32032 is 90.8% at 1 ws, 83.2% at 2 ws. In general, programs with lighter bus use show smaller degradation with wait states and smaller ratios of NS32032 to NS32016 execution speed. In fact, a program doing nothing but register to register divison operations might show no degradation at all under wait states (because of the instruction pipeline) and no difference in execution speed between the NS32016 and NS32032. -- Richard Mateosian {allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm nsc!srm@decwrl.ARPA