The IF statement....

[Mike]

with a bit of planning, almost all IF statements can be replaced with (multiple) boolean statements.

eg.
if x = 1 then p=p+1
if x = 2 then p=p-1

can be achieved with

p=p+(x=2)-(x=1)

much faster....

Have you ever made own time measurements, or are you just repeating the urban myth of any substantial speed improvement of Boolean expressions over IF statements?





More compact? Yes, probably. *Much* faster? No.

Here, the Boolean expression is slightly faster (just 29 jiffies per 1000 evaluations!). With more complex expressions, the Boolean expression is likely to become slower than multiple-line IF statements, as the comparisons have all to be evaluated anyway, but the IF version only needs to execute one single THEN statement, whereas the Boolean expression needs to evaluate all subexpressions in full:

[groepaz]

the IF thing will get slower and slower the more basic lines come before it, the boolean expression wouldnt

[Mike]

Well, you'll need to explain that in more detail.

THEN skips the rest of the line, when the IF predicate evaluates to false. How fast that happens, doesn't depend on how many program line statements are before that IF statement.

It's clear to me, how GOTO works (it scans from the beginning of the program when jumping backwards, from the current line when jumping forwards) which means more program lines generally slow a program down - an effect which can however be minimized by clever arrangement of the involved GOTO/GOSUB jump target lines. And FOR isn't affected by this, as FOR stores the address of the loop start on stack.

[dr.geek]

no urban myth to me...just 36 years experience in BASIC programming....first noticed it when i used the technique to improves a Breakout game from a book listing in about 1985....those benchmarking tests counting jiffies are interesting, but the real evidence is in a practical application.. eg, a game with player input, game AI, etc...

[Mike]

those benchmarking tests counting jiffies are interesting

They prove you *false*, to be exact.

When your game main loops became faster, this was likely because of general optimisations like using less program lines overall, eliminating superfluous instructions, storing often used constants in 'early' variables, arranging the GOTO/GOSUB target lines for minimal search time, etc. But not by the replacement of IF statements by Boolean expressions.

[dr.geek]

those benchmarking tests counting jiffies are interesting

They prove you *false*, to be exact.

When your game main loops became faster, this was likely because of general optimisations like using less program lines overall, eliminating superfluous instructions, storing often used constants in 'early' variables, arranging the GOTO/GOSUB target lines for minimal search time, etc. But not by the replacement of IF statements by Boolean expressions.

agreed to a point ..... 7 if/thens may be faster than a 7 evaluation boolen expression....but a simple boolean expression is still tighter in the main game loop near the start of a program.....its all in the implementation

[wimoos]

Hmmm....

Rewriting in the last example as so:

S=S+INT((X+1)/2)*((XAND1)*2-1)

Results in a jiffy count of 1565...
Which goes to show that recognizing some lineair algebra may help altogether.

Regards,

Wim.

[Stormcrow]

Even if you can slightly improve program speed by converting IF statements to expression evaluations, you more than lose that benefit due to difficulty in modifying — or understanding — your code later.

[wimoos]

Even if you can slightly improve program speed by converting IF statements to expression evaluations, you more than lose that benefit due to difficulty in modifying — or understanding — your code later.

A true word. There is a proverb in IT that says: "optimizing must be done - but not now".

But when resources are limited (memory, CPU-power), sometimes it's the only thing you can do to make the most of it... In WimBasic I managed to save about 8% of the original 8 kbytes which gave me room to add another 6 commands and more and better functionality.

[Mike]

Rewriting in the last example as so:

S=S+INT((X+1)/2)*((XAND1)*2-1)

Results in a jiffy count of 1565...

[Kweepa]

speedybasic.png (8.12 KiB) Viewed 5956 times

speedierbasic.png (7.9 KiB) Viewed 5955 times

This is why Jeff always uses . for 0

[Mike]

Kweepa,

your variant doesn't improve substantially upon the crucial change: using a simple table lookup instead of (rather complicated) Boolean or otherwise hand-crafted expressions or a 'battery' of IF statements.

Also, 'inlining' the RND() statement clearly is of the rule bending variety, as it changes the timing and semantics of the test loop. It was supposed that X might be defined elsewhere in a program, and only the speed change of the summation statement 'S=S+...' between 'X=INT(RND(1)*8)+1' and 'NEXT' was intended to be tested.

You can eliminate the time incurred by the test loop by replacing the summation statement with an 'empty' assignment, i.e. "S=S". Of course the algorithm then doesn't work anymore, but when the time measured there is subtracted from the other times measured thus far, you see the real improvement by the various methods:



Boolean expression: 2369 - 668 = 1701 jiffies, base value
IF ... THEN battery: 1906 - 668 = 1238 jiffies, +37 % speed improvement
wimoos' formula: 1565 - 668 = 897 jiffies, +90% speed improvement
table lookup: 845 - 668 = 177 jiffies, +861% speed improvement (!!!)

[Kweepa]

Yes, I am a dirty cheater

[Mike]

No worries!

At least CBM BASIC is still good for some surprises, isn't it?

[dr.geek]

Great Analysis Kweepa....seems like its look-up tables for the win...no (or minimal) calculations to be performed...would integer variables add any extra saving?