I've been having this argument with the folks at TICALCS2 for a while. I keep trying to explain to them that loops are always faster, but they keep defending their claim that Goto's are faster in smaller programs. I'm thinking we should settle this debate once and for all. The evidence presented by bfr is here, and the debate started here.
Care to sum up the key points so I don't have to go rooting around in the topics?
Here's what you need to know. They were discussing how to optimize code when the issue of lbls/gotos came up. Bfr then said he tested an inifinite loop on an 86 and found that gotos are faster than while. Everyone agreed except for myself. We discussed it for a while. Bfr's strongest argument is that a while loop must check a condition and a goto does not, thus making the goto faster. I counter that claim by saying you'll have to check a condition to goto a lbl anyway if you want the code to do anything meaningful and/or end eventually. Then Bfr put his proof up on BPC.
Ummm, if it's a loop like For(X,1,200 or While 1, the processing time for the conditional is nearly immaterial.
Yeah, but the calc doesn't know where the Lbls are, so it has to find them. Loops though, it knows the location to, or it seems to, since it doesn't really have a problem with speed in large games. So While/Repeat/For( just pwned Lbl/Goto. Very Happy
tifreak8x wrote:
Yeah, but the calc doesn't know where the Lbls are, so it has to find them. Loops though, it knows the location to, or it seems to, since it doesn't really have a problem with speed in large games. So While/Repeat/For( just pwned Lbl/Goto. Very Happy
Of course, and always will in any kind of interpreted language that doesn't preprocess the label table.
tifreak8x wrote:
Loops though, it knows the location to, or it seems to, since it doesn't really have a problem with speed in large games.

You're right, the calc does know the location of loops. I believe, when it encounters a loop instruction, it pushes an entry onto the FPS giving the location of the loop, continues, then when it reaches the corresponding end command, it pops the value off the FPS and goes back to there, no searching involved. This could also explain the symptoms of code fatigue: when you goto out of a loop, it doesn't pop the entry off the FPS.
Gotos as I recall search for the corresponding label from the beginning of the prog before they jump. So If you have a label at the top of your prog, it doesn't noticeably slow down the prog, but if you're jumping from distant locations constantly throughout the prog, then you'll encounter speed problems.
http://www.ticalc.org/archives/files/fileinfo/164/16418.html

If any of you have TI-86 or emulator for the TI-86, you'll see can see that it uses Goto/Lbl for its main loop. Try to see how inefficient (in terms of memory and speed) is to put a While loop in its place. I'd be even more inefficient ot put a For loop in its place.

I'm not saying that Goto/Lbl is always better. You, something1990, are saying that While and For loops are always better, when they aren't.
Kuro wrote:
Gotos as I recall search for the corresponding label from the beginning of the prog before they jump. So If you have a label at the top of your prog, it doesn't noticeably slow down the prog, but if you're jumping from distant locations constantly throughout the prog, then you'll encounter speed problems.
It actually does make a noticeable difference imho. But yes, you are all right. that's why in most cases loops are preferable.
I know in most cases loops are preferable. I said in the argument:

"Also, on the TI-86 at leastI know to try to avoid labels and gotos; I'm a C++ programmer and learned well."

"While loops are often more useful"

By the way, this is mainly the thing that kind of sparked the argument after it seemed like it was over (it's a post at BackPocket Calc):

something1990:

Quote:

Nothing has been going on here in a while. Nothing has been going on at our Staff Board at TICALCS2, or TICALCS2 itself. Two things need to be done. First, we need to get more activity on here, both from new people and from existing members. Second, we need to move our Staff Board from TICALCS2. The more I stay there the more I dislike some of the people there. No offense, but they don't seem too smart. All that's being done there at the moment is some dumb face-off that Pure claims will be interesting. Also, in the Optimizing Code Tutorial post, they promoted the use of labels and gotos in code. They even claimed that labels/gotos are faster than loops, which is pretty dumb. It would be better if we could move our staff board somewhere else.
Ah. Indeed, I was just trying to summarize the consensus. Smile Anyone else have new point to make?
What do assembly programmers use? Wink
All "goto's" in assembly either already have the addresses that they jump to stored in them, or they know how far they should move forward or backward to get there so there is no time spent searching. BASIC's goto and ASM's jr/jp are very very different. Wink
I know. I just haaaaaaad to add that. Very Happy
Laughing I figured as much, but I wanted to add to the topic in some way. This whole discussion of Goto/Label vs. While/Repeat/For has become so hackneyed I had/have nothing to say towards that.
Exactly. To expand on Chip's point, ASM jumps use the address of the jump or the number of bytes to jump forward or back as the label reference instead of an alphanumeric symbol, so there's no virtual dereferencing occuring.
So absolute jumps and loops are somewhat similiar in that they already know the address to jump to. What's the final verdict? Are gotos faster than loops in the smaller programs, or are loops always the better choice?
Gotos are never faster than loops unless the loop uses an insanely complicated conditional statement and/or the label is extremely close to the beginning of the program.
I knew it Exclamation Also, I don't think it was accurate testing them in an infinite loop as neither Gotos nor Loops would be very useful under those conditions.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement