BBC BASIC for Windows: Speed test Hexadecimal vs decimal

BBC BASIC for Windows
Programming >> BBC BASIC language >> Speed test Hexadecimal vs decimal
http://bb4w.conforums.com/index.cgi?board=language&action=display&num=1462668036

Speed test Hexadecimal vs decimal
Post by michael on May 8^th, 2016, 12:40am

Hexadecimal is 42 milliseconds faster in this program
I ran each for 1 second in profiler
2000000 is equal to &1E8480
Check this out
If you know how to make this faster let me know plz
Code:

      a%=0
      REPEAT
        a%=a%+&1
      UNTIL a%=&1E8480

Profiler report file - Sat.07 May 2016,18:27:56

File - BMP LOAD OSCOLLI.bbc

Figures in the first column indicate approximate
time in milliseconds spent in each program line.

Figures in the second column indicate approximate
percentage of the total time spent in each program line.

Initial timeout setting : 1000 milliseconds.

Time spent Profiling : 440 milliseconds.

0: a%=0
1: 0.23 REPEAT
223: 50.68 a%=a%+&1
216: 49.09 UNTIL a%=&1E8480

216: 49.09 Libraries and immediate mode

Code:

      a%=0
      REPEAT
        a%=a%+1
      UNTIL a%=2000000

Profiler report file - Sat.07 May 2016,18:32:45

File - BMP LOAD OSCOLLI.bbc

Figures in the first column indicate approximate
time in milliseconds spent in each program line.

Figures in the second column indicate approximate
percentage of the total time spent in each program line.

Initial timeout setting : 1000 milliseconds.

Time spent Profiling : 482 milliseconds.

: a%=0
1 : 0.21 REPEAT
224 : 46.47 a%=a%+1
257 : 53.32 UNTIL a%=2000000

257 : 53.32 Libraries and immediate mode
***********************************************
And assuming that maybe its the hexadecimal goal that makes it faster is wrong.. Hexadecimal is faster as a whole, but lets try it anyways
Code:

      a%=0
      REPEAT
        a%=a%+1
      UNTIL a%=&1E8480

Profiler report file - Sat.07 May 2016,18:49:35

File - BMP LOAD OSCOLLI.bbc

Figures in the first column indicate approximate
time in milliseconds spent in each program line.

Figures in the second column indicate approximate
percentage of the total time spent in each program line.

Initial timeout setting : 1000 milliseconds.

Time spent Profiling : 451 milliseconds.

:
: a%=0
1 : 0.22 REPEAT
247 : 54.77 a%=a%+1
203 : 45.01 UNTIL a%=&1E8480
:

: Libraries and immediate mode
************************************************
Lastly, but not least, a test with these type of variables
Code:

      a=0
      REPEAT
        a=a+1
      UNTIL a=2000000

Profiler report file - Sat.07 May 2016,19:09:16

File - BMP LOAD OSCOLLI.bbc

Figures in the first column indicate approximate
time in milliseconds spent in each program line.

Figures in the second column indicate approximate
percentage of the total time spent in each program line.

Initial timeout setting : 1000 milliseconds.

Time spent Profiling : 482 milliseconds.

:
: a=0
2 : 0.41 REPEAT
237 : 49.17 a=a+1
243 : 50.41 UNTIL a=2000000

: Libraries and immediate mode

Re: Speed test Hexadecimal vs decimal
Post by David Williams on May 8^th, 2016, 06:57am

on May 8^th, 2016, 12:40am, michael wrote:

Hexadecimal is 42 milliseconds faster in this program
I ran each for 1 second in profiler
2000000 is equal to &1E8480
Check this out
If you know how to make this faster let me know plz
Code:

      a%=0
      REPEAT
        a%=a%+&1
      UNTIL a%=&1E8480

Two ideas:

1) Use BB4W's resident 'static' integer variables - all upper case, single-letter variable names from A% up to Z%.

2) Replace a%=a%+&1 with a%+=&1
(or if using A% instead of a%, then A%+=&1)

So now we have:

Code:

A%=0
REPEAT
A%+=&1
UNTIL A%=&1E8480

That should be slightly faster (I don't have BB4W installed on this machine, so I can't test it myself).

There's one little trick you can employ in this specific case which might give you a tiny speed boost: replace A%+=&1 with A%-=TRUE. Can you see how it works? I think any performance gain probably isn't worth the apparent obfuscation it leads to!

Putting the REPEAT loop onto one line might speed things up further (by a negligible amount):

Code:

REPEAT A%+=&1 UNTIL A%=&1E8480

Not something to be encouraged in general (in proper programs) as it's less readable than using separate lines for each statement.

David.
--

Re: Speed test Hexadecimal vs decimal
Post by michael on May 11^th, 2016, 12:55am

