LoginLogin
Might make SBS readonly: thread

Number Type Speed

Root / Submissions / [.]

DFrostCreated:
I wondered how fast the seven different number representations were so I pieced this together:
VAR M%,CONSTANT%,INT%,REAL%,LITERAL%,BIN%,HEX%,SCI%,TESTINT% = 1,TESTREAL# = 1
M% = MILLISEC
DEF VOID X END'used to access variables but don't do anything with them
WHILE MILLISEC-M%<1001
 VOID #TRUE
 INC CONSTANT
WEND
M% = MILLISEC
WHILE MILLISEC - M% <1001
 VOID TESTINT%
 INC INT%
WEND
M% = MILLISEC
WHILE MILLISEC - M%< 1001
 VOID TESTREAL#
 INC REAL%
WEND
M% = MILLISEC
WHILE MILLISEC-M%<1001
 VOID 1
 INC LITERAL%
WEND
M% = MILLISEC
WHILE MILLISEC-M%<1001
 VOID &B1
 INC BIN%
WEND
M% = MILLISEC
WHILE MILLISEC-M%<1001
 VOID &H1
 INC HEX%
WEND
M% = MILLISEC
WHILE MILLISEC - M%<1001
 VOID 10E-1
 INC SCI%
WEND
PRINT HEX%'like &H1
PRINT BIN%'like &B1
PRINT LITERAL%'like 1
PRINT REAL%'like X#
PRINT INT%'like X%
PRINT CONSTANT%'like #TRUE
PRINT SCI%'like 10E-1
my result was binary having the highest score.

*clap clap*

-_- what does that mean?

source
VAR TESTINT% = 1,TESTREAL# = 1
DEF VOID X END
VAR B=&HDEADBEEF 'for separating assignment and calls
VOID #TRUE
VOID TESTINT%
VOID TESTREAL#
VOID 1
VOID &B1
VOID &H1
VOID 10E-1
raw
0x2fffa6:       0x30010000      0xff940001      0xb001004f      0xff840001
0x2fffb6:       0x941c004f      0x002fffc0      0xb401802c      0xdeadbeef
0x2fffc6:       0x004fee48      0x00017001      0xee589425      0x0001004f
0x2fffd6:       0xff946000      0x9425004f      0x004fee58      0x60000001
0x2fffe6:       0x004fff84      0xee589425      0x0001004f      0x00017001
0x2ffff6:       0xee589425      0x0001004f      0x00017001      0xee589425
0x300006:       0x0001004f      0x00017001      0xee589425      0x0001004f
0x300016:       0x00007801      0x00000000      0x94253ff0      0x004fee58
0x300026:       0x00300001
What you're saying doesn't make any sense. 3.3.2:
3001 0001 ff94                          ; assign 1 to TESTINT%
004f b001 0001 ff84                     ;assign 1.0 to TESTREAL#
004f 941c ffc0 002f 802c b401 beef dead ;assign 0xDEADBEEF to B

ee48 004f 0001 7001 9425           'call VOID(1) with ??
ee58 004f 0001 6000 ff94 004f 9425 'call VOID(1) with TESTINT%
ee58 004f 0001 6000 ff84 004f 9425 'call VOID(1) with TESTREAL#
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7801 0000 0000 0000 3ff0 9425 'push real<1.0> to the stack and call VOID(1)
ee58 004f 0001 'questionable
0030 'end of program
Literal 1, &B1, and &H1 all compile to the same constant.

Replying to:Yolkai
source
VAR TESTINT% = 1,TESTREAL# = 1
DEF VOID X END
VAR B=&HDEADBEEF 'for separating assignment and calls
VOID #TRUE
VOID TESTINT%
VOID TESTREAL#
VOID 1
VOID &B1
VOID &H1
VOID 10E-1
raw
0x2fffa6:       0x30010000      0xff940001      0xb001004f      0xff840001
0x2fffb6:       0x941c004f      0x002fffc0      0xb401802c      0xdeadbeef
0x2fffc6:       0x004fee48      0x00017001      0xee589425      0x0001004f
0x2fffd6:       0xff946000      0x9425004f      0x004fee58      0x60000001
0x2fffe6:       0x004fff84      0xee589425      0x0001004f      0x00017001
0x2ffff6:       0xee589425      0x0001004f      0x00017001      0xee589425
0x300006:       0x0001004f      0x00017001      0xee589425      0x0001004f
0x300016:       0x00007801      0x00000000      0x94253ff0      0x004fee58
0x300026:       0x00300001
What you're saying doesn't make any sense. 3.3.2:
3001 0001 ff94                          ; assign 1 to TESTINT%
004f b001 0001 ff84                     ;assign 1.0 to TESTREAL#
004f 941c ffc0 002f 802c b401 beef dead ;assign 0xDEADBEEF to B

