Quick Question

Previous topic - Next topic

kamakazieturtle

Just wondering, never really have had an official answer on this. Whats the difference between "IF" and "SELECT?" I have often wondered this, is there anything different I can do with one or the other? Also if anyone knows, is one of them faster? Thanks in advance.

Synthetic

Switches (Select in this case) are generally faster, though not by a lot, and it depends on the situation and compiler. It also can help with readability of your code. As a general rule, if you have a variable that may have 3 or more different potential results to deal with, a Select should be used. Also, a Select will only use the first matching case from the list and bypass any others that may also match so if that is an issue for what your trying to do, If statements would be the route to go.
"Impossible is a word people use to make themselves feel better when they quit."

My AMXMODX plugins for Day of Defeat 1.3 can be found here.

Synthetic

As a test, I just did a comparison of a 5 Case Select and 5 IF equivalent in a 10mil pass FOR loop, both of which gave me an average of 16.5ms completion times. ;) This could just be the way my system handles them though and testing on your target platform will be the best way to determine the route to take.

Another thing to mention is to always use the most probable match for your Cases first to least probable. This can be help reduce the amount of checks it has to do if you know a certain value will be more common then others.
"Impossible is a word people use to make themselves feel better when they quit."

My AMXMODX plugins for Day of Defeat 1.3 can be found here.

ketil

Quote from: Synthetic on 2010-Nov-15
Switches (Select in this case) are generally faster, though not by a lot, and it depends on the situation and compiler. It also can help with readability of your code. As a general rule, if you have a variable that may have 3 or more different potential results to deal with, a Select should be used. Also, a Select will only use the first matching case from the list and bypass any others that may also match so if that is an issue for what your trying to do, If statements would be the route to go.

I guess that depends on how many evaluations that is performed.
Is a jump-table (generated by switch) really faster if there's just one or two evaluations ?
A SELECT (that generates a jump-table) will in some cases be a lot faster the IF/ELSEIF (or several IF's) "if the probable positive evaluation" is not among the first few evaluations. That because all IF's will evaluated until true, and therefore an jump-table has a shorter path.

Confusing explaination ... eh ?
I'll let it be with that. It's a bit late now.

If you are going for optimised code, it will really pay of reading up on compiler construction.
Anyway ... I guess IF/SELECT is quite trivial when i comes to optimization. A good compiler should even that one out. :)
"Sugar makes the world go 'round. Caffeine makes it spin faster."

MrTAToad

SELECT always generates one or more IF statements, rather than a jump table of some sort.

ketil

Quote from: MrTAToad on 2010-Nov-15
SELECT always generates one or more IF statements, rather than a jump table of some sort.

Sorry then, my mistake.

I thought SELECT would act like the switch command in C/C++ since GLBasic do convert the basic code to C++.
Therefore my answer was related to what happens when c++ is compiled into native code.

From your answer, I guess that GLB then uses it's own templates when converting the code to c++, and not necessairily using obvious C/C++ commands.

Because in C/C++ jump-tables is generated when compiling SWITCH statements and nested IF statements whit a nesting depth of n ( n depending of compiler optimization configuration ).

Have a look at this: http://books.google.no/books?id=qug840wejVQC&pg=PA500&lpg=PA500&dq=nested+if+statements+jump-table&source=bl&ots=egUoUadMW6&sig=KRN3uROG5c97hU8CxyzpU_8FYWY&hl=no&ei=GyLhTMugBpChOqOM-dcO&sa=X&oi=book_result&ct=result&resnum=5&ved=0CEQQ6AEwBA#v=onepage&q=nested%20if%20statements%20jump-table&f=false

Then again ... I guess i should not comment such threads as this one since I really don't know anything about the GLBasic's internal working, and you obviously do. I do probably think to much in the lines of C/C++, and made the assumption that i could draw a line between GLB and C++ since GLB seem to be an preprocessor ... SORRY  :(

But optimization is a very interesting area, so i guess i will fire up the good old IDA Pro disassembler and have a look a the code behind some functionality. It might not be a very useful thing to do in this case, but it's a lot of fun :)
"Sugar makes the world go 'round. Caffeine makes it spin faster."

Kitty Hello

in GLB it's just a more conveinient way of long:
IF
ELSEIF
ELSEIF
ENDIF

blocks.

Like:
Switch a
case 3 to 5
case 6 to 9
default
endselect

MrTAToad

It would be nice if SELECT was converted to a C switch statement, but Gernot did mention why - its mainly due to expressions and the different checks.

For example :

Code (glbasic) Select
IF A%=1
ELSEIF b$="H"
ELSEIF d=1.5
ENDIF


just wouldn't be able to convert to a straight switch statement.

However :

Code (glbasic) Select
IF A%=1
ELSEIF A%=2
ELSEIF A%=3
ENDIF


could.  The problem being you would need to make sure that all expressions are of the same type and all result in a known value at compile time.  I somehow doubt Gernot would want to have the hassle of checking these sort of things at the moment.

However, using a proper switch statement, would, of course improve program speed - the problem with multiple IF's is that evaluating each one is time-consuming.

kamakazieturtle

Thanks for the help guys, I didn't exactly know how to do a proper speed test.

Quote from: Synthetic on 2010-Nov-15
Another thing to mention is to always use the most probable match for your Cases first to least probable. This can be help reduce the amount of checks it has to do if you know a certain value will be more common then others.

Indeed, sloppy code is never very efficient. Not to mention readable later on, haha.