Benchmark (II)

February 2006


We will run two separate types of benchmarks on this flat panel data.

Pure Raster Exercise

In this benchmark we run just the rasterizing thread to produce a bitmap in memory. There is no additional overhead associated with processing the bitmaps produced by the rasterizer. This gives us a good handle on just how fast the rasterizer by itself runs. We use the sample application gdsrip.

 

Raster, Format and Compress

In this benchmark we run both the raster thread and a compression/format thread to move the bitmap from memory to disk as a compressed (packbits) TIFF file. This is closer to a "real" world application. This test gives some direction as to how to best use memory and threads. For this benchmark the sample application, gds2tiff, is used.



Pure Raster Timings

Dual 2.4 GHz Dual Xeon, gdsriplib v1.29, RHEL3, threads = 4, DBS = 4 million

Structure Pixel
(um)
Raster Buffer
(MB)
Number
of
Buffers
Time
(mm:ss)
pannel3 1 512 1 4:08
pannel3 0.5 512 1 11:49
TOP 1 512 1 66:09
TOP 1 1024 1 63:43


Comments

1. You would expect the second run at 0.5 pixel size to take 4 times the first run at 1 um pixel size. It only takes 2.4 times the first run indicating that there are other delays not related to rasterization.

2. You would expect the third run to take 15 times the first run since the TOP level has 15 instances of pannel3. It takes slightly more.

3. Increasing the raster buffer from 512MB to 1024MB improves the throughput a bit -- probably by reducing overhead associated with bands since there are 1/2 the number of bands to process.




Raster, Format and Compress

Dual 2.4 GHz Dual Xeon, gdsriplib v1.29, RHE3, threads = 4, DBS = 4 million

Structure Pixel
(um)
Raster Buffer
(MB)
Number
of
Buffers
Time
(mm:ss)
pannel3 1 512 1 9:39
pannel3 1 512 2 6:10
TOP 1 750 1 160:16
TOP 1 750 2 104:48
TOP 1 1024 1 155:42
TOP 1 1024 2 105:48


Comments

1. a second thread (create_tiff) waits for the raster thread to complete and then takes the raw bitmap, compresses it using packbits and writes the compressed file to disk. Once it completes its job, the raster thread can work on the next band (for the 1 buffer case ...)

2. If a second raster buffer is defined, the raster thread can start work on the next band while the create_tiff is doing its compression work. This can (and does in these examples) result in improved throughput.



gdsriplib Benchmark   1   2   3