BBC BASIC for Windows
« Speed test Hexadecimal vs decimal »

Welcome Guest. Please Login or Register.
Apr 5th, 2018, 9:53pm



ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018.
Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.

If you require a dump of the post on your message board, please come to the support board and request it.


Thank you Conforums members.

BBC BASIC for Windows Resources
Online BBC BASIC for Windows documentation
BBC BASIC for Windows Beginners' Tutorial
BBC BASIC Home Page
BBC BASIC on Rosetta Code
BBC BASIC discussion group
BBC BASIC for Windows Programmers' Reference

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Speed test Hexadecimal vs decimal  (Read 997 times)
michael
Senior Member
ImageImageImageImage


member is offline

Avatar




PM


Posts: 335
xx Speed test Hexadecimal vs decimal
« Thread started on: May 8th, 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




« Last Edit: May 8th, 2016, 01:24am by michael » User IP Logged

I like making program generators and like reinventing the wheel
David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: Speed test Hexadecimal vs decimal
« Reply #1 on: May 8th, 2016, 06:57am »

on May 8th, 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.
--
« Last Edit: May 8th, 2016, 07:09am by David Williams » User IP Logged

michael
Senior Member
ImageImageImageImage


member is offline

Avatar




PM


Posts: 335
xx Re: Speed test Hexadecimal vs decimal
« Reply #2 on: May 11th, 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
 
« Last Edit: May 11th, 2016, 01:34am by michael » User IP Logged

I like making program generators and like reinventing the wheel
KenDown
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 181
xx Re: Speed test Hexadecimal vs decimal
« Reply #3 on: Nov 27th, 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
User IP Logged

michael
Senior Member
ImageImageImageImage


member is offline

Avatar




PM


Posts: 335
xx Re: Speed test Hexadecimal vs decimal
« Reply #4 on: Nov 27th, 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.
« Last Edit: Nov 28th, 2016, 05:13am by michael » User IP Logged

I like making program generators and like reinventing the wheel
KenDown
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 181
xx Re: Speed test Hexadecimal vs decimal
« Reply #5 on: Nov 28th, 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.
User IP Logged

michael
Senior Member
ImageImageImageImage


member is offline

Avatar




PM


Posts: 335
smiley Re: Speed test Hexadecimal vs decimal
« Reply #6 on: Nov 28th, 2016, 07:58am »

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

I like making program generators and like reinventing the wheel
David Williams
Developer

member is offline

Avatar

meh


PM

Gender: Male
Posts: 452
xx Re: Speed test Hexadecimal vs decimal
« Reply #7 on: Nov 28th, 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.
--






User IP Logged

KenDown
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 181
xx Re: Speed test Hexadecimal vs decimal
« Reply #8 on: Nov 28th, 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.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

| |

This forum powered for FREE by Conforums ©
Terms of Service | Privacy Policy | Conforums Support | Parental Controls