Thread: making programms faster

  1. #1
    Registered User
    Join Date
    May 2004
    Posts
    20

    making programms faster

    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 ?

  2. #2
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,218
    *twitch twitch*

    GOTO is faster, but is strongly discouraged because of its spaghettiness.
    If you understand what you're doing, you're not learning anything.

  3. #3
    Registered User
    Join Date
    May 2004
    Posts
    20
    it looks like assembly code,isn't?

  4. #4
    Registered User
    Join Date
    Mar 2004
    Posts
    536
    Quote 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
    Last edited by Dave Evans; 10-07-2004 at 12:44 PM.

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    ---
    Join Date
    May 2004
    Posts
    1,379
    Quote Originally Posted by deian
    it looks like assembly code,isn't?
    assembly does use labels but it is a very primitive language. but it also uses procedures which are similar to functions. but when it comes to c, never use goto

  7. #7
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    never use goto
    goto has its places in C. Just look at the source code to linux, and count the number of times you see a goto statement. I think you'd be surprised.

  8. #8
    Registered User
    Join Date
    Sep 2001
    Posts
    4,912
    I wrote a small console game once where it was in one spot, absolutely necessary to use goto. It's usually frowned upon to the point that people are afraid to use it, which is sad. It has it's place, and it's not very common, but goto is not an inherently 'bad' thing.

  9. #9
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    You guys are insane. Never use goto. You mean to tell me that with everything that is available in C++ and C all you can do is resort to a goto as your solution.

    Gimme a break.

  10. #10
    C++ Developer XSquared's Avatar
    Join Date
    Jun 2002
    Location
    Ontario, Canada
    Posts
    2,718
    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.
    Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah

    You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie

  11. #11
    Has a Masters in B.S.
    Join Date
    Aug 2001
    Posts
    2,263
    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.
    ADVISORY: This users posts are rated CP-MA, for Mature Audiences only.

  12. #12
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    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
    }
    Last edited by VirtualAce; 10-07-2004 at 08:44 PM.

  13. #13
    Obsessed with C chrismiceli's Avatar
    Join Date
    Jan 2003
    Posts
    501
    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.
    Help populate a c/c++ help irc channel
    server: irc://irc.efnet.net
    channel: #c

  14. #14
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    >> ...thoughtless anti-goto stuff...
    It almost makes you mad enough to slam your fist right on your knee....

    I concur with no-one.

    gg

  15. #15
    Registered User
    Join Date
    Jun 2004
    Posts
    722
    Quote Originally Posted by sand_man
    assembly does use labels but it is a very primitive language. but it also uses procedures which are similar to functions. but when it comes to c, never use goto
    Correction: assembly IS the BASE language. Try thinking like a CPU

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Java is 1000 times faster than c++ on my computer???
    By darin722 in forum C++ Programming
    Replies: 16
    Last Post: 06-13-2009, 12:48 AM
  2. Faster bitwise operator
    By Yarin in forum C++ Programming
    Replies: 18
    Last Post: 04-29-2009, 01:56 PM
  3. which among the following two for loops is faster?
    By vapanchamukhi in forum C Programming
    Replies: 11
    Last Post: 02-12-2009, 03:32 AM
  4. Replies: 2
    Last Post: 11-26-2001, 04:05 PM
  5. Floating point faster than fixed-point
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 11-08-2001, 11:34 PM