Vectors are incredibly slow about mtasa-blue HOT 18 OPEN

Actually, OOP in MTA is 10x slower than PP..
Ridiculous

from mtasa-blue.

so, I have successfully implemented Lua-Vec into MTA.
Nothing blew up, nothing has crashed(other than me creating 160 million userdatas and running out of memory).
Here are some benchmark numbers:

• 10 000 000 iterations
• GC:OFF means the GC was stopped with collectgarbage "stop"
• GC:ON means the garbage collector was running eg collectgarbage "restart"
• mem usage delta is the delta between memusg(total) before running the functions, and at the end
• in the userdata cases (V2-3-4) feel free to multiply the memory value by 2
• Test resource: vectest.zip

============[native-vector - GC: OFF]============
memusg(total): 305.59 MiB

=> create: 3190 ms
=> sub: 1941 ms
=> mul: 1964 ms
=> eg: 703 ms
=> add: 1865 ms

memory usage delta: 1.192 GiB
============[native-vector - GC: ON]============
memusg(total): 1.490 GiB

=> create: 2819 ms
=> sub: 1587 ms
=> mul: 1582 ms
=> eg: 618 ms
=> add: 1575 ms

memory usage delta: 1.192 GiB
==================================================

============[Vector2 - GC: OFF]============
memusg(total): 1.490 GiB

=> create: 12694 ms
=> sub: 12399 ms
=> mul: 12751 ms
=> eg: 2787 ms
=> add: 12590 ms

memory usage delta: 2.906 GiB
============[Vector2 - GC: ON]============
memusg(total): 3.279 GiB

=> create: 50838 ms
=> sub: 27321 ms
=> mul: 30752 ms
=> eg: 7328 ms
=> add: 27570 ms

memory usage delta: 457.76 MiB
==================================================

============[Vector3 - GC: OFF]============
memusg(total): 1.938 GiB

=> create: 25011 ms
=> sub: 27654 ms
=> mul: 12385 ms
=> eg: 2625 ms
=> add: 13643 ms

memory usage delta: 2.906 GiB
============[Vector3 - GC: ON]============
memusg(total): 3.279 GiB

=> create: 87044 ms
=> sub: 28738 ms
=> mul: 27916 ms
=> eg: 7129 ms
=> add: 23017 ms

memory usage delta: -489 B
==================================================

============[Vector4 - GC: OFF]============
memusg(total): 1.938 GiB

=> create: 23437 ms
=> sub: 30718 ms
=> mul: 12657 ms
=> eg: 2584 ms
=> add: 13442 ms

memory usage delta: 2.906 GiB
============[Vector4 - GC: ON]============
memusg(total): 3.279 GiB

=> create: 84181 ms
=> sub: 25660 ms
=> mul: 24275 ms
=> eg: 6246 ms
=> add: 19446 ms

memory usage delta: -481 B
==================================================

from mtasa-blue.

I agree! vectors are 10 times slower then normal list of coords

from mtasa-blue.

On the other side, internal Lua functions are pretty fast, so, maybe we need a custom version of lua, which has vectors by default, or something, because this way only MTA's source code benefits from Vectors.
They are literally 100x times slower(not considering the time it takes to create them.)

from mtasa-blue.

There is also a memory "problem" caused by infrequent garbage collection. See mantis 9840.

It would be useful to document this online.

Suggestions:

• Implement vectors as Lua tables, maybe??? Not sure if this would help at all, but as a side effect it fixes #374
• Modify vectors to do more in-place operations. If necessary, make <oop>true</oop> now take a version <oop>2</oop> for v2

from mtasa-blue.

There is also a memory "problem" caused by infrequent garbage collection. See mantis 9840.

Wow that's heavy. This could be a hugh part of our performance issues. Our gamemode ist full written in oop and we used Vectors neary everywhere.

from mtasa-blue.

I don't think it causes any performance issues, it would only affect memory usage.

from mtasa-blue.

Memory issue was 'fixed' in 6f3fe6d (but Mantis was not updated)

from mtasa-blue.

What do you mean under "in-place" operations?
Actually, garbage collection is pretty slow, if you create 200 vectors every frame, and you measure the time it takes to create them, you'll notice it's between 0 and 1(depends on CPU), but sometimes it jumps up to 28ms, that's I suppose the gc kicking in, even do maybe it's just the frame limiter.

from mtasa-blue.

But even creating a Vector takes a lot of time for some reason.

from mtasa-blue.

Tried in-place add, it nearly takes the same time to complete, so that didnt really help.
Implementing vectors as Lua tables wouldn't help too much either, I've tried that and it gave me the same results.
With that in mind in really have no clue why it's so slow.
Reading from the stack can't be that slow, since __eq is fast.
Pushing to the stack can't be that slow since then every function that is vector based should be slow(because they push vectors onto the stack).

