Over-thinking it again
Blitz3D Forums/Blitz3D Programming/Over-thinking it again
| ||
| Just an item of curiousity, is there any difference in speed performance between a single-dimensional array and a Blitz array? [bbcode]Dim array(50) Global array[50][/bbcode] |
| ||
| Time for a Flakey Speed Test™: Conclusion: no speed difference. |
| ||
| I'd imagine any difference is so negligible that it certainly won't be where your slow points will be.... |
| ||
| argh a damming to the slowdown and the double posts! :| Last edited 2012 |
| ||
| I would not be surprised if they did not translate to the same thing under the hood (ie. some kind of normal C array). What is a fair bit slower though is type-lists and using repeated type access when unessecary (rather than transfering the fields to locals and back again... there is a "number of same lookups break-even point" for this, cannot remember what it is, but the number is relatively low before you can speedtest the difference.) -Although the convenience of types and typelists* should not put anyone off using them! But if you need some uber-fast nested iteration you are better off with arrays or local transfers. (*that is for example using "foreach in" for those that are unaware as unlike max, b3d does not make it's use of lists clear) Last edited 2012 |
| ||
| there is a "number of same lookups break-even point" for this, cannot remember what it is, but the number is relatively low before you can speedtest the difference It's somewhere in the region of 7-12 on my computer, but this will vary from machine to machine, and the increase is negligible either way. Remember that B3D performs no optimisations. Pulling a member out and working with the local can often bring ludicrous speed improvements in BlitzMax or C, because an optimising compiler can assign hot locals to work from registers. Blitz3D will never do that, so there's actually very little difference in the mechanics. (Also worth noting that a compiler capable of working out that a local can go in registers will often be able to tell when an object is safe to split up temporarily, so unless you're doing Dark Pointer Magic, you usually don't need this technique with optimising compilers either.) If you need this kind of micro-optimisation, it's seriously time to consider supplementing your code with a DLL in a more performant language. It's simply not possible to make B3D code all that fast (heck, these days there are interpreters in B3D's performance league...). |
| ||
| Pulling a member out and working with the local can often bring ludicrous speed improvements in BlitzMax or C, It can in B3D too, trust me :)But yeah as you say do don't really need to do this unless you want to squeeze every millisecond out of a load of nasty nested consuming code with 100s of lookups to "obj\h obj\x obj\y obj\z + others." for example. Plus you only need to write back what has changed. At the end of the day it is worth doing anyway, just to make the code more readable, and if it speeds it all up then bargain. :D Last edited 2012 |
   |