![]() |
|
DescriptionBMPSpeed Benchmark generates BMP files up to 512 MB. It measures speed of saving, loading, scrolling, rotating and editing of 0.5, 1, 2, 4 etc. MB files upwards. Pre-compiled versions of the benchmarks can be found in BMPSpd.zip which also contains the source code and more detailed explanations. New 64 and 32 bit versions are also available in Video64.zip with comparisons in 64 Bit Graphics Tests.htm. Some results of the new versions are given below. See also My Main Page for other PC benchmarks and results. Measurements include results for one of the fastest 2009 disks in an eSATA enclosure (system C2D4). For further details See Report. BMPSpd.exe has two built in 24 bit .BMP files size 204 x 204 and 288 x 288 pixels or about 0.125 and 0.25 MBytes. The program alternately doubles the pixel dimensions to produce files for testing at 0.5, 1, 2, 4 up to 512 MB, with 50% of RAM size being the default largest size. Extra copies for editing result in memory demands of more than twice the largest image size leading to paging to/from disk. Five tests are run at each size, run times being saved in log file BMPTime.txt. 1 - Enlarge with blur editing (copy with add/divide instructions) and display. 2 - Save enlargement to disk. 3 - Load from disk, format and display. 4 - Copy from memory scrolling. 5 - Make an extra copy rotating 90 degrees and display. Data transfer speeds in MB/second are also recorded for Test 4 where displayed data might be from video RAM cache, main RAM or disk page file. Example Results Log
ExplanationFor Enlarge, Read and Rotate, memory is allocated and an attempt made to create a Device Independent Bitmap (CreateDIBitmap function), needed for use with fast BitBlt block copying to the screen. When insufficient resources are available the DIB cannot be created and a slow copy function has to be used (StretchDIBits). The number of successful DIB creations are indicated in the last column. For such as scrolling, a copy of the whole image can be cached in video RAM and the speed obtained is a measure of graphics performance. This is shown by the >990 MB/second speeds in the example log. Next come 263 MB/second speed results copying from main RAM to video RAM, followed by slower speeds where the DIB was not created. Slow results at 512 MB and 256 MB are due to insufficient RAM and paging to/from disk. The size of images that can be cached depend on the graphics manufacturer, driver and, so it seems, version of Windows. Examples of fast graphics speed and size cached with WinXP are GeForce FX5900 6900 MB/sec up to 4 MB and ATI Radeon 9800 Pro 5300 MB/sec up to 32 MB. Enlarge and rotate are affected by CPU, graphics and RAM speeds with save and load, of course, mainly dependent on disk speed. The tables below include an average time for these four measurements. Other tables provide details of systems badly affected by paging. Results now include some using a Solid State Drive, where the fastest average times are obtained, using a slower processor. Looking at the statistics given with the results, they are worst case for the largest image. Performance can be reduced if the paging setting is for variable space and the setting is too low. For the example above, few other applications are using the paging file with 1106 MB occupied. The program is demanding 1043 MB RAM, as indicated by used virtual space. The results include information of systems used as indicated here (see Systems Used). The following shows the first systems that produced an average response time of 1 second for the four measurements, at different image sizes.
Surprisingly, the worst recorded performance shown here in on Athlon 64 CPUs using Windows XP x64 where, with 1 GB RAM, rotating a 256 MB image can take more than a minute and a 512 MB one 15 minutes (see Paging 2, Ath64 *). This appears to be due to excessive paging. This even affects rotating at 128 MB (see 128 MB Images Ath64 *). The benchmark was compiled to produce 64 bit code (Ath64 #) and this has the same problem but is faster than the 32 bit version on most tests. This has now been resolved following slow speed measurements with 3 GB RAM using 64-Bit Vista (See C2D3 Paging 2). The clue is the 3 in the last column of results, indicating that CreateDIBitmap is used for fast BitBlt copying. In the past, the size that could be created for fast copying varied, depending on the version of Windows and graphics driver/card. Most recent results via Windows XP showed a limit of 64 MB but with 64-Bit Windows it is available for at least 512 MB bitmaps. Tests show that the DIBs are at 32 bits, 33% larger than the original BMP data. So, a 512 MB image increases to 682 MB and the program can have two open (in addition to original data). RAM space used for the DIBs is outside the user’s virtual space. With this image size, total virtual memory demands (as seen in pagefile usage) increase from around 1100 MB to 2300 MB. Given sufficient RAM, this produces no problems and scrolling is very fast. See scrolling time at larger images for C2D3, the 4 GB PC. Further details are in Paging.htm. |
|