ee48 004f 0001 7001 9425           'call VOID(1) with ??
ee58 004f 0001 6000 ff94 004f 9425 'call VOID(1) with TESTINT%
ee58 004f 0001 6000 ff84 004f 9425 'call VOID(1) with TESTREAL#
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7801 0000 0000 0000 3ff0 9425 'push real<1.0> to the stack and call VOID(1)
ee58 004f 0001 'questionable
0030 'end of program
Literal 1, &B1, and &H1 all compile to the same constant.
EXPLAIN THIS:

MEME REVIEW ๐Ÿ‘๐Ÿ‘ skratta du fรถrlorar du

Replying to:Yolkai
source
VAR TESTINT% = 1,TESTREAL# = 1
DEF VOID X END
VAR B=&HDEADBEEF 'for separating assignment and calls
VOID #TRUE
VOID TESTINT%
VOID TESTREAL#
VOID 1
VOID &B1
VOID &H1
VOID 10E-1
raw
0x2fffa6:       0x30010000      0xff940001      0xb001004f      0xff840001
0x2fffb6:       0x941c004f      0x002fffc0      0xb401802c      0xdeadbeef
0x2fffc6:       0x004fee48      0x00017001      0xee589425      0x0001004f
0x2fffd6:       0xff946000      0x9425004f      0x004fee58      0x60000001
0x2fffe6:       0x004fff84      0xee589425      0x0001004f      0x00017001
0x2ffff6:       0xee589425      0x0001004f      0x00017001      0xee589425
0x300006:       0x0001004f      0x00017001      0xee589425      0x0001004f
0x300016:       0x00007801      0x00000000      0x94253ff0      0x004fee58
0x300026:       0x00300001
What you're saying doesn't make any sense. 3.3.2:
3001 0001 ff94                          ; assign 1 to TESTINT%
004f b001 0001 ff84                     ;assign 1.0 to TESTREAL#
004f 941c ffc0 002f 802c b401 beef dead ;assign 0xDEADBEEF to B

