Public Group

# Basic Operations (add, sub., muilt., etc) - Speed?

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

## Recommended Posts

I remember on a reply to a post I made, where I was asking whether I should use one logical operator or another one for speed, it said that I needn't worry since the speed was about equal (don't remember the exact words). My main question is: Are there any differences in speed between the basic functions, add, multiply, divide, bitiwise ops, logical ops, etc? Also, would there be any speed difference between things such as "a=a+1", "a+=1", and "a++"? Examples: > If I were to iterate through the pixels of a section in a bitmap, should I just use some simple multiplications to find where the pixel is ("ptr=start+(x+y*width)"), or would I want to try and use addition more? > Is there any difference for checking if a number (32-bit int) is odd: > > if (x % 2 == 1) > > if (x % 2 > 0) > > if ((x & 1) == 1) > > if ((x & 1) > 0) Please bear with me on this.

##### Share on other sites
This would fall under the realm of premature optimization. Chances are any difference in times between your operators will be overshadowed by the relative efficiency of the algorithm you choose to implement.

Further, the compiler will most likely optimize any choice of operations into their fastest equivalent.

##### Share on other sites
Bit shifting on some processors takes longer than multiplying simple numbers.

##### Share on other sites

Quote:
 Original post by deadimpMy main question is: Are there any differences in speed between the basic functions, add, multiply, divide, bitiwise ops, logical ops, etc?

Multiply and divide will take a tad longer than the others on most architectures (so far as I know).

Quote:
 Original post by deadimpAlso, would there be any speed difference between things such as "a=a+1", "a+=1", and "a++"?

These are all equivalent at the assembly level.

Quote:
 Original post by deadimpIs there any difference for checking if a number (32-bit int) is odd:> > if (x % 2 == 1)> > if (x % 2 > 0)> > if ((x & 1) == 1)> > if ((x & 1) > 0)

The second two will probably be a little faster (but the compiler will most likely change your code).

The only reason I studied any of this was for a class. Serioulsy, if I were you I would not bother at this low of a level. Also as M2TM pointed out, it is all dependant on the processor. Compiler writers will optimize your code for their processor.

Good Luck!

##### Share on other sites
Further, fixing your algorithm so you're not iterating through pixels will yield orders of magnitude better results than any bit fiddling.

##### Share on other sites
Alright, I will take this into consideration.
Thanks!

Telastyn << For the bitmap algorithms, the example I meant it for was pixel-precise collision detection.

##### Share on other sites
Quote:
 Original post by deadimpAlright, I will take this into consideration.Thanks!Telastyn << For the bitmap algorithms, the example I meant it for was pixel-precise collision detection.

Quote:
 Further, fixing your algorithm so you're not iterating through pixels will yield orders of magnitude better results than any bit fiddling.

##### Share on other sites
Do you have any idea how fast your computer is? The 1 optimisation I would consider is to iterate through your bitmap the way it lies in memory to make sure everything stays in the cache.

Judging by what you've shown, you should have y on the outer loop like this:
for (int y = 0; y < height; y++)   for (int x = 0; x < width; x++)

EDIT: Oh, collision detection. Yeah, you shouldn't really have to iterate through everything.

##### Share on other sites
*Confused*
Well, then again, I don't exacly have much of a knowledge base on image algorithms...

[Heh, that sounded somewhat sophisticated]

##### Share on other sites
If you want to do pixel-perfect, consider using masks and AND. If you don't get this I can clarify.

• 10
• 17
• 9
• 13
• 41