How does RGBench work?

Unlike most benchmark programs (e.g. MacBench or BAPCo, which is the standard benchmark of the German computer magazine c't) RGBench concentrates on the raw computing speed of the computer. Subsystems like hard disk or graphics cards should only play a minor role. This situation is typical for scientific number crunching applications. Such programs are usually "handwritten" and may run for hours, days or even weeks. However, output to the display and disk-IO is always slow in comparison to CPU speed and even to RAM access. Therefore this kind of access is reduced to a minimum and is not a factor in the speed of such a program. On the other hand, disk and graphics-IO is an important factor in the speed of so called standard applications (word processors, spreadsheets, databases, Photoshop, ...) Benchmarks like MacBench or BAPCo either try to mimic these standard applications or even use them.

Hence, RGBench primarily tests the speed of the CPU and the cache and memory subsystem. Unfortunately, the amount of data is quite often much larger than the size of the cache. By using three different sizes of data fields, RGBench examines the influence of cache­both its size and speed­on computing speed. The largest data field fits only into the L3-Cache of some highend Alpha workstations (of which I was not aware when I started writing the benchmark).

All programs in RGBench are taken from the fields in which I am (or was) working. These are the simulation of simple fluids (or more generally soft matter) and AI. Two of the programs are dominated by FPU performance (MD and MC). The other two concentrate mainly on integer calculations (MCI and GA).

I know that the algorithms used could easily be optimized. However, it is my experience that the success of optimization depends heavily on the computer. In other words, a speed gain of 20 or 30 percent on one computer/compiler combination might lead to almost nothing on another. I therefore tried to keep the programs a simple as possible and avoid CPU specific optimizations. (Nevertheless, the SGI Indy workstations might be overrated since they were the development platform).

RGBench consists of four programs:

There has been a forth Benchmarking program included. Unfortunately it turn out that in gaBench (GA) 12 source code lines out of 510 lines consume roughly 90 % of the CPU in this program. Hence a compiler good in optimizing this particular loop could easliy push the results of gaBench and RGBench to the top. Therefore it I skiped gaBench.

Accordingly the interger score is now identical to the result of MCI. The results of MD and MC are averaged to obtain the FPU score. Intgere and FPU score are avareged to the total score where the interger score has a weight of 40 %.

Three different amounts of data (about 512kB, 2MB and 8MB) were used to determine the influence of the cache. The score for the programs themselves are the averages over all three data fields. The scores for the data fields were averaged over all four programs. Here gaBench is still included. In next days I will recalculated the numbers here, as well.

On a lot a benchmark pages, I found almost no information about the hardware (e.g. speed and size of the cache) used. However different aspects of the hardware surrounding the CPU can have a great impact on the results. For example, a PowerPC 603 goes from Pentium class to faster than a Pentium II simply by adding a backside cache. Thus these details could be of great importance for the interpretation of the results. I therefore added a page with this data (to the extent known).

I invite everyone to contribute to the database of this benchmark. You can obtain the programs for free here. I would appreciate it if you would send your results to me. I will publish them here as long as they are not redundant.