It is important to set the % in FUNCTIONS for performance?

[Dark Schneider]

If not set the %, is the FPU used in any way, affecting the performance or not?
example:

Code (glbasic) Select Expand


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()

[Kitty Hello]

% returns 4 byte, and # returns 8 bytes on windows. Nothing you really trouble about.

[Schranz0r]

You have to write :

Code (glbasic) Select Expand

FUNCTION MyFunc%:

    RETURN var%

ENDFUNCTION

Its good to safe performance on Wiz and other handhelds

[Dark Schneider]

You have to write :

Code (glbasic) Select Expand

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:

Code (glbasic) Select Expand


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.

[MrTAToad]

If I remember correctly, DGInt is floating point values and DGNat is an integer

[Wampus]

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. 

[hardyx]

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.

[Dark Schneider]

But 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.

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).

And that is the real problem I think, because the typical use is:

Code (glbasic) Select Expand

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:

Code (glbasic) Select Expand


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:

Code (glbasic) Select Expand


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.

32bit and 64bit numbers on my PC and iPod

On iPod FP are 32-bit sized.

[Kitty Hello]

Converting integers to float and vice versa might be expensive!

[BdR]

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..

Code (glbasic) Select Expand


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?

Code (glbasic) Select Expand


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

[Kitty Hello]

Only the declaration is required.