Ok after lots of digging and research I made this solution:
Now I need to find a way to quickly deal with graphics.
Perhaps controlling a pointer or say, sprites in some manner. But if I transfer the video into a large register, then I could manipulate the draws directly.
I am researching that information directly from NASM dev contributors links.
This is a step towards something.. Its a lot of research
Quote:

AH = 0Ch
BH = page number
AL = pixel color
if bit 7 set, value is XOR'ed onto screen except in 256-color modes
CX = column
DX = row

Return:
Nothing

Desc: Set a single pixel on the display in graphics modes

Notes: Valid only in graphics modes. BH is ignored if the current video mode supports only one page
This program is pretty well instant.. It is lightning fast
Code:

     
 PRINT "Please wait for increment to 2 million"
      PROCassemble
      bcd%=2000000
      bin%=0
      REM REPEAT
      CALL bin2bcd
      REM UNTIL bin%=2000000
      PRINT bin%
      PRINT "DONE"
      END

      DEF PROCassemble
      LOCAL P%, L%, gap%
      DIM gap% &7FF, P% &7FF, L% &7FF
      [OPT 10
      .bin2bcd
      mov eax,[^bin%]
      mov ebx,[^bcd%]
      .loop
      inc eax
      cmp eax,ebx
      jle loop
      mov [^bin%],eax
      ret
      ]
      ENDPROC

Re: Speed test Hexadecimal vs decimal
Post by KenDown on Nov 27^th, 2016, 5:28pm

Er - why on earth is anyone using

a%=a%+&1

or even

a%+=&1
huh

As &1 and 1 are identical, save one byte of memory and interpretation and simply say

a%+=1

Re: Speed test Hexadecimal vs decimal
Post by michael on Nov 27^th, 2016, 9:50pm

Um.. I think hexadecimal is always faster?

Look at the first post. It has a comparison.. I did this a while back
Using hexadecimal is 40 milliseconds faster
But your biggest speed loss is from plotting on screen
.. so its best to keep efficient draws and the such

But that doesn't mean I will go out of my way to use hexadecimal..
I think even with assembly language, using RETURN with a variable could increase the speed of elaborate creations. Although I haven't tried this yet.

Re: Speed test Hexadecimal vs decimal
Post by KenDown on Nov 28^th, 2016, 07:52am

Hmmmm. Curioser and curioser.

TIME=0
a%=0
FORi%=1TO100000000:a%+=1:NEXT
PRINTTIME

TIME=0
a%=0
FORi%=1TO100000000:a%+=&1:NEXT
PRINTTIME

TIME=0
a%=0
FORi%=1TO&5F5E100:a%+=&1:NEXT
PRINTTIME

TIME=0
a%=0
REPEAT:a%+=1:UNTILa%=100000000
PRINTTIME

TIME=0
a%=0
REPEAT:a%+=&1:UNTILa%=100000000
PRINTTIME

TIME=0
a%=0
REPEAT:a%+=&1:UNTILa%=&5F5E100
PRINTTIME

Produced the following times:

1003
960
974
2276
2207
1863

A REPEAT:UNTIL loop is almost twice as slow as a FOR:NEXT loop. Giving the end point in hex is slower with the FOR and faster with the REPEAT.

Using a WHILE:ENDWHILE loop three times in the same order gave

2257
2225
1940

I presume that both REPEAT and WHILE do a comparison on each iteration, whereas FOR knows the endpoint, so to speak.

Very interesting - and thanks for pointing it out.

Re: Speed test Hexadecimal vs decimal
Post by michael on Nov 28^th, 2016, 07:58am

That is very interesting! Thanks for showing that comparison. Who would have known?

Re: Speed test Hexadecimal vs decimal
Post by David Williams on Nov 28^th, 2016, 08:51am

BB4W's resident static integer variables (A%, B%, C%, ..., Z%) are accessed more quickly than ordinary integers (a%, b%, c%, etc.).

The reason why hexadecimal constants tend to be 'processed' faster than decimal integers is because BB4W can convert them to binary a little quicker.

Incidentally, a slightly faster way of incrementing a variable by 1 is to substitute e.g. A%+=1 with A%-=TRUE. Or if decrementing, substitute A%-=1 with A%+=TRUE.

Also, omitting the colons in the one-line statement

Code:

FOR I%=1 TO 10000000:A%-=TRUE:NEXT

seems to lead to slightly faster execution.

So for ultimate speed (in BASIC), try the following:

Code:

        TIME=0
        A%=0
        FORI%=1TO100000000 A%-=TRUE NEXT
        PRINTTIME

Notice this discussion hasn't considered the impact of BB4W's REM!Faster compiler directive.

David.
--

Re: Speed test Hexadecimal vs decimal
Post by KenDown on Nov 28^th, 2016, 10:01am

Good gracious! I didn't know one could omit the colons. Mind you, I think I'll keep them in. My computer isn't the only one who needs to read my code (I do!) and none of my programs are that time critical.