Benchmark

Benchmark measures graphics card and CPU performance on standard Chimera rendering tasks. It facilitates comparisons among hardware systems, and for users with access to different systems, indicates which will give the best performance with Chimera. Although the standardized tasks involve a cubic grid of data points, the scores are relevant to performance in displaying and manipulating molecular models.

The Chimera web site includes a table of scores for different computer systems. You can send your results and system description to chimera-dev@cgl.ucsf.edu to have them added to the table.

There are several ways to start Benchmark, a tool in the Utilities category.

The top part of the Benchmark panel initially contains explanatory text. When benchmark calculations are run, the results are appended to this text. The series of buttons under Run benchmark start the calculation(s), which can then be stopped with Halt as needed. Each benchmark finds and reports the edge size N of an N by N by N cube on which the task can be performed at 10 frames per second (fps). This edge size is also called the score for the task. Data that can be handled at 10 fps is easily manipulable in Chimera.

• all runs all of the following benchmarks
• surface measures the OpenGL rendering rate for triangles by drawing the surface of the cube
• mesh measures the OpenGL rendering rate for lines by drawing a mesh surface of the cube
• contour measures CPU and memory performance by contouring a Gaussian bump in the cube at a threshold that produces a spherical surface occupying nearly the whole volume
• solid measures two-dimensional texture mapping performance by making each point in the cube opaque white
• recolor measures bandwidth to the graphics card by repeatedly updating the color at each point in the cube

The models are drawn to an internal buffer and not actually shown in the Chimera graphics window. Pressing one of the buttons under Show standard model will draw the specified model type (surface, mesh, or solid) of the specified size in the graphics window. Depending on the size and viewing angle, a solid model may look like a stack of planes; this is an artifact of the rendering procedure. The Model Panel can be used to close the model. Rendering time depends on window size and positioning of the model within the view; these can be set as in the invisible benchmark runs using the Set standard view buttons camera (position and orientation of model within the view) and window size (512 x 512 pixels).

The Measure frame rate buttons report the frame rate for the current display. The benchmark results are based on the ideal frame rate; unlike the actual frame rate, the ideal rate does not include the fixed delay introduced by Chimera or effects from synchronization of OpenGL drawing with monitor refresh. Monitor actual frame rate reports the rate every second.

The benchmark results will be affected by the presence of additional models in Chimera. These should be closed before benchmarks are run. Similarly, the results will be affected if there are other processes running on the system. An iterative approach is used to find the data size that can be handled at 10 fps; if this fails to converge, the Halt button can be used to stop the calculation.

Insufficient memory.
The solid benchmark can run out of memory on a machine with fast graphics relative to main memory size.

Chimera window comes to top.
When the Chimera graphics window is covered by other windows, some systems will shortcut the drawing process. Running any of the benchmarks brings the graphics window to the top.

Timing method.
The benchmark timings use wall clock time (the Python time.time() call) instead of CPU time (Python time.clock()) because the latter does not measure the time used by the graphics card.

Convergence method.
Iterative bisection is used to find the 10 fps size. An alternative is to get the time for a given size and use a scaling law. However, there is no simple relationship between rate and data size; pixel fill rate, number of primitives, texture memory size, and CPU cache size can all cause hard-to-predict scaling behavior.