Basic Operations (add, sub., muilt., etc) - Speed?
Author
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.
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.
Further, the compiler will most likely optimize any choice of operations into their fastest equivalent.
You only need to worry about this if you are writing a compiler. To answer your question though
Multiply and divide will take a tad longer than the others on most architectures (so far as I know).
These are all equivalent at the assembly level.
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!
Quote:Original post by deadimp
My 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 deadimp
Also, 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 deadimp
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)
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!
Further, fixing your algorithm so you're not iterating through pixels will yield orders of magnitude better results than any bit fiddling.
Author
Alright, I will take this into consideration.
Thanks!
Telastyn << For the bitmap algorithms, the example I meant it for was pixel-precise collision detection.
Thanks!
Telastyn << For the bitmap algorithms, the example I meant it for was pixel-precise collision detection.
Quote:Original post by deadimp
Alright, 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.
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:
EDIT: Oh, collision detection. Yeah, you shouldn't really have to iterate through everything.
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.
Author
*Confused*
Well, then again, I don't exacly have much of a knowledge base on image algorithms...
[Heh, that sounded somewhat sophisticated]
Well, then again, I don't exacly have much of a knowledge base on image algorithms...
[Heh, that sounded somewhat sophisticated]
If you want to do pixel-perfect, consider using masks and AND. If you don't get this I can clarify.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
