Rather than a tutorial, these are just a few pieces of advice I've stumbled upon while coding the attached array performance example. This is probably something that the more seasoned GLBasic coders know, but newbies such as myself might find useful.
Dimensioning arrays:
- Linear (1D) arrays are the fastest to use
- It is slightly faster to use 2D arrays than simulating them through 1D arrays
- It is considerably faster to simulate 3D or 4D arrays through 1D arrays than using real 3D or 4D arrays
Traversing arrays:
- Traversing arrays linearly is the fastest way to work
- To traverse both real multidimensional and simulated arrays the fastest way, nestle the dimension loops from highest to lowest dimension (as seen in the attached example)
- Integer indexes (eg. i%) are faster to use than float indexes (eg. i#, i)
Additions are very much welcomed.
The result of the test in my own computer is attached as well.
[attachment deleted by admin]
strange, it crashes as I press f5
Quote from: erico on 2011-Nov-02
strange, it crashes as I press f5
Same here :blink:
Ahh, got it to work. Had to create a new project then paste/include the code in it then worked fine =D
Are you guys just trying to compile the code straight from the GBAS file? It will crash if you do that. Open a new or old test project and paste the code into it.
Anyway, those are interesting results. Thanks for testing. I guess it may be worth simulating multidimensional arrays unless it starts to make your code harder to understand. I heard some great advice in a lecture by the creator of Braid. To paraphrase it, "Given the time restraints and the relative benefits of code optimisation for indie games you should only really optimise for getting things done."
Might be worth adding in some options to enable/disable that
Quote from: MrTAToad on 2011-Dec-14
Might be worth adding in some options to enable/disable that
Or a new command '
SAFEARRAY: state%=TRUE'
That way you have control over which sections of code get optimized.
Generally, for non time critical code, you want the safer method, but you may want to turn off array bounds checking during the main game loop when using large arrays or whatever.
That would have to be a compile-time option. Do you want release builds not to check for array bounds? That will seriously cause trouble when you misbehave. You get errors and strange results at totally random spots then.
The checks are very quick. I don't think it's a big overhead.
If it does give some speed ups then why not have a new taskbar option (like debug) that turns off/on final version compilation? This would then turn off the array bound checks but only when you are happy it's not going to fall over before hand with normal compilation. This could then be used for other similar things when they become apparent.
Cheers
The option would be nice but personally I don't think I'd ever use it. Inflicting users with obscure and practically untraceable errors in release builds is a horrible thought.
Well, having the option would be nice for me, I very rarely go out of bounds, having it permanently on feels a little wasteful. Only for a release build though, not debug.
All C++ programs that use dynamic arrays have such a check (std::vector always does e.g.). It's not really an overhead.
Would it be possible then to add an error output message when our arrays do go out of bounds, rather than just terminating immediately? Even if it just states "Array out of bounds" or something (stating the actual array would be even better).
Quote from: Kitty Hello on 2011-Dec-16
All C++ programs that use dynamic arrays have such a check (std::vector always does e.g.). It's not really an overhead.
Ah, I had assumed that std::vector was only used for certain situations within GLB, but when I come to think of it, there are very few static arrays within GLB.
I'm using some own stuff that works like std::vector. But a bit more cleverness for the REDIM and such.
DGArray wins!