mike@wicat.UUCP (Mike Hibler) (12/18/85)
RESULTS (formatted to plug into the comments at the beginning of dry.c): ------------------------------------------------------------------------------ As is: * WICAT MB 68000-8Mhz System V WICAT C 4.1 585 731 ~ * WICAT MB 68000-12.5Mhz System V WICAT C 4.1 1246 1537 ~ * WICAT PB 68000-8Mhz System V WICAT C 4.1 998 1226 ~ * WICAT PB 68000-12.5Mhz System V WICAT C 4.1 1530 1898 ~ Using shorts in place of ints: * WICAT MB 68000-8Mhz System V WICAT C 4.1 675 853 S~ * WICAT MB 68000-12.5Mhz System V WICAT C 4.1 1450 1814 S~ * WICAT PB 68000-8Mhz System V WICAT C 4.1 1169 1464 S~ * WICAT PB 68000-12.5Mhz System V WICAT C 4.1 1780 2233 S~ Notes: * ~ For WICAT Systems: MB=MultiBus, PB=Proprietary Bus ------------------------------------------------------------------------------ The 8 Mhz Multibus and all proprietary bus systems access memory across the system bus, the 12.5 Mhz Multibus CPU has on-board memory. WICAT's System V is derived from UniSoft's Uniplus+ and AT&T's version 5.2 release 1. The WICAT C compiler is derived from the original MIT 68000 compiler and AT&T's PCC. OBSERVATION (stop me if you have heard this before...): ------------------------------------------------------------------------------ Some "optimizers" may ruin the instruction mix which the program attempts to achieve. For example in the following piece of code from the main loop of Proc0: for (CharIndex = 'A'; CharIndex <= Char2Glob; ++CharIndex) if (EnumLoc == Func1(CharIndex, 'C')) Proc6(Ident1, &EnumLoc); IntLoc3 = IntLoc2 * IntLoc1; + IntLoc2 = IntLoc3 / IntLoc1; + IntLoc2 = 7 * (IntLoc3 - IntLoc2) - IntLoc1; Proc2(&IntLoc1); our optimizer effectively removes the marked statements since IntLoc2 is "dead" (i.e. it is reset at the beginning of the loop and not used after the loop). This eliminates a 32-bit by 32-bit division, a runtime function call on a 68000 based machine, and possibly a 32-bit by 32-bit multiplication (though more likely a short sequence of adds since the multiplication is by a constant). By eliminating the optimization (via a test of IntLoc2 after the loop), the net loss in "speed" was less than 2%, but who knows what other optimizations lurk out there! ------------------------------------------------------------------------------ Mike Hibler WICAT Systems utah-cs!uplhercules!wicat!mike
schwrtze@acf8.UUCP (E. Schwartz group) (12/20/85)
[eat eat...] People who write 'C' code like that should consider themselves very fortunate indeed to have any live dead analysis done on poor code. I would hope no person would write redundant code like that, of course a code generator might but I think the WICAT claim is marketing hype to push the fact of the live dead analysis. It is a good optimisation though. Just a poor way of showing its true value. Hedley Rainnie hedley@alaya cmcl2!alaya!hedley
mash@mips.UUCP (John Mashey) (12/22/85)
Hedley Rainnie writes: > People who write 'C' code like that should consider themselves very > fortunate indeed to have any live dead analysis done on poor code. I > would hope no person would write redundant code like that, of course a code > generator might but I think the WICAT claim is marketing hype to push the > fact of the live dead analysis. It is a good optimisation though. > Just a poor way of showing its true value. 1) Code generators might, especially really advanced ones that do some exotic optimizations. 2) More importantly, it does illustrate the care that must be taken in pure CPU benchmarks to that try to model the usage patterns of real programs. Benchmarks really ought not have any obviously dead code or dead variables. It's very amusing to see an optimizer optimize away most of a synthetic program from the back, eliminating varaibles whose values are unused, then the computations that set those variables, thus discovering more that are unused. 3) One simple technique provides clear results with most compilers: Just before loop ends, call a function passing variables (that would be dead) as arguments; of course, factor this function call into the usage patterns. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043