Thread: making programms faster

*twitch twitch*

GOTO is faster, but is strongly discouraged because of its spaghettiness.

Originally Posted by deian

which is the faster way to call a set of instructions, grouping them
in a separate function(and calling her) or labeling first set instruction and using GOTO instuction from other parts of the program ?

Why would you use GOTO? If they are not called from different parts of the program, just put them in-line. (Threfore saving the time wasted by GOTO to get there and GOTO to get back.) If they are called from different parts of the program and you use GOTO to get there, how would you know where to go back to? (That's what functions do: think of the functions's return statement as GO_BACK_TO_WHERE_YOU_CAME_FROM.)

Faster: put everything inline.

[edit]
For purposes of answering homework questions: Call and return are slower than GOTO since the computer will have to execute instructions to save the context (registers, etc.) when a called function is entered and to restore the context when the "return" is executed.

[/edit]

Regards,

Dave

> http://vision.eng.shu.ac.uk/bala/c/c...imization.html
If you succeed in the first two points, most good compilers will take care of most of the rest.

Edit
http://cboard.cprogramming.com/showt...t=optimisation

Often times if you have multiple nested loops, it can be quite useful to use a goto statement to quickly jump out of them all, instead of creating a special case to break out of each one individually.

im tired of hearing all this thoughtless anti-goto stuff... i mean so many people come down on goto's just because everybody else says their bad... they don't even think about them how they can be used effectively, or consider them for any reason... they are a TOOL for solving a problem... use as needed. you don't forget you have a tool just cause it can chop you leg off... now do ya?

taught proper coding techniques they are rarely if ever necessary, that does not mean they should be completely forgotten or never be taught...

I am sillyI am sillyI am sillyI am silly that reasoning is so flawed... leads to worse problems.

I'm an assembly programmer so I understand jmps and goto's. They have no place in higher level languages. There are constructs built into those languages to specifically address the issue. All you have to do is use them.

If you really want to make your code faster then:

1. Limit the amount of function calls you make thus limiting stack frame setup overhead, and limit the number of times you jump around all over the place. A jump is not as costly as a function call since no stack frame has to be set up but a lot of jumps can be a problem. You probably won't notice at 1GHz though.

2. Limit the number of times you switch between data types. Switching between floats and integers uses quite a few cycles. It would be better to use all floats or all integers than a mixture of them. No one follows this and it's nearly impossible to do but from a pure assembly standpoint it would be faster. Check the Intel docs as to why this is true.

3. Use integer based math - yes it's still faster. Integer operations perform at one half clock cycle on Pentium 4 systems and floats take at least 1 cycle (ok so a float at 1 cycle is very good....but). Most still use floats/doubles, and I do to, but that is not to say that integers are not faster. It's just that floats and doubles are as fast as integers used to be, so no one seems to care anymore.

4. Stop using those crappy n^2 searches and loops. Two for loops are extremely slow in comparison to one for loop. The inner loop is the bottleneck. This is ok if you are not concerned about speed at that point in the program, but at a critical point you would not want to use this type of structure. So, unroll your loops into single loops and at best unroll the triple into a double. If you see a lot of nested loops, your code is going to be slow. If you want to make faster code than you are currently making then you are going to have to change the way you think about problems. There are a million solutions to a programming problem, but only a few that are the fastest. You have to change the way you code, think, and analyze.

5. Turn your compiler optimizations on. Compilers are extremely good at optimizing your code. They can suppress redundant calls (see number 1), do loop optimization, and a host of other modifications that really helps.

6. Use hand-tuned assembly code. Yes, assembly that is hand-tuned should be - 'should be' faster than compiler created assembler. It's not always the case and knowing when to optimize and when not to is a science in itself. NOT ALL hand coded assembly is faster than what the compiler spits out so don't think by adding asm to your code you are gonna just make it fly. You might actually screw it up. If you are not sure about when to use assembly or how to use it...don't. The compiler will do just fine for you.

7. This applies to graphics coding. Please, please, please, use what is available to you. It does not make sense to code something in DirectDraw when Direct3D and OpenGL are readily available to you. Your code will NEVER EVER EVER EVER be faster than the GPU so use the thing. Now it is possible with vertex and pixel shaders to throw a lot of the math at the GPU - even matrices because a texture does not have to be graphics oriented. A texture could be a matrix and yes, yes, yes you can do matrix math on the GPU. I didn't think so until I just started reading my pixel shader books.

8. Research. This is probably the biggest one of em all. Constantly look at what other people have done, why they did it, and what the results were. I've found code on the internet that claimed to be fast but in actuality crawled and creeped. Very good sources of information are hard to find because there is so much information out there. But you can normally trust what you find here:
www.gamedev.net
www.gamasutra.com
www.programmersheaven.com

Sorry but if you want to make fast code learn from the game programmers. They have to be fast or the game sucks - interactivity is the prime goal and you don't get it by writing slow crappy code. Some of the tricks they use are worth their weight in gold. If it's accuracy you are after then check out some engineering sites and code. But it's probably not the fastest code out there.

9. Get some books on the topic. This falls under research I reckon but it's very important. Read, read, read - code, code, code. Don't just trust what we say here - read it for yourself. No one out there knows it all - (except for Salem and Prelude ), so read books about the topic at hand. Comp sci books are good but make sure they are real-world oriented and not about some theory cooked up in a classroom. Classroom often never meets with the real-world. I wish it weren't true, but if you don't believe me...just look at some of the threads on this board.

I could add about 100 more steps but I won't. If it's speed that you desire and speed that you research then eventually it is speed that you will receive. If not, it is your own fault. Use the resources available to you.

And this:

Often times if you have multiple nested loops, it can be quite useful to use a goto statement to quickly jump out of them all, instead of creating a special case to break out of each one individually.

...is a sign that you are doing something terribly wrong. You should never have multiple nested loops if you care about speed in the least bit. Look at this and you can see why nested loops are slow.

Code:

for (int i=0;i<200;i++)
{
for (int j=0;j<200;j++)
{
	for (int k=0;k<200;k++)
	{
	 //do something here
	} 
}
}

As opposed to:

Code:

for (unsigned long i=0;i<(200*200*200);i++)
{
//do something here
}

The reason you see so many gotos in the linux kernel is because it is the best way to handle the way they report errors. It would become too modularized to have a function for each error they wish to report. Also, inlining everything would be too big. It also makes sense the way linux uses gotos.