operator+ can't be so slow since adding values up with simple dereferencing(so in-place) would be way faster.
Maybe what causes the issue are metatables, and the way they work?
But then why is __eq waay faster than the other methods? Maybe it's some kind of Lua optimization?

Edit:

Actually....

from mtasa-blue.

Summarisation of discussion in #mta.dev. Proposed next steps are:

1. context switches wastes time. lets move the existing vector API to a Lua implementation (retaining the exact same API)
2. explore in-place operations as a separate pull request
   • do a "draft" implementation for sake of profiling
   • measure the difference result = result + x is vs. result.add(x) (but for complex calculations, not something this simple. write a bitcoin miner in lua or something.)
   • ensure that the in-place operations does not affect existing scripts.
   • document in-place operations somewhere
   • make it clear that this feature does not break or improve existing scripts. scripts will need to be modified to take advantage of this feature. also make it clear that infix operators are generally better for readability, and in-place ops are for squeezing out that last bit of performance when doing complex calculations

from mtasa-blue.

Even if we implement vectors in Lua we won't be able to pass them trough events as the metatable will get lost in the process, so we don't fix #374

from mtasa-blue.

Even if we implement vectors in Lua we won't be able to pass them trough events as the metatable will get lost in the process, so we don't fix #374

The coordinates will still be stored in the dictionary section vec.x,vec.y,vec.z (or array section, vec[1],vec[2],vec[3], if we wanted .x to go via __index), so half the problem will be fixed.

Further work will need to be done to magically re-apply the metatable on the "other end", Potential solution for magically reapplying the metatable:

• set some __mta_type field if that doesn't already exist
• on the "other end", check if metatable is already set. if not, check if table passed around has __mta_type set to Vector3. if so, set the table's metatable to Vector3

This same magically reapplying the metatable thing will need to be done when passing vectors between resources. Probably needs to be implemented as part of CLuaArgument(s).

(Could actually be a generic setting like __mta_metatable that will set the table's metatable to the whatever table living at _G[__mta_metatable]. This will benefit general OOP implementations. But I like the idea of the typename being accessible as well.)

from mtasa-blue.

Does the "bad" OOP performance only apply to OOP functions or will the whole script performance suffer when i simply enable OOP in the meta while using only 1 OOP function in a big script? Because i need OOP to get the camera forward matrix and i dont want to break CPU performance even more.

from mtasa-blue.

@Einheit-101 the performance issue is really only with Vectors and Matrices.

Ultimately the issue is mostly due to garbage collection. If you do something simple like
(a + b + c)*(a + b + c) with the Vectors a, b and c, MTA will need to:

• create vectors a, b, c
• create intermediate vector for a + b (left side)
• create intermediate vector for a + b + c (left side)
• garbage collect a + b vector (left side)
• create intermediate vector for a + b (right side)
• create intermediate vector for a + b + c (right side)
• garbage collect a + b vector (right side)
• create intermediate vector for the result
• garbage collect a + b + c vector (left side)
• garbage collect a + b + c vector (right side)
• return result vector

If you did the same thing with three floats, each you'd not get a single object construction or destruction.

from mtasa-blue.

Yeah, so I've looked around, and found this.
Now, I've looked at the code, and it seems like to be mostly compatible with the current Lua bytecode.. mostly.. The only thing being incompatible is the typeids have increased, so now it looks like this:

// ltm.c:23

const char *const luaT_typenames[] = {
  "nil", "boolean", "userdata", "number",
  "vec",  /* LUA-VEC */
  "string", "table", "function", "userdata", "thread",
  "proto", "upval"
};

(note the `/LUA-VEC/ comment)

// lua.h:69

#define LUA_TNONE		(-1)

#define LUA_TNIL		0
#define LUA_TBOOLEAN		1
#define LUA_TLIGHTUSERDATA	2
#define LUA_TNUMBER		3
#define LUA_TSTRING		4
#define LUA_TTABLE		5
#define LUA_TFUNCTION		6
#define LUA_TUSERDATA		7
#define LUA_TTHREAD		8
#define LUA_TVEC		9  /* LUA-VEC */

// lobject.h:19

/* tags for values visible from Lua */
#define LAST_TAG	LUA_TVEC  /* LUA_TTHREAD   -- LUA-VEC */

#define NUM_TAGS	(LAST_TAG+1)


/*
** Extra tags for non-values
*/
#define LUA_TPROTO	(LAST_TAG+1)
#define LUA_TUPVAL	(LAST_TAG+2)
#define LUA_TDEADKEY	(LAST_TAG+3)

from mtasa-blue.

• If it's possible to make this backwards compatible with previously compiled scripts, great!
• If it's not possible to make it backwards compatible, I don't see a problem with forcing people to recompile their code
• I'm not against this either, as this wouldn't change any syntax afaik (Lua or the existing MTA API, I assume?)

But I am not excited about modifying our copy of Lua further. This isn't a no -- I'd just be a lot more excited if we had a proper Lua branch with our custom changes somewhere.

from mtasa-blue.