Jump to content
  • Advertisement
Sign in to follow this  
PolarWolf

How to use small datatypes efficiently

This topic is 1029 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

I used to use small datatypes(short, char) to save memory,but these types will likely need two bus transaction for operations,take this union for example

 

union UValue
{
    struct
    {
         short    m_nVal1;
         short    m_nVal2;
    };
 
    int   m_nVal;
} uValue;
 
Tow bus transaction are needed to read m_nVal2 into cpu(while i am not sure if this is the case for  m_nVal1 cuz it's four bytes aligned),will this be extremely slow,is it wise to operate on m_nVal2 with some special tactics,say, set uValue.m_nVal2 to 77, do it like this
 
 uValue.m_nVal = (uValue.m_nVal & 65535)  | (77 << 16);
 
Will this way be much faster than uValue.m_nVal2 = 77 ? I am sure we all like the feeling that we coding in the best way.
 
It can be encapsulated in a member function
 
void UValue::SetVal2(int val)
{
    m_nVal = (m_nVal & 65535) | (77 << 16);
}
Edited by PolarWolf

Share this post


Link to post
Share on other sites
Advertisement
Probably not.

Getting data from memory into cache will be the bottleneck. How you access the members once they are on the CPU are unlikely to make any difference to a real-world application.

Share this post


Link to post
Share on other sites

Probably not.

Getting data from memory into cache will be the bottleneck. How you access the members once they are on the CPU are unlikely to make any difference to a real-world application.

The problem lies exactly in Getting data from memory into cache,cuz m_nVal2 is not aligned ,it will need tow bus transaction tow complete,so my qustion is will reading m_nVal  instead be much faster.

Share this post


Link to post
Share on other sites


The problem lies exactly in Getting data from memory into cache,cuz m_nVal2 is not aligned ,it will need tow bus transaction tow complete,so my qustion is will reading m_nVal  instead be much faster.

No, not at all.

 

Also m_nVal2 is properly aligned. Unions don't break alignment requirements.  They are somewhat dangerous and platform specific, so they generally shouldn't be used unless you know exactly what you are doing and why you are doing it.  

 

It doesn't make much sense to do it in this case.

Share this post


Link to post
Share on other sites

 


Excellent explanation frob,i did ignored catches. But two bus transactions may be possible if less likely,here is a snippet from this link https://msdn.microsoft.com/en-us/library/ee418650.aspx
 
Reads and writes of types that are not naturally aligned—for instance, writing DWORDs that cross four-byte boundaries—are not guaranteed to be atomic. The CPU may have to do these reads and writes as multiple bus transactions, which could allow another thread to modify or see the data in the middle of the read or write.
 

 

Share this post


Link to post
Share on other sites

There would be no reason for the compiler to break boundaries for that specific union.  There are other unions you can build that will break boundaries, but that one -- two shorts unioned with an int -- will not break any boundaries.

Share this post


Link to post
Share on other sites

Yes this quote doesn't match my example,it says cross four-byte boundaries,while my example is not four bytes aligned,sorry for that.

Btw it seems that operate on not aligned arrays on mobile platform will  crash the application.

Share this post


Link to post
Share on other sites
Some systems crash, yes. Others you incur an invisible performance penalty.

But, I hate to drag this line out, unless you have profiled a real world application and identified this as a genuine bottleneck, such optimisation is absurd.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!