If not set the %, is the FPU used in any way, affecting the performance or not?
example:
FUNCTION MyFunc:
LOCAL result%
...
return result
endfunction
We return an integer but we have not set the % on the function, is the value changed to FP?.
What about if we return nothing?
On PC this is not noticeable, but this can be important on devices, where we have only a shared vector unit for FP computing and its power is very limited. Especially when we have function that are called many times per franme, like TYPES.Update()
% returns 4 byte, and # returns 8 bytes on windows. Nothing you really trouble about.
You have to write :
FUNCTION MyFunc%:
RETURN var%
ENDFUNCTION
Its good to safe performance on Wiz and other handhelds
Quote from: Schranz0r on 2011-Jan-17
You have to write :
FUNCTION MyFunc%:
RETURN var%
ENDFUNCTION
Its good to safe performance on Wiz and other handhelds
That is what I'd want to know, on devices, thanks.
I have seen the temps.h and I found this:
DGInt DrawLayout(DGNat game_mode, DGNat world_selected, DGArray<TWorldInfo>& worlds_info, DGArray<TStagesInfo>& stages_info);
DGInt LoadStageMedia(DGStr dirname_Str, DGNatArray& sprites);
DGInt LoadContentMainScreen(DGNatArray& sprites);
DGInt UnloadContentMainScreen(DGNatArray& sprites);
DGInt ShowLoadScreen();
DGInt SetSoundMute();
If I am not wrong, DGInt are floating point, so the % should be used, if not there can be device's vector unit that can decrease performance.
If I remember correctly, DGInt is floating point values and DGNat is an integer
I've done some speed comparisons of 32bit and 64bit numbers on my PC and iPod in the past. What I found was that working with 32bit and 64bit arrays or variables was pretty much equivalent in speed for most things, so long as you stick to working with 32bit or 64bit numbers all the time. If you do things like assign a 32bit array or variable to a 64bit array or variable or do a calculation that mixes the two number types together then expect things to be a little slower (probably because some numbers have to go through a conversion).
Test it yourself too because I'm recalling the difference from memory. It was months ago that I tried this. Also it might well be different for things like the GP2X.
On a somewhat related note I've found that something like array1 = ASL(bXOR(value1, 4353621), 24) is as fast as array1 = value1 when working with 32bit numbers on the PC and iPod. So, if you really wanted to reduce memory usage you could use a 32bit integer to store 4 8bit numbers or 2 16bit numbers :) I did this to my Line of Sight algorithm yesterday and it works great. Although...it does make for complicated code that is very confusing to read. :-[
But iPhone and iPod Touch has a cpu with a VFP (vector floating point) unit, and some systems like GP2X, some PPC or Wiz don't have this. If you work with floating point numbers in a integer cpu, they are emulated by software and they are very slooooow.
QuoteBut iPhone and iPod Touch has a cpu with a VFP (vector floating point) unit
But it is shared, it is used for computing the vectors too, while the ALU (for integers) is totally free to be used only for integer and logic computing. So using integer in all places you can increase at less a bit the speed on any device.
QuoteIf you do things like assign a 32bit array or variable to a 64bit array or variable or do a calculation that mixes the two number types together then expect things to be a little slower (probably because some numbers have to go through a conversion).
And that is the real problem I think, because the typical use is:
var%=MyFunc()and things like that, where var is expected to store a memory pointer (integer), or a boolean, and then we will have I think about 80% of conversion inadvertently.
And more because, in the function, we usually can have something like:
FUNCTION MyFunc:
...
RETURN TRUE
ENDFUNCTION
That TRUE is converted to FP, and the when assign to
var% is converted again to INTEGER. To avoid conversion in the function itself, we should do something like:
FUNCTION MyFunc:
...
RETURN 1.0
ENDFUNCTION
That is not much typical because we are not used to do that. So to avoid problems, it is better to set the
% by default unless you are sure that want to return a FP value.
Quote32bit and 64bit numbers on my PC and iPod
On iPod FP are 32-bit sized.
Converting integers to float and vice versa might be expensive!
I still have one question: do you have to repeat the data type operators (% or # or $) after the variables or function have been declared with an explicit datatype?
So for example, does this code..
GLOBAL myvalue% // <- declarations
// also use DGNat (%) operators after declaration
myvalue% = DoSomething%(12, 34)
FUNCTION DoSomething%: x%, y% // <- declarations
LOCAL i% // <- declaration
// also here, repeat % operator
i% = (x% * y%)
RETURN i%
ENDFUNCTION
..do the exact same as this code?
GLOBAL myvalue% // <- declarations
// already declared as DGNat (%) so no need to repeat(?)
myvalue = DoSomething(12, 34)
FUNCTION DoSomething%: x%, y% // <- declarations
LOCAL i% // <- declaration
// also here, do not repeat % operator
i = (x * y)
RETURN i
ENDFUNCTION
Only the declaration is required.