Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!husc6!mit-eddie!genrad!decvax!decwrl!amdcad!cae780!tektronix!reed!omen!caf From: caf@omen.UUCP (Chuck Forsberg WA7KGX) Newsgroups: comp.sys.ibm.pc,comp.sys.misc Subject: Siev and 2^4096 Benchmarks Updated Message-ID: <427@omen.UUCP> Date: Tue, 25-Nov-86 05:37:22 EST Article-I.D.: omen.427 Posted: Tue Nov 25 05:37:22 1986 Date-Received: Wed, 26-Nov-86 03:45:34 EST Distribution: net Organization: Omen Technology, Portland Lines: 417 Xref: mnetor comp.sys.ibm.pc:237 comp.sys.misc:66 Siev and BCT Benchmarks: Comdex 1986 Edition The Siev benchmark has a new winner: the 25 mHz 68020 powered Definicon Systems ran siev in .34 seconds. This is more than twice as fast as the fastest 386 box in captivity, and mearly as fast as a bug mainframe. An interesting note is the Computer Dynamics 18 mHz 386 System (Intel Motherboard): The benchmark was compiled with both 8086 and 80286 code generation. The 86 siev object file was 113 bytes of executable code, and the 286 file was 108 bytes, a reduction of 5 per cent code space. Yet the 8086 code consistiently ran about four per cent faster than the more compact 286 code! It is also interesting (and disappointing) to note that the Intel 386 Motherboard is 50 per cent slower than an 8mHz AT clone when forced to use 16 bit memory. BCT additions: time bc <40% during the Unicom show. Stay tuned ... ^ Real time measured from beginning of program execution to program finish (omitting loading and reboot time). & Compile/link times; sequenced by "batch" file; 20 buffers, NO verify. Verify adds about 15 seconds. ! A much faster code generator has been promised. * Data from compiler vendor re Byte Magazine version. **Data from compiler vendor re Byte Magazine version. A optimizer under development provides about 30% improvement in code density and execution speed. @ compiler/linker Executables on hard disk, other files on electronic disk IBM PC, DOS 2.1, Maynard WS-1 Hard Disk except for IBMPC-AT(extended) as shown. + Compiled with the Lattice 8086 D model (big data memory, <64k code), and 32 bit index variables. For comparision with 68000 based systems listed as 32 bit systems, as the 68000 compilers listed there use long integers and can address >64k without compiling in special modes. No electronic disk used. -------------- Comment ------------ These times are approximate and may improve as product development proceeds on the newer systems. They should be used as general information regarding the levels of performance possible and not in any specific purchasing decision without independent confirmation. It should be noted that the short loops in this program may penalize highly pipelined machines such as the 16032 more than other (more representative of normal usage) programs. An interesting note is the Computer Dynamics 18 mHz 386 System (Intel Motherboard): The benchmark was compiled with both 8086 and 80286 code generation. The 86 siev object file was 113 bytes of executable code, and the 286 file was 108 bytes, a reduction of 5 per cent code space. Yet the 8086 code consistiently ran about four per cent faster than the more compact 286 code! It is also interesting (and disappointing) to note that the Intel 386 Motherboard is 50 per cent slower than an 8mHz AT clone when forced to use 16 bit memory. The Regulus software is listed with different times in 16 and 32 bit categories because the compiler uses 16 bit integers and defaults to 16 bit addressing except for pointers. On some systems, there is a considerable discrepancy between the real and user times that cannot be explained by other demands on the system. Usually, the real and user times are nearly the same when a cpu bound program is run on an otherwise unloaded Unix(TM) system. The compile/link times are often more significant in predicting how responsive a system will be in a software development context. On BDS C, the variables are made externs to optimize 8080 execution speed and code density. BDS C lacks longs, floats, and some other aspects of C, but it produces reasonable code density and is an excellent compromise for the CP/M environment. Compile times were influenced by the structure of the compiler. The Unix(TM) compilers had up to 5 passes (preprocessor, c0, c1, c2, as) while Lattice and BDS C have but two passes to produce object code (BDS uses no intermediate file). Lattice, C86 and Coherent/CC86 bypass the assembly pass. The compile/link times are affected by the size of the library that must be scanned. This tends to penalize the more nearly complete implementations such as C86 and Coherent/Mark Williams. Some MS-DOS implementations place uninitialized externs in the .exe file. For example, the Lattice C v2.0 results in a 19584 byte .exe file for siev, while the C86 v2.10j .exe file is 9466 bytes! Unix, Zenix, VAX, et al. are trade-marks. From lanl-a!jlg Wed May 11 14:39:55 1983 Subject: sieve Newsgroups: net.micro The sieve program used in BYTE was not really a very good benchmark of larger machines. The problem is, there is too much stuff in the algorithm that is not necessary (ie. never used or printed). A good compiler on a large machine will probably 'optimize' all of this stuff out. The result is that the same algorithm is not performed on each machine. No one with access to both IBM and CRAY machines will really beleave that the IBM numbers in the January BYTE are correct. The CRAY fortran numbers (CFT is not very good at global optimization) are pretty accurate, also a hand coded assembly version of the algorithm (which implements the whole benchmark with nothing optimized out) beats the best IBM numbers by 50%. The advantage of vector arch.... This may not seem to be relevant to the discussion of micros, but the newer machines now and in the near future will be a lot more sophisticated than those most micro fans are familiar with. Be on the lookout for bad benchmarks! Mainframe people have had to face this problem many times. J.L. Giles (...!lasl-a!jlg) From ixn5h!dcn Thu May 12 05:48:56 1983 Subject: Re: Aztec C Review Newsgroups: net.micro.apple I decided to quantify my complaint about the slow compilation of Aztec C on the Apple by running the benchmark program in the January 1983 issue of Byte. I still have the interpreted version, V1.03, with two drives. I was also lazy enough to leave off the comments. The results for the sieve program are: Compile: compile = 1:03 (min:sec) assemble = 0:33 link = 1:17 total = 2:53 Execute: 6:37 or 397 seconds I also tried the Pascal version, with these results: Compile: 0:18 Execute: 8:31 or 511 seconds By comparsion, the Integer BASIC execute time was 1850 seconds and Applesoft BASIC was 2806 seconds. I know Pascal is easy to compile, but should it take so long to compile the C code? The compile times for other machines in the article were an order of magnitude faster, so maybe it's just not optimized for the Apple. I'm looking forward to trying the native- code compiler. Dave Newkirk ihnp4!ixn5h!dcn /* * Huge model siev needed for fair comparision of 16 bit CPU's with 68000 * and VAX types. Compile with huge model. Use 80190 and 80191 for sizes * which gives 14713 primes to make sure it really IS huge model code. */ #include #define SIZE 8190 #define SIZEPL 8191 char f[SIZEPL]; main() { register long i,p,k; register int c, n; for (n = 1; n <= 10; n++) { c = 0; for (i = 0; i <= SIZE; i++) f[i] = 1; for (i = 0; i <= SIZE; i++) { if (f[i]) { p = i + i + 3; k = i + p; while (k <= SIZE) { f[k] = 0; k += p; } c++; } } } printf("\n%d primes.\n", c); } Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix ...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software" Voice: 503-621-3406 17505-V Northwest Sauvie Island Road Portland OR 97231 TeleGodzilla BBS: 621-3746 2400/1200 CIS:70007,2304 Genie:CAF Source:TCE022 omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly