Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.arch Subject: Re: Am29000 and MIPS Message-ID: <218@winchester.mips.UUCP> Date: Sat, 21-Mar-87 18:32:35 EST Article-I.D.: winchest.218 Posted: Sat Mar 21 18:32:35 1987 Date-Received: Sun, 22-Mar-87 17:43:10 EST References: <15192@amdcad.UUCP> <1423@husc6.UUCP> <15243@sun.uucp> <15217@amdcad.UUCP> <17915@ucbvax.BERKELEY.EDU> Reply-To: mash@winchester.UUCP (John Mashey) Distribution: world Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 39 Keywords: RISC MIPS Simulation Performance In article <17915@ucbvax.BERKELEY.EDU> shebanow@ji.Berkeley.EDU.UUCP (Mike Shebanow) writes: >In article <15217@amdcad.UUCP> tim@amdcad.UUCP (Tim Olson) writes: >>Perhaps a small description of our simulation environment is in order.... > >I have several questions regarding the simulation. It would >be quite unfair to compare the running times for a real VAX 11/780 against >a simulation, unless the following effects are included in the simulation: >...(list of important effects)... > >I don't mean to put the AM29000 down (as including all of the above into >a simulation is beyond difficult), but using simulation times to compare >performance against a real machine is unreasonable (as is a MIPS >to MIPS comparison). In defense of AMD, comparing simulation against a real machine is NOT unreasonable; it's been done plenty of times, and if done well, can be quite accurate [we do this all of the time, and generally get within several percent, sometimes better.] Serious computer design requires accurate simulators: there are too many tradeoffs to do it by intuition alone. Note, of course, that simulators can have bugs, and that one really only knows when you can start corellating simualtions with the real numbers. Finally, Tim O. had replied (well) to the original list of questions. Let me add one more: How often were caches swept in the simulations to account for context-switch, clocks [running under unix, you can lose several % to the fact that clock interrupts execute a bunch of code], system-call overhead, etc? Note that even when you only measure user time, going in and out of the kernel can blast your I-cache, and, if you're not careful, every single read/write can zap big hunks of your D-cache. The kernel time to do this is (properly) not counted, but you can be surprised by cache effects in this type of machine. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086