So, whats people's opinion on this?
I'd be really happy to see this in 1.6.
Also it seems like we could without problems add support for matrices as well. A GCObject is 180 bytes, a regular 3x3 matrix is.. 48, which means that the unions size would stay the same.

I like the changes.

@qaisjp suggested that it would be nice to have a separate branch to keep track of our modifications to Lua.

We can have a submodule for Lua. In this way, it will be easy to track the changes.

So, we should create a separate repo?

So, we should create a separate repo?

Hmm, that doesn't seem like a good idea. Let's just create a new branch for Lua. I'd do it like this:

1. Download Lua 5.1 original source and commit the code to the branch.
2. Copy the Lua source from MTA vendor to the new branch.
3. And then create a PR for lua-vec changes.

My approach would be:

1. Fork Lua repo to multitheftauto org. This keeps original history instead of destroying the Lua 5.1 history, and makes it easier to cherry-pick improvements later.
2. Cherry-pick our custom 5.1 mods from mtasa-blue to a branch on the Lua repo
3. Replace vendor/lua in mtasa-blue with a submodule that targets that Lua repo
4. Create a PR for lua-vec changes in the Lua repo.

This approach is compatible with the submodule system proposed in #319.

AFAIK There is no official Lua repo on GitHub, if that's what you meant by Fork Lua repo.
I dont think the Lua history is necessary. I'll just create a new repo with the 5.1 source code from Lua website

Okay I think I did it.
Is this what you meant?

AFAIK There is no official Lua repo on GitHub, if that's what you meant by Fork Lua repo.
I dont think the Lua history is necessary. I'll just create a new repo with the 5.1 source code from Lua website

There's an official mirror on GitHub of the Lua repo, here. It has a tag for every released Lua version, all the way back to 5.1. I agree that keeping the history may come in handy in the future for some cherry-picks, for updating Lua more easily, or whatever, but I would also understand not keeping the original commit history if it's deemed too verbose.

Please look at MTA org's /lua repo.
I have filtered our commits to vendor/lua + added base Lua at the top (source code for 5.1.5 downloaded from Lua website).
Would that fit?

i noticed you call the vector type in Lua only "vec" which is inconsistent to the other types: "number", "table", ...
the type should be "vector"

since Lua uses doubles, shouldn't the vectors not use doubles too?

There would be no benefit of the additional memory required. MTA uses float vectors everywhere, the additiona precision would be lost.
Yeah, the type name will be changed, once this PR gets reviewed or something.. Tbh, we didnt really agree on a name yet. I think vector (perhaps with a capital V) is acceptable. Since it's not vanilla Lua, we might as well stick to our naming convention.

maybe cVector
where c stands for custom
or if someone has better idea he should write it

btw. since my knowledge is not too big about instruction sets
so, only asking if it's possible:
could it be possible that the vectors could somehow utilize something like sse2 for even higher performance?

Please look at MTA org's /lua repo.
I have filtered our commits to vendor/lua + added base Lua at the top (source code for 5.1.5 downloaded from Lua website).
Would that fit?

I'm not sure if you were talking to me, but yeah, it looks good to me. I was just pointing out that the original approach that @qaisjp suggested was possible due to the existence of that mirror.

Anyways, the submodule stuff #2112

The main bottleneck is probably still the Lua side, rather than the actual maths. Not worth the headache. But where I think we might benefit from SSE is our vector stuff.. although I wonder why MSVC doesn't use SSE by default there.. Should be pretty trivial I belive.

Edit: Turns out there's 2 lua-vec branches: One which is a first-class value like a number, bool, etc.. and the second one (this) treats it as GCObject's. Obviously the first one is faster, but comes at the expense of making TValue be 16 bytes instead of 8 (Which translates to basically 2x memory usage for Lua values) and probably performance loss as it would take 4 memory fetches to move the value into the register. The GC'd version is probably already fast enough IMHO. Although it uses some hackery (some kind of free list?).

@Pirulax A great amount of time has passed, but do you still want to get this pull request merged?

This is very useful and would be a good update.
You don't plan to continue dealing with this PR in the future?

Bump?

Any news on this? Would make my current project way easier and faster instead of countless float math operations each time.

I think it can be merged, no?

Edit: Actually nvm, this is just the veclib, i'd still have to change all the parser stuff and whatnot to return this type instead of Vector3...
I don't really have the time to deal with this PR to be honest.
So, if anyone has the time to work on it, then great, we can get this merged... Otherwise it is what it is.