Author |
Topic: Speed test Hexadecimal vs decimal (Read 997 times) |
|
michael
Senior Member
member is offline


Posts: 335
|
 |
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 » |
Logged
|
I like making program generators and like reinventing the wheel
|
|
|
David Williams
Developer
member is offline

meh

Gender: 
Posts: 452
|
 |
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. --
|
|
|
|
michael
Senior Member
member is offline


Posts: 335
|
 |
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 » |
Logged
|
I like making program generators and like reinventing the wheel
|
|
|
KenDown
Full Member
member is offline


Posts: 181
|
 |
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

As &1 and 1 are identical, save one byte of memory and interpretation and simply say
a%+=1
|
|
Logged
|
|
|
|
michael
Senior Member
member is offline


Posts: 335
|
 |
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 » |
Logged
|
I like making program generators and like reinventing the wheel
|
|
|
KenDown
Full Member
member is offline


Posts: 181
|
 |
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.
|
|
Logged
|
|
|
|
michael
Senior Member
member is offline


Posts: 335
|
 |
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?
|
|
Logged
|
I like making program generators and like reinventing the wheel
|
|
|
David Williams
Developer
member is offline

meh

Gender: 
Posts: 452
|
 |
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. --
|
|
Logged
|
|
|
|
KenDown
Full Member
member is offline


Posts: 181
|
 |
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.
|
|
Logged
|
|
|
|
|