colors and the under-32-bit-datatype speed loss
Author
It is said that it is slower to use data types with 8 or 16 bits in a 32 bit environment (or higher) due to caching and other related memory addressing anomalies. Keeping this in mind, why wouldn't you use a 32 bit data type (DWORD or int) with all color modes, 8 bit and 16 bit too? You would just use the significant part of a variable in calculations.
Quote:Original post by warp XNo, it's due to the fact that the system word is 32 bits wide, so even using 8 bit colors requires sending 32 bits down the bus.
It is said that it is slower to use data types with 8 or 16 bits in a 32 bit environment (or higher) due to caching and other related memory addressing anomalies.
Quote:Keeping this in mind, why wouldn't you use a 32 bit data type (DWORD or int) with all color modes, 8 bit and 16 bit too?There are certain operations that are easier in 8-bit indexed palette mode, for one. There's also memory constraints: a 32-bit color image requires twice as much memory as a 16-bit image of the same dimensions.
Moved to general programming.
Whatever way you look at it, using 16-bit color means the raster(image) takes up less memory, (or the transfer of color info to the graphics card requires less I/O bandwidth).
Since reading from memory is extremely expensive (hundreds of cycles), the time it takes to extract 16-bit color info from a 32-bit (or do any 16-bit operations) word pales into insignificance.
Simply put: The advantage of using lower-precision color values is data size, which often directly translates into speed. The only significant advantage of using higher-precision color values is higher quality.
Since reading from memory is extremely expensive (hundreds of cycles), the time it takes to extract 16-bit color info from a 32-bit (or do any 16-bit operations) word pales into insignificance.
Simply put: The advantage of using lower-precision color values is data size, which often directly translates into speed. The only significant advantage of using higher-precision color values is higher quality.
If you are storing only 1 pixel, then by all means use an int for it, and it might be marginally faster. Of course if there's only 1 then there's probably no need for it to be faster.
If it's an entire bitmap or whatever with many pixels, then the amount of memory you use becomes the bottleneck. This means that 16-bit images can be operated on much faster than 32-bit ones, and 8-bit images are faster yet.
I know this is true because I have written a software-3D renderer, and bulk usage of smaller data types IS much faster. It runs up to twice as fast, depending on how little processing you're doing with each pixel. Obviously if you're effectively just doing a memcpy then it's twice as fast. If you're running a software 3D-engine somewhat like quake, then it might be 25% faster. There is a similiar speed increase when going from 16 to 8 bit, but then everything changes to being paletteised.
If it's an entire bitmap or whatever with many pixels, then the amount of memory you use becomes the bottleneck. This means that 16-bit images can be operated on much faster than 32-bit ones, and 8-bit images are faster yet.
I know this is true because I have written a software-3D renderer, and bulk usage of smaller data types IS much faster. It runs up to twice as fast, depending on how little processing you're doing with each pixel. Obviously if you're effectively just doing a memcpy then it's twice as fast. If you're running a software 3D-engine somewhat like quake, then it might be 25% faster. There is a similiar speed increase when going from 16 to 8 bit, but then everything changes to being paletteised.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
