Sign in to follow this  

colors and the under-32-bit-datatype speed loss

This topic is 4688 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Quote:
Original post by warp X
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.
No, 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.

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4688 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this