ee48 004f 0001 7001 9425           'call VOID(1) with ??
ee58 004f 0001 6000 ff94 004f 9425 'call VOID(1) with TESTINT%
ee58 004f 0001 6000 ff84 004f 9425 'call VOID(1) with TESTREAL#
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7801 0000 0000 0000 3ff0 9425 'push real<1.0> to the stack and call VOID(1)
ee58 004f 0001 'questionable
0030 'end of program
Literal 1, &B1, and &H1 all compile to the same constant.
idk what you're showing me edit: here's what I get running the code in the post (with the print order and type suffixes fixed) +/- 3 milliseconds not counting the first one (#TRUE) which is +/- 30 milliseconds

I was clapping, obviously. It means good job.

Replying to:Yolkai
source
VAR TESTINT% = 1,TESTREAL# = 1
DEF VOID X END
VAR B=&HDEADBEEF 'for separating assignment and calls
VOID #TRUE
VOID TESTINT%
VOID TESTREAL#
VOID 1
VOID &B1
VOID &H1
VOID 10E-1
raw
0x2fffa6:       0x30010000      0xff940001      0xb001004f      0xff840001
0x2fffb6:       0x941c004f      0x002fffc0      0xb401802c      0xdeadbeef
0x2fffc6:       0x004fee48      0x00017001      0xee589425      0x0001004f
0x2fffd6:       0xff946000      0x9425004f      0x004fee58      0x60000001
0x2fffe6:       0x004fff84      0xee589425      0x0001004f      0x00017001
0x2ffff6:       0xee589425      0x0001004f      0x00017001      0xee589425
0x300006:       0x0001004f      0x00017001      0xee589425      0x0001004f
0x300016:       0x00007801      0x00000000      0x94253ff0      0x004fee58
0x300026:       0x00300001
What you're saying doesn't make any sense. 3.3.2:
3001 0001 ff94                          ; assign 1 to TESTINT%
004f b001 0001 ff84                     ;assign 1.0 to TESTREAL#
004f 941c ffc0 002f 802c b401 beef dead ;assign 0xDEADBEEF to B

ee48 004f 0001 7001 9425           'call VOID(1) with ??
ee58 004f 0001 6000 ff94 004f 9425 'call VOID(1) with TESTINT%
ee58 004f 0001 6000 ff84 004f 9425 'call VOID(1) with TESTREAL#
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7001 0001 9425      'push int<1> to the stack and call VOID(1)
ee58 004f 0001 7801 0000 0000 0000 3ff0 9425 'push real<1.0> to the stack and call VOID(1)
ee58 004f 0001 'questionable
0030 'end of program
Literal 1, &B1, and &H1 all compile to the same constant.
well, that graph shows their values compared to the max I don't know why these results are on my DS. I'm not doubting you.

I've written essentially the same code looped 100 times in a routine whereupon ending it calculated the arithmetic mean of each counter. I ran this while I ate breakfast, here are my results: Integer - 176445 Floating-point - 177165 String - 171828 Binary - 180373 Hexadecimal - 180545 Standard Index - 174469 Constant (#TRUE) - 180630 Literal Integer - 180438 Literal String - 176340 I suppose I neglected a literal floating-point test case. There seems to be some variation between each type, exactly what it means or if it means anything at all is up for speculation I guess.

Replying to:MZ952
I've written essentially the same code looped 100 times in a routine whereupon ending it calculated the arithmetic mean of each counter. I ran this while I ate breakfast, here are my results: Integer - 176445 Floating-point - 177165 String - 171828 Binary - 180373 Hexadecimal - 180545 Standard Index - 174469 Constant (#TRUE) - 180630 Literal Integer - 180438 Literal String - 176340 I suppose I neglected a literal floating-point test case. There seems to be some variation between each type, exactly what it means or if it means anything at all is up for speculation I guess.
according to these results:
  • binary literal, hex literal, constant, and integer literal have negligible difference here (because they're the same)
  • String variables have some overhead more than other variable types
  • Literal strings are a little faster than string variables (when passing to a function) but slower than other literals (they're stored as a length followed by the sequence, i.e. have to be interpreted more than just the push instruction)
  • I assume "Standard Index" means indexing into an array A%[i]. Array access has an obvious overhead. Correction: real numbers are slower than integers, obviously. Scientific notation compiles to real type always(?).
  • integer and floating point variable access times are probably the same

Replying to:MZ952
I've written essentially the same code looped 100 times in a routine whereupon ending it calculated the arithmetic mean of each counter. I ran this while I ate breakfast, here are my results: Integer - 176445 Floating-point - 177165 String - 171828 Binary - 180373 Hexadecimal - 180545 Standard Index - 174469 Constant (#TRUE) - 180630 Literal Integer - 180438 Literal String - 176340 I suppose I neglected a literal floating-point test case. There seems to be some variation between each type, exactly what it means or if it means anything at all is up for speculation I guess.
I'm sorry, standard index means standard form or scientific notation, e.g., 1E7.

Replying to:MZ952
I've written essentially the same code looped 100 times in a routine whereupon ending it calculated the arithmetic mean of each counter. I ran this while I ate breakfast, here are my results: Integer - 176445 Floating-point - 177165 String - 171828 Binary - 180373 Hexadecimal - 180545 Standard Index - 174469 Constant (#TRUE) - 180630 Literal Integer - 180438 Literal String - 176340 I suppose I neglected a literal floating-point test case. There seems to be some variation between each type, exactly what it means or if it means anything at all is up for speculation I guess.
I've heard that the speed difference between ints and floats is bigger on the o3DS. EDIT: yes scientific notation is always real type. (Can be tested using TYPEOF)