home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / ibm / pc / hardware / 33065 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  30.1 KB

  1. Path: sparky!uunet!think.com!yale.edu!ira.uka.de!uka!uka!news
  2. From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
  3. Newsgroups: comp.sys.ibm.pc.hardware
  4. Subject: Performance comparison: Cyrix 486DLC, Intel RapidCAD, C&T 38600DX
  5. Date: 14 Dec 1992 13:30:29 GMT
  6. Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
  7. Lines: 511
  8. Distribution: world
  9. Message-ID: <1gi29lINNm9p@iraul1.ira.uka.de>
  10. NNTP-Posting-Host: irav1.ira.uka.de
  11. X-News-Reader: VMS NEWS 1.23
  12.  
  13. Performance Comparison Intel 386DX, Intel RapidCAD, C&T 38600DX, Cyrix 486DLC
  14.  
  15. This document, containing descriptions and a benchmark comparison of the
  16. Intel 386DX, Intel RapidCAD, C&T 38600DX, and the Cyrix 486DLC has been
  17. put together for the benefit of the net.community. I believe, but cannot
  18. guarantee, that all data given herein is correct. If you would like to
  19. report errors in this document, or have suggestions for its enhancement,
  20. feel free to contact me at the following email address:
  21.  
  22.      S_JUFFA@IRAVCL.IRA.UKA.DE
  23.  
  24. You can also write to me at my snail mail address:
  25.  
  26.      Norbert Juffa
  27.      Wielandstr. 14
  28.      7500 Karlsruhe 1
  29.      Germany
  30.  
  31. Corrections pertaining to spelling or grammatical errors are also encouraged,
  32. especially from those net.users that are native speakers of (American) English.
  33.  
  34.  
  35. This is the second version of this document. Thanks to the people that helped
  36. improve it by their comments on the previous version:
  37.  
  38.     Alex Martelli (martelli@cadlab.sublink.org),
  39.     Fred Dunlap (cyrix!fred@texsun.Central.Sun.COM)
  40.  
  41. A special thanks for editing this article goes to:
  42.  
  43.     David Ruggiero (osiris@halcyon.halcyon.com)
  44.  
  45.  
  46. ---------------------------------------------------------------------------
  47.  
  48. In 1992, three new CPUs were introduced into the PC marketplace. Each has the
  49. capability to replace the standard Intel 386DX CPU and provide higher
  50. performance for existing 386 systems. These new chips are the Intel RapidCAD,
  51. the Chips&Technologies (C&T) Super386 38600DX, and the Cyrix 486DLC. At the
  52. moment, all of these are only available in 33 MHz versions, but C&T and Cyrix
  53. have announced 40 MHz versions for delivery in early 1993. (Of course you could
  54. try to push existing 33 MHz chips to 40 MHz, but I do not recommend this, as my
  55. experience shows that operation at the higher frequency tends to be unreliable,
  56. with the possibility of the machine locking up unexpectedly.) While the Intel
  57. RapidCAD is marketed only as an end-user product (which means PC manufacturers
  58. will not ship systems with the RapidCAD already installed), both C&T and Cyrix
  59. sell their products directly to the end user as well as to PC motherboard
  60. manufacturers. Cyrix also manufactures the 486SLC, which is a replacement for
  61. the Intel/AMD 386SX CPUs. C&T has announced a 38600SX chip, but it will not
  62. ship before sometime in 1993, if at all.
  63.  
  64. The Intel RapidCAD
  65. ------------------
  66.  
  67. The Intel RapidCAD is, in rough terms, an Intel 486DX with the 8 kB on-chip
  68. cache removed and a 386 pinout. To software, it appears to be a 386DX with a
  69. math coprocessor, as the 486-specific instructions have been removed from its
  70. instruction set. It is marketed by Intel as "the ultimate coprocessor" and, as
  71. the name implies, its main purpose is to replace the 386DX in existing systems
  72. and thereby boost the performance of floating-point intensive applications such
  73. as CAD software, spreadsheets, and math packages (e.g. SPSS, Mathematica).
  74.  
  75. RapidCAD is delivered as a set of two chips. RapidCAD-1 is a 132-pin PGA (pin
  76. grid array) chip that goes into the CPU socket and replaces the 386DX. It
  77. contains the CPU and the FPU (floating-point unit). RapidCAD-2 is a 68-pin PGA
  78. chip that goes into the 387 coprocessor (or EMC) socket; it contains a simple
  79. PLA whose only purpose it to generate the FERR signal for the motherboard
  80. logic: this provides full PC-compatible handling of floating point exceptions.
  81. Many CPU instructions execute in one clock cycle in the RapidCAD, just as on
  82. the Intel 486. The RapidCAD is constrained, however, by use of the standard
  83. 386DX bus interface, since every bus cycle takes two CPU clock cycles. This
  84. means that instructions may be executed by the RapidCAD faster than they can be
  85. fetched from memory. But as most FPU instructions take longer to execute than
  86. CPU instructions, they are not greatly slowed down by this slow bus interface,
  87. and most of them execute in the same time as in the Intel 486DX. Therefore, the
  88. Intel RapidCAD provides higher overall floating-point performance than any
  89. existing 386/387 combination. Results from the SPEC benchmarks, a common
  90. workstation UNIX benchmark suite, show that the RapidCAD provides 85% more
  91. floating point and 15% more integer performance than an Intel 386DX/387DX
  92. combination at the same clock frequency.
  93.  
  94. Power consumption of the RapidCAD is typically 3500 mW at 33 MHz. The current
  95. street price of the 33 MHz version is ~300 US$.
  96.  
  97. The C&T 38600DX
  98. ---------------
  99.  
  100. The Chips&Technologies 38600DX is designed to be 100% compatible to the Intel
  101. 386DX CPU. Unlike AMD's Am386 CPUs (which use microcode that is identical to
  102. the Intel 386DX's microcode), the C&T 38600DX uses new microcode developed
  103. within C&T using "clean-room" techniques. C&T even included the 386DX's
  104. "undocumented" LOADALL386 instruction in the instruction set to provide full
  105. compatibility with the Intel chip.
  106.  
  107. Some instructions execute faster on the 38600DX than on the 386DX. C&T also
  108. produces a 38605DX CPU that includes a 512-byte instruction cache and provides
  109. further performance increases over the Intel part. The 38605DX needs a bigger
  110. socket (144-pin PGA) and is therefore *not* pin-compatible with the 386DX.
  111.  
  112. In my tests, I found that the 38600DX has severe problems with the CPU-
  113. coprocessor communication, which causes its floating-point performance to drop
  114. below the level provided by the Intel 386DX/Intel 387DX for most programs. This
  115. problem exists with all available 387 compatible coprocessors (ULSI 83C87, IIT
  116. 3C87, Cyrix EMC87, Cyrix 83D87, Cyrix 387+, C&T 38700, and the Intel 387DX). (A
  117. net.acquaintance also did tests with the 38600DX and arrived at similar
  118. results. He contacted C&T and they said they were aware of the problem.)
  119.  
  120. Typical power consumption of the 40 MHz 38600DX is 1650 mW, which is less than
  121. the typical power consumption of the Intel 386DX at 33 MHz (2000 mW). The
  122. 38600DX currently sells for ~US$ 80 for the 33 MHz version.
  123.  
  124. The Cyrix 486DLC
  125. ----------------
  126.  
  127. The Cyrix 486DLC is the latest entry into the market of 386DX replacements. It
  128. features a 486SX compatible instruction set, a 1 kB on-chip cache, and a 16x16-
  129. bit hardware multiplier. The RISC-like execution unit of the 486DLC executes
  130. many instructions in a single clock cycle. The hardware multiplier multiplies
  131. 16-bit quantities in 3 clock cycles, as compared to 12-25 cycles on a standard
  132. Intel 386DX. This is especially useful in address calculations (code from non-
  133. optimizing compilers may contain many MUL instructions for array accesses) and
  134. for software floating-point arithmetic (e.g., a coprocessor emulator). The 1 kB
  135. cache helps the 486DLC to overcome the limitations of the 386 bus interface,
  136. although its hit rate averages only about 65% under normal program conditions.
  137.  
  138. In existing 386 systems, DMA transfers (such as those performed by a SCSI
  139. controller or a sound board) may force the internal cache of the 486DLC to be
  140. flushed as the only means available in a 386 system to enforce consistency
  141. between the contents of the on-chip cache and external memory. This stems from
  142. the fact that the 386 bus interface was designed without provisions for an
  143. on-chip cache. This problem can reduce the performance of the 486DLC in systems
  144. that do a sizeable amount of (bus master) DMA. Cyrix has, however, defined some
  145. additional cache control signals for some of the 486DLC lines; they can be used
  146. to improve communications between the on-chip cache and a larger external cache
  147. or main memory and prevent this problem. Although current 386 systems ignore
  148. these signals (since they are not defined for the Intel 386DX), future systems
  149. designed with the Cyrix chip in mind may take advantage of them and thereby
  150. gain increased performance.
  151.  
  152. The Cyrix cache is a unified data/instruction write-through type and can be
  153. configured as either a direct-mapped or 2-way set associative cache. It permits
  154. definition of up to four non-cacheable regions, which are particularly useful
  155. if a system has memory mapped peripherals (e.g., the Weitek math coprocessor).
  156. For compatibility reasons, the cache is disabled after a processor reset
  157. and must be enabled with the help of a small program provided by Cyrix. This
  158. prevents problems with BIOSes that are not "486DLC aware". (I am certain that
  159. future versions of the AMI BIOS and other BIOSes will take the 486DLC into
  160. consideration and directly support the Cyrix chip's cache.)
  161.  
  162. The 486DLC will not work correctly with all math coprocessors in all
  163. circumstances, with protected mode multitasked environments (e.g. MS-Windows
  164. 386-enhanced mode) being especially critical. Using the 486DLC with the Cyrix
  165. EMC87, Cyrix 83D87 (chips produced prior to November 1991), and IIT 3C87, I
  166. have been able to completely lock up the machine due to synchronization
  167. problems between the CPU and the coprocessor while executing the FSAVE or
  168. FRSTOR instructions (which are used to save and restore the coprocessor status
  169. during task switches). According to Cyrix, this problem only occurs with the
  170. first revision of the 486DLC and is fixed on newer ones. To be on the safe
  171. side, the 486DLC should best be used with the Cyrix 387+ (its "Europe-only"
  172. name) or with the identical Cyrix 83D87 (US-bound chips manufactured after
  173. October 1991): these are not only are the highest performing 387 coprocessors
  174. on the market, but they also work properly even with the first generation
  175. 486DLC.
  176.  
  177. If you already have a Cyrix 83D87 coprocessor and want to know whether it is
  178. the old or new type, I recommend you use my COMPTEST program, available as
  179. CTEST257.ZIP via anonymous ftp from garbo@uwasa.fi and other fine ftp servers.
  180. If COMPTEST reports a 387+, you either have the 387+ or the identical newer
  181. version of the 83D87 installed and can use any version of the Cyrix 486DLC
  182. without problems. If you believe that you may have problems with a 486DLC/387
  183. combination, I suggest you contact Cyrix technical support (1-800-FAS-MATH in
  184. the US).
  185.  
  186. Power consumption of a 40 MHz 486DLC is typically 2800 mW. The 486DLC sells for
  187. ~115 US$ for the 33 MHz version, according to its German distributor.
  188.  
  189. Tests and benchmarks
  190. --------------------
  191.  
  192. HW configuration: 33.3/40 MHz motherboard with Forex chip set and AMI BIOS. 128
  193. kB zero- wait-state, direct mapped, write-through CPU cache with one write
  194. buffer, 4 bytes per cache line, and 4 clock cycles penalty for a cache line
  195. miss. 8 MB of main memory with an average access time of 1.6 wait states. Cyrix
  196. EMC87 in 387 compatibility mode as math coprocessor. (This and the Cyrix 83D87
  197. / 387+ are the fastest coprocessors available for use with the
  198. 386DX/486DLC/38600DX). Conner 3204F hard disk, 203 MB capacity, IDE interface
  199. (CORETEST throughput 1100 kB/s, seek time 16 ms). Diamond SpeedSTAR HiColor,
  200. ISA bus SVGA card using Tseng's ET4000 chip, 1 MB DRAM as frame buffer, *no*
  201. accelerator. The switches on the card were set for fastest reliable operation,
  202. with a throughput of 6500 bytes/ms at 40 MHz and 5400 bytes/ms at 33.3 MHz.
  203.  
  204. SW configuration: MS-DOS 5.0, MS Windows 3.1, HyperDisk 4.32 disk cache program
  205. in write-back mode, using 2 MB of extended memory, 386MAX 6.01 used as memory
  206. manager and DPMI provider in some benchmarks. Latest Tseng (Colorview) driver
  207. for Windows 3.1 at 1024x768x256, using the 8514 fonts.
  208.  
  209.  
  210. For the Whetstone, Dhrystone, WINTACH, DODUC, LINPACK, LLL, and Savage
  211. benchmarks, *higher* numbers indicate *faster* performance.
  212.  
  213. For the MAKE RTL, MAKE TRANCK, and String-Test benchmarks, *lower* numbers
  214. indicate *faster* performance.
  215.  
  216.  
  217.                          Intel        C&T      Intel      Cyrix      Cyrix
  218. 33.3 MHz                 386DX    38600DX   RapidCAD      486DLC     486DLC
  219.                                                         cache off    cache on
  220. integer
  221.  
  222. Whetstone [kWhets/s]       447        585        563        695        803
  223. Dhrystone (C) [Dhry./s]  11688      11819      12357      14150      15488
  224. Dhrystone (Pas) [Dhry./s]10455      10877      10751      12154      13858
  225. String-Test [ms]           459        453        441        347        327
  226. MAKE RTL [s]                51.32      47.10      46.34      43.45      39.13
  227. MAKE TRANCK [s]             62.42      55.47      55.37      53.64      46.12
  228. WINTACH [overall RPM]        4.85       4.90       5.49       5.53       6.14
  229.  
  230. float
  231.  
  232. DODUC [Rapidity index]      79.0       76.4      150.3       89.4       90.7
  233. LINPACK [MFLOPS]             0.2808     0.2707     0.4578     0.3158     0.3438
  234. LLL [MFLOPS]                 0.3352     0.3537     0.6083     0.3816     0.4139
  235. Whetstone [kWhets/s]      2540       2340       3990       2908       3061
  236. Savage [function eval/s] 71685      53191      72464      88757      93897
  237.  
  238.  
  239.                          Intel        C&T      Intel      Cyrix      Cyrix
  240. 40.0 MHz                 386DX    38600DX   RapidCAD      486DLC     486DLC
  241.                                                          cache off   cache on
  242. integer
  243.  
  244. Whetstone [kWhets/s]       536        702        676        835        963
  245. Dhrystone (C) [Dhry./s]  14128      14116      14836      16987      18750
  246. Dhrystone (Pas) [Dhry./s]12490      13067      12890      14573      16624
  247. String-Test [ms]           384        377        368        289        273
  248. MAKE RTL [s]                43.46      40.11      39.84      37.25      33.54
  249. MAKE TRANCK [s]             53.00      47.59      47.07      45.36      39.00
  250. WINTACH [overall RPM]        5.65       5.73       6.41       6.46       7.23
  251.  
  252. float
  253.  
  254. DODUC [Rapidity index]      94.9       77.5      180.3      105.1      106.6
  255. LINPACK [MFLOPS]             0.3324     0.3260     0.5418     0.3789     0.4131
  256. LLL [MFLOPS]                 0.4025     0.4204     0.7263     0.4562     0.4956
  257. Whetstone [kWhets/s]      3061       2632       4798       3505       3677
  258. Savage [function eval/s] 86083      49587      86957     106762     112360
  259.  
  260.  
  261. To complete the picture, I ran the CPU/FPU standard benchmarks on an Intel
  262. 486DX running at 33.3/40 MHz. Since the 486 machine was configured with a
  263. different hard disk than the 386 system, and the compilers and tools installed
  264. on the 386 machine were not present, the MAKE benchmarks could unfortunately
  265. not be included in the tests.
  266.  
  267. 486DX, 256 kBytes CPU cache (write-thru), 8 MB of RAM, AMI-BIOS, Diamond
  268. SpeedSTAR HiColor (VIDSPEED thoughput: 6500 bytes/ms at 40 MHz and 5400
  269. bytes/ms at 33.3 MHz), MS-DOS 5.0, MS-Windows 3.1:
  270.  
  271. integer                       33.3 MHz             40 Mhz
  272.  
  273. Whetstone [kWhets/s]          707                 848
  274. Dhrystone (C) [Dhry./s]     19394               23265
  275. Dhrystone (Pas) [Dhry./s]   16978               20368
  276. String-Test [ms]              333                 279
  277. WINTACH                         8.59               10.14
  278.  
  279. float
  280.  
  281. DODUC [Rapidity index]        184.0              220.7
  282. LINPACK [MFLOPS]                0.6682              0.8204
  283. LLL [MFLOPS]                    0.9387              1.1110
  284. Whetstone [kWhets/s]         5143                6195
  285. Savage [function eval/s]    82192               98522
  286.  
  287.  
  288. Conclusions
  289. -----------
  290.  
  291. The Cyrix 486DLC is the 386DX replacement with the highest integer performance.
  292. With the internal cache enabled, integer performance of the 486DLC can be up to
  293. 80% higher compared with a Intel 386DX at the same clock frequency, with the
  294. average speed gain for integer applications being 35%. Enabling the internal
  295. cache provides about 5-15% more performance than with the cache disabled for
  296. both integer and floating-point applications. Floating-point applications are
  297. accelerated by about 15%-30% if the Cyrix 486DLC (with cache enabled) is used
  298. instead of the Intel 386DX. Compared with the Intel 486DX, the Cyrix 486DLC
  299. provides about 70% of the integer performance and about 50% of the floating
  300. point performance at the same clock frequency.
  301.  
  302. The Intel RapidCAD is the 386DX replacement that provides the highest floating
  303. point performance. It can speed up most floating-point intensive programs by
  304. 60%-90% compared with the fastest Intel 386DX/math coprocessor combination; it
  305. provides nearly 75% of the floating-point performance of a Intel 486DX at the
  306. same clock frequency. Integer performance increases by an average 15% by using
  307. the RapidCAD instead of the standard Intel 386DX, with the maximum performance
  308. gain being 35%.
  309.  
  310. The Chips&Technologies 38600DX has a slightly higher integer performance than
  311. the Intel 386DX, with the speedup ranging from 0%-30% and an average speedup on
  312. the order of 10%.
  313.  
  314.  
  315. Description of benchmarks
  316. -------------------------
  317. DHRYSTONE [9] is a synthetic benchmark developed by R. Weicker from Siemens in
  318. 1984. The frequency of operations and data types used by Dhrystone are modeled
  319. after statistics collected for 'typical' programs that are written in a HLL
  320. (high level language) such as C or Pascal that do not use floating-point
  321. arithmetic. Thus there is a certain distribution of global and local variables
  322. being used in procedures, there is a certain percentage of use of records
  323. (structs) or strings out of the total number of variables accessed and there is
  324. a certain percentage of procedure calls and if-statements out of the total
  325. lines of codes executed. All these percentages match the statistics used in the
  326. development of Dhrystone quite closely. To preserve the typical distributions,
  327. the measurement rules for Dhrystone forbid function inlining (a frequently used
  328. optimization technique optionally performed by most optimizing compilers). The
  329. current version of Dhrystone is 2.1, and this is the version used for my tests.
  330. Version 2.1 [10] differs from previous versions in that it contains additional
  331. code that prevents optimizing compilers from throwing out most of the code by
  332. dead code elimination (since Dhrystone has no input file, many expressions can
  333. be computed at compile time), thus artificially inflating performance numbers.
  334. The Dhrystone benchmark exists in equivalent Ada, Pascal and C versions, which
  335. are all available from netlib@ornl.gov. Dhrystone measures the time to execute
  336. its main loop and sets this time into relation with a fixed reference time, the
  337. result being a performance index given in "Dhrystones per second". I used two
  338. Dhrystone executables. One was compiled using the non-optimizing Turbo Pascal
  339. 6.0 compiler, the other one was compiled with the MS-C 7.0 compiler using the
  340. large memory model and maximum optimization but without the use of function
  341. inlining. Because the Turbo Pascal executable uses more memory operands and the
  342. MS-C executable uses more register-to-register operations, the speedup for the
  343. executables on different CPUs can be noticeably different.
  344.  
  345. WINTACH is a public domain benchmark program by Texas Instruments that measures
  346. the speed of graphics output for four typical MS-Windows applications: a word
  347. processor, a spreadsheet, a CAD program, and a paint program. TI has collected
  348. profiles for each class of applications under 'typical' user loads. The four
  349. parts of the WINTACH benchmark were then modeled after these profiles, so that
  350. the percentage of certain GDI (graphics device interface) calls found in the
  351. profiles is also present in the benchmark. WINTACH determines the performance
  352. of each program part relative to the performance of a standard VGA card in a 20
  353. MHz 386DX machine. It also combines the four values into an overall relative
  354. performance index, which is reported in my tables. Using this single number to
  355. represent graphics performance is justified in this case since the four partial
  356. results do *not* deviate much from the average for the SVGA tested (a Diamond
  357. SpeedSTAR HiColor). I used a frame buffer card for the test because for these
  358. graphics card type, graphics performance depends solely on the performance of
  359. the CPU, which handles all accesses to the display memory. On an accelerated
  360. card, some of the low-level operations are delegated to the accelerator chip
  361. and the influence of the CPU speed on the graphics performance is not seen so
  362. clearly. For this test, I used the latest Tseng Windows 3.1 driver (Colorview)
  363. at a resolution of 1024x768x256 with the large 8514 fonts (WINTACH code C8).
  364.  
  365. MAKE RTL is not a single program. Rather it is a build of a complete project,
  366. my own run-time library for Turbo Pascal 6.0. The project consists of about 200
  367. source files with a total size of ~650 kByte. Most of the source files are
  368. assembly language (.ASM) files, while there are also some Pascal (.PAS) files.
  369. Building the complete project using MAKE, about 200 binary files (.OBJ and
  370. .TPU) are produced with a combined size of ~300 kB. The programs used during
  371. the build are MAKE 3.5, TPC 6.01, and TASM 2.01, all by Borland, Inc. All files
  372. are read from and written to the hard disk, using a 2 MB write back disk cache
  373. provided by the HyperDisk 4.32 program. This eliminates most of the I/O
  374. overhead. No memory manager was installed during the test. The time reported is
  375. the time from starting the MAKE utility to the reappearance of the DOS prompt.
  376. MAKE RTL can be thought of being typical of applications that operate on a lot
  377. of small files, and use only integer instructions.
  378.  
  379. MAKE TRANCK is a project build for a project consisting of two assembly
  380. language modules, two C modules and one FORTRAN module. The combined size of
  381. the source files is approximately 120 kBytes. All modules are compiled
  382. (assembled) and combined into a single program linking with both, the C and the
  383. FORTRAN libraries. Programs used are MAKE 3.5 by Borland and MASM 6.0, MS-C
  384. 7.0, MS-FORTRAN 5.0, and LINK 5.3, all by Microsoft, Inc. The C compiler and
  385. the linker run in protected mode and require a DPMI host to be present. 386MAX
  386. 6.01 by Qualitas was installed for this purpose. To minimize I/O overhead, the
  387. HyperDisk 4.32 disk caching program was installed, with 2 MByte of extended
  388. memory allocated to the cache. The modules are compiled with compiler switches
  389. set for maximum optimization, and most of the time for the project build is
  390. spent in the optimizing stages of the compilers.
  391.  
  392. STRING-TEST is a simple benchmark that tests the string handling functions
  393. built into the Turbo Pascal language. Nearly all of the execution time is spent
  394. in repeated execution of the STOS, CMPS, SCAS, and MOVS instructions. The data
  395. and code fit into about five kBytes of memory. In cached systems, almost all
  396. memory accesses will be cache hits. The program was written and compiled with
  397. Turbo Pascal 6.0 and linked with my own run-time library, which provides much
  398. faster string functions than the run-time library delivered by Borland.
  399. Compiler switches were set for fastest execution. The time reported is the time
  400. to complete the whole benchmark in milliseconds, with an accuracy of +/-1
  401. millisecond.
  402.  
  403. LLL is short for Lawrence Livermore Loops [8], a set of kernels taken from real
  404. floating point extensive programs. Some of these loops are vectorizable, but
  405. since we don't deal with vector processors here, this doesn't matter. For this
  406. test, LLL was adapted from the FORTRAN original in [7] to Turbo Pascal. By
  407. variable overlaying (similar to FORTRAN's EQUIVALENCE statement) memory
  408. allocation for data was reduced to 64 kB, so all data fits into a single 64 kB
  409. segment. The older version of LLL is used here which contains 14 loops. There
  410. also exists a newer, more elaborate version consisting of 24 kernels. The
  411. kernels in LLL exercise only multiplication and addition. The MFLOPS rate
  412. reported is the average of the MFLOPS rate of all 14 kernels as reported by the
  413. LLL program. LLL and Whetstone results (see below) are reported as returned by
  414. my COMPTEST test program in which they have been included as a measure of
  415. coprocessor/FPU performance. COMPTEST has been compiled under Turbo Pascal 6.0
  416. with all 'optimizations' on and using my own run-time library, which gives
  417. higher performance than the one included with TP 6.0. My library is available
  418. as TPL60N17.ZIP from garbo.uwasa.fi and ftp-sites that mirror this site. All
  419. floating point variables in the program where declared as DOUBLE.
  420.  
  421. LINPACK [4] is a well known floating-point benchmark that also heavily
  422. exercises the memory system. Linpack operates on large matrices and takes up
  423. about 570 kB in the version used for this test. This is about the largest
  424. program size a pure DOS system can accommodate. Linpack was originally designed
  425. to estimate performance of BLAS, a library of FORTRAN subroutines that handles
  426. various vector and matrix operations. Note that vendors are free to supply
  427. optimized (e.g. assembly language versions) of BLAS. Linpack uses two routines
  428. from BLAS which are thought to be typical of the matrix operations used by
  429. BLAS. Both routines only use addition/subtraction and multiplication. The
  430. FORTRAN source code for Linpack can be obtained from the automated mail server
  431. netlib@ornl.gov. Linpack was compiled using MS FORTRAN 5.0 in the HUGE memory
  432. model (which can handle data structures larger than 64 kB) and with compiler
  433. switches set for maximum optimization. Linpack performs the same test
  434. repeatedly. The number reported is the maximum MFLOPS rate returned by Linpack.
  435. All floating point variables in the program were declared as DOUBLE. Linpack 
  436. MFLOPS ratings for a great number of machines are contained in [5]. This 
  437. PostScript document is also available from netlib@ornl.gov.
  438.  
  439. WHETSTONE [1,2,3] is a synthetic benchmark based on statistics collected about
  440. the use of certain control and data structures in programs written in high
  441. level languages. Based on these statistics, Whetstone tries to mirror a
  442. 'typical' HLL program. Whetstone performance is expressed by how many
  443. theoretical 'whetstone' instructions are executed per second. It was originally
  444. implemented in ALGOL. Unlike LLL and Linpack, Whetstone not only uses addition
  445. and multiplication but exercises all basic arithmetic operations as well as
  446. some transcendental functions. Whetstone performance depends on the speed of
  447. the coprocessor as well as on the speed of the CPU, while LLL and Linpack place
  448. a heavier burden on the coprocessor/FPU. There exist an old and a new version
  449. of Whetstone. Note that results from the two versions can differ by as much as
  450. 20% for the same test configuration. For this test, the new version in Pascal
  451. from [2] was used. It was compiled with Turbo Pascal 6.0 and my own library
  452. (see above) with all 'optimizations' on. For the integer test, software fp
  453. arithmetic using the REAL type was utilized. Using the software arithmetic
  454. exercises only the CPU, in particular the execution of MOV, SHL, SHR, RCR,
  455. ADD, SUB, MUL, and DIV instructions. For the floating point test, the hardware
  456. floating-point arithmetic of the coprocessor was used and computations were
  457. performed using the DOUBLE type.
  458.  
  459. SAVAGE tests the performance of transcendental function evaluation. It is
  460. basically a small loop in which the sin, cos, arctan, ln, exp, and sqrt
  461. functions are combined in a single expression. While sin, cos, arctan, and sqrt
  462. can be evaluated directly with a single 387 coprocessor instruction each, ln
  463. and exp need additional preprocessing for argument reduction and result
  464. conversion. According to [11], the Savage benchmark was devised by Bill Savage,
  465. and is distributed by: The Wohl Engine Company, Ltd., 8200 Shore Front Parkway,
  466. Rockaway Beach, NY 11693, USA. Usually, Savage is programmed to make 250,000
  467. passes though the loop. Here only 10,000 loops are executed for a total of
  468. 60,000 transcendental function evaluations. The result is expressed in function
  469. evaluations per second. SAVAGE source code was taken from [6] and compiled with
  470. Turbo Pascal 6.0 and my own run-time library (see above).
  471.  
  472. DODUC [12] is a modified application program by Nhuan Doduc that is also part
  473. of the SPEC benchmark suite. It is a nuclear safety analysis code that
  474. simulates the time evolution of a thermohydraulic modelization for a nuclear
  475. reactor's component and the benchmark is created from the computational kernel
  476. of the original application. The benchmark consist of 5323 FORTRAN statement
  477. lines and the executable size is about 350 kBytes. Almost all processing is
  478. done using double precision floating-point values. There is not much array
  479. processing. Instead the program has an iterative structure with an abundance of
  480. short branches and small loops. The version used for this test was compiled
  481. with the highly optimizing NDP FORTRAN V3.0 compiler from Microway, which
  482. generates a 32-bit mode executable that runs in protected mode using a
  483. protected mode loader provided by Microway. The execution time of the DODUC
  484. program is set into relation with fixed reference times and the result is
  485. scaled to give a "Rapidity index".
  486.  
  487.  
  488. References
  489. ----------
  490.  
  491. [1]  Curnow, H.J.; Wichmann, B.A.: A synthetic benchmark.
  492.      Computer Journal, Vol. 19, No. 1, 1976, pp. 43-49
  493. [2]  Wichmann, B.A.: Validation code for the Whetstone benchmark.
  494.      NPL Report DITC 107/88, National Physics Laboratory, UK, March 1988
  495. [3]  Curnow, H.J.: Wither Whetstone? The Synthetic Benchmark after 15 Years.
  496.      In: Aad van der Steen (ed.): Evaluating Supercomputers.
  497.      London: Chapman and Hall 1990
  498. [4]  Dongarra, J.J.: The Linpack Benchmark: An Explanation.
  499.      In: Aad van der Steen (ed.): Evaluating Supercomputers.
  500.      London: Chapman and Hall 1990
  501. [5]  Dongarra, J.J.: Performance of Various Computers Using Standard Linear
  502.      Equations Software.
  503.      Report CS-89-85, Computer Science Department, University of Tennessee,
  504.      March 11, 1992
  505. [6]  Huth, N.: Dichtung und Wahrheit oder Datenblatt und Test.
  506.      Design & Elektronik 1990, Heft 13, Seiten 105-110
  507. [7]  Esser, R.; Kremer, F.; Schmidt, W.G.: Testrechnungen auf der IBM 3090E mit
  508.      Vektoreinrichtung.
  509.      Arbeitsbericht RRZK-8803, Regionales Rechenzentrum an der Universit"at zu
  510.      K"oln, Februar 1988
  511. [8]  McMahon, H.H.: The Livermore Fortran Kernels: A test of the numerical
  512.      performance range.
  513.      Technical Report UCRL-53745, Lawrence Livermore National
  514.      Laboratory, USA, December 1986
  515. [9]  Weicker, R.P.: Dhrystone: A Synthetic Systems Programming Benchmark.
  516.      Communications of the ACM, Vol. 27, No. 10, October 1984, pp. 1013-1030
  517. [10] Weicker, R.P.: Dhrystone Benchmark: Rationale for Version 2 and
  518.      Measurement Rules.
  519.      SIGPLAN Notices. Vol. 23, No. 8, August 1988, pp. 49-62
  520. [11] FasMath 83D87 Benchmark Report. Cyrix Corporation, June 1990
  521.      Order No. B2004
  522. [12] Doduc, Nhuan: Fortran Execution Time Benchmark.
  523.      Unpublished manuscript, version 45, available from ndoduc@framentec.fr
  524.