Vectors vs Arrays
BlitzMax Forums/BlitzMax Programming/Vectors vs Arrays
| ||
I'm creating some geometry types so that I have standardised objects for everything which needs shapes in my game, such as lighting, collisions and possibly physics. However before I continue I'd like to know your opinion on weather you think it's a good idea to use vector objects everywhere, or to stick to arrays, multidimensional arrays, or even arrays of arrays, for functions which will see a lot of use. For example...''''Vector Method GetPoints:TVec2[] () 'Return NEW vectors for each point End Method '''Array Method GetPoints:Float[]() 'e.g. Return [x,y,x+w,y+h] EndMethod '''Array of arrays Method GetPoints:Float[][]() 'e.g. Return[[x,y],[x+w,y+h]] EndMethod '''Multidimensional 'can't be bothered to write it but you get the picture Which method offers the best usability/speed in your opinion? My thought is that, if using vectors here for every point turns out to be too slow, I'd probably go with arrays of arrays, so that you can, for example, get Point[1][0] |
| ||
| I would say that you would be better of with objects! But there are already a few vector/math libraries in the code archives and the community framework why not use one of those as your base? |
| ||
| As reference iirc MiniB3D uses objects for vectors. It even uses objects as result-types when making many vector calculations. I think that was this that stopped me from playing with MiniB3D with BMX-threading back in the day because the garbage collector (at least back then) was much to slow to cope with the massive about of objects this produced. MiniB3D worked quite ok in single threaded more though. |
| ||
| Since creating the topic I've actually benchmarked the different choices. The speeds were a ratio of (array:array-of-array:objects) = (2:7:8), making objects significantly slower than an array, but not much slower than an array of arrays. However the difference only becomes noticeable at hundreds of thousands of calculations per second, which I won't even get close to doing, so I've gone with vector objects for usability. However, Mahan, you make a good point about threaded mode, which I've yet to test. I'm sure vectors will be slower still, but I've already started sticking them in all over the place now, and even with the threaded GC I don't think I'm doing enough calculations for it to matter. |
| ||
| [...]benchmarked the different choices[...] and even with the threaded GC I don't think I'm doing enough calculations for it to matter. Proof-of-concepts or benchmarks are my preferred method of testing computer "doubts" (in lack of a better word) too. The second quote also has a lot of merit. Before building in optimization (which often complicates the code structure) be certain that the optimization is needed. A well written and clear piece of code is commonly easy to optimize. It's often much harder to optimize a complex code (due to previous. possibly unnecessary optimizations). KISS principle at it's best (Keep it simple, stupid!) :-) |
| ||
| Both Arrays and Objects are heap allocated and subject to garbage collection though. The reason Objects seem slower, is probably because they carry around their own VMT (using more memory). Where you can expect speed improvements is in 1D arrays of multiple "vectors" (ie vecs:Float[3*count]) and filling pre-allocated space instead of allocating new space on each math operation. |
| ||
| IMO, a distinct vector class has better usability/readability. And since Arrays are objects, you're speed "hit" isn't going to come from accessing the fields (x,y, etc), but from creating those objects (either TVec or Array). When I wrote the initial port to Farseer Physics I knew there'd be a performance bottleneck with allocating vectors and such but didn't do it until it BECAME a problem. Only then did I start using inlining, caching, and pooling techniques to mitigate the allocation of objects inside the main loop. |
| ||
| The best way with automated garbage collectors is to recycle objects. With out recycling and randomly removing objects, The memory gets trashed just like Harddrives when they get fragmented. after a while of adding and removing objects the memory allocation starts to slow down the program. the best way is to create objects and when they are done being used, store them for future use. It can be done in arrays but work best with Link Lists sense you can expand and shrink them as needed. a good example is demonstrated here by DStastny: http://www.blitzmax.com/Community/posts.php?topic=62215 There are other similar ways but this one illustrate the principle really clear. |
   |