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-1my result was binary having the highest score.
Number Type Speed
Root / Submissions / [.]
DFrostCreated:
I wondered how fast the seven different number representations were so I pieced this together:
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
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 programLiteral 1, &B1, and &H1 all compile to the same constant.
Replying to:Yolkai
What you're saying doesn't make any sense.
3.3.2:
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
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 programLiteral 1, &B1, and &H1 all compile to the same constant.
EXPLAIN THIS:
Replying to:Yolkai
What you're saying doesn't make any sense.
3.3.2:
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
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 programLiteral 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
Replying to:Yolkai
What you're saying doesn't make any sense.
3.3.2:
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
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 programLiteral 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)