LÖVE

seeker14491 wrote:

miko wrote:

seeker14491 wrote:Using tables is very slow, as seen here: http://code.google.com/p/lua-vec/wiki/Benchmarks . Is there a way to build a modified version of lua and then make a modified Love2d?

Did you notice that luajit is faster than lua-vec? Just use luajit-based love2d executables (as I always do).

Yeah, I did notice, but I didn't know it could be used with Love2D. Is everything compatible when used with Love2D?

Yes, the only case being when someone generates bytecode instead of providing source *.lua files inside *.love package. But such practice was already criticized on this forum, and now such cases are really rare. Otherwise, everything works, but faster, and you get bit.* and ffi.* functions for free (those of course will work only with luajit-based love2d, no are not portable).

you may want to try luajit again

the final release is able to completely eliminate object allocations in some cases. temporary vectors are pretty amenable to this optimization if you're careful. you may not quite reach c++ performance but it should hopefully perform somewhat better at least.

but you do have to be careful with love api calls, since luajit can't compile those and allocation sinking can only be performed in compiled code.

of course, as mentioned, "unpacked" vectors have zero gc overhead so they're better if you're really hitting the gc, but they are longer and are a great way to get bit by list adjustment. unfortunately, it's fairly difficult to switch all your code from table-based to unpacked vectors.

personally, i would just use tables. if those are too slow i'd fall back to a hybrid method: persistent vectors are mutable tables, but intermediate math is performed on unpacked values (for performance-sensitive areas, other areas you could just use regular vector operations). awkward, but at least you aren't allocating nearly as many tables, and you can keep compatibility with eg userdata/cdata-based vectors