28 replies to this topic

[icuurd12b42]

Correct me if I'm wrong but I think some PC architecture (or programming libraries) had LUT for some math features a long time ago but I think this became obsolete when the math co-processor was faster calculating results than looking up the table...

It is certain that in the case of GM7 and higher a LUT could improve performance especially since the loss of performance from using doubles instead of singles for numbers.

[DanRedux]

Exactly what I was thinking, a sub-series of Math functions with "quick_" prepended to them.

quick_sqrt(10) is very VERY slightly faster than sqrt(10) because it uses a lookup table.

[icuurd12b42]

Exactly what I was thinking, a sub-series of Math functions with "quick_" prepended to them.

quick_sqrt(10) is very VERY slightly faster than sqrt(10) because it uses a lookup table.

It would be faster if you did not wrap it around a script, access the LUT array directly

LUTsqrt[10]

[DanRedux]

This is true. I noticed GM has absolutely no global arrays at all.. Could be cool. I only suggested a function because you could internally remove the decimal or linearly tween between the two integers around that decimal. If users have to wrap a floor() around it so that the index has no decimal place, it'll lose most of it's speed benefit.

[icuurd12b42]

globalvar LUTsqrt;

LUTsqrt[0] = 0;
LUTsqrt[1] = 1;
LUTsqrt[2] = 1.412;


But the moment you need to tweak the argument like you mentioned you may in effect cancel all benefits.

[DanRedux]

Maybe use the un-used @ symbol?

sqrt@4.5

Then the parser could know what to expect and how to handle it without the overhead of a function.

[icuurd12b42]

If we are strictly speaking of a GM implementation as proof of concept; like my previous post imply, any tweaking could cancel out the benefits, that would include

-Having the functionality in a script (somewhat)
-Having code to cap the values (mostly)
-Having to parse a string (definitely)


The interpreted nature of GML makes it so that the more code to achieve this, the slower it will be

the fastest means to the data in through an array, and GM is smart enough to accept floating points as value (no floor() needed)


So, minimally, to implement this in a safe way, you would need a script
value = 10;
x = LUTFunction(value);


//LUTFunction
//this for rotary type data like sin/cos angle
if(argument0<0) return LUTarray[argument0 mod numLUTentries + numLUTentries];
return LUTarray[argument0 mod numLUTentries];


an unsafe but fastest way would be
value = 10;
x = LUTarray[value];
but now the user needs to ensure his value is compatible; which is not a big deal when you are cautious and conscious about the danger

[DanRedux]

This is why I suggested it be a modification to the actual parser. The @ symbol is currently unused, but could be used to access LUT's quickly and understandable.

sqrt@4.5 literally means "Square Root at 4.5". The parser could detect the @ symbol and find the right-hand-side, parsing it quicker than a function and in fact quicker than an array (due to no internal map lookup).

It's semantic, could be very fast, and would add almost no space or startup time to the GM runner.

[paul23]

Actually many games do preprocessing (either during map-load or during creation of the game). For example in RTS games the map is generally floodfilled, resulting in each "island" getting it's own key.

This results in the computer being much faster when calculating paths. - It knows already that if the position keys is different no path is possible. (Making the worst case faster).

However precalculating numbers is just silly, you're thinking about micro optimizations those will never give results close to macro optimizations like using a better sorting algorithm etc etc. In GM it's even worse: not the function itself often takes time, but the parser, so the fact functions are there does take time. The gain will simply always be neglectable, and before you even think about these you have to use a profiler.