LuaJIT?

[liquidev]

A while ago I saw that there were some new branches: using-luajit, and using-luajit-2. @franko are you considering using LuaJIT for faster performance?

[takase1121]

AFAIK luaJIT is 5.1 and incompatible with 5.2.

[liquidev]

Ah, looking at the incompatibilities list it seems that Lua 5.1 and 5.2 aren't fully compatible with each other.

[takase1121]

Besides how fast do you want it to be? PUC's implementation is pretty fast. I doubt we could push out more performance. As long as the UI is smooth, a few ms isn't going to matter too much.

We could put our focus to improve the lua side of the code instead, I think that will yield much more benifits.

[liquidev]

Well, my linting plugin uses a rather inefficient method for rendering antialiased quarter-circles so I hope it doesn't affect performance too much.

[takase1121]

I mean, you're probably going to exhaust command buffer before slowing it down significantly for users to notice.

…

On Sat, Apr 3, 2021, 20:08 liquidev ***@***.***> wrote: Well, my linting plugin uses a rather inefficient method for rendering antialiased quarter-circles so I hope it doesn't affect performance *too* much. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6UHTBJZKXOLRXR7FCGLETTG4AMDANCNFSM42KFHEYA> .

[liquidev]

Honestly it would be nice if we could add some extra drawing functions into the core for plugins to utilize. Having to implement an antialiased circle rendering algorithm in Lua feels kind of icky.

[franko]

A while ago I saw that there were some new branches: using-luajit, and using-luajit-2. @franko are you considering using LuaJIT for faster performance?

Lite-xl works nicely with luajit, the second branch is working and could be merged. I was considering merging into the master branch or releasing luajit binaries for testing. Luajit would remain optional and Lua 5.2 would be used unless luajit is explicitly requested.

Yes I was considering luajit to have faster execution of lua code. Lite and lite-xl are quite lua-heavy especially when using some plugins.

[franko]

AFAIK luaJIT is 5.1 and incompatible with 5.2.

You are correct but in practice they are almost-compatible. I was able to use luajit adding a very simple compatibility layer. On the Lua side it was a few lines while on the C side it was less trivial but I found the compatibility layer already available from the Kepler project. It required only implementing a few missing C API functions.

[franko]

Besides how fast do you want it to be? PUC's implementation is pretty fast. I doubt we could push out more performance. As long as the UI is smooth, a few ms isn't going to matter too much.

We could put our focus to improve the lua side of the code instead, I think that will yield much more benifits.

Well, I agree with you about that. This is basically the reason I didn't rush to integrate luajit. As long as the Lua code is reasonably coded the speed-up introduced by luajit doesn't matter that much. Some parts of the Lua code scales badly so they should be rewritten to perform better to scale better, throwing a jit-based engine is not the solution.

In addition the rendering engine on the C side can also be optimized to better use the CPU. For example when you scroll a DocView the application is rendering over and over the same text which is just shifted without reusing even a single pixel from the previous frame. So there is room for an obvious improvement there. In addition the SDL library is able to use hardware-accelerated operation but lite refuse to use them and write himself pixel-by-pixel not using the more modern API SDL offers.

I have a good idea about how to optimize the graphics engine but I had to give the priority to implement more or better functionalities instead of optimizing something people will barely notice.

[franko]

Honestly it would be nice if we could add some extra drawing functions into the core for plugins to utilize. Having to implement an antialiased circle rendering algorithm in Lua feels kind of icky.

This was in my list of nice things I would like to implement and I think this is actually easy because it fits with current lite architecture. You just add a new command in rencache.c to render a polygonal path which, in turns will be rendered by the AGG library. The tricky part is that you need to copy the path data into the command payload but this is not difficult to implement.

Of course render an arbitrary polygonal path will be slower than a rectangle but the AGG library is pretty good and probably the wouldn't be any noticeable slow down. Well with AGG you have also the option to render the path using non-antialised algorithm, grayscale antialiasing or subpixel antialiasing like for the fonts.

On the other side I had no reason to implement this stuff except for the pure pleasure of implementing such a cool thing.

[joaopauloalbq]

Is there any really significant feature in Lua 5.4 that justifies its use over the huge impact on performance loss compared to LuaJIT?

For example, the following code in LuaJIT is 525% faster than Lua. It is even faster, in some magical way, than Rust and C 🤯

local x = 1

for i=0,99999998 do
    x = (i+i+2*i+1-0.379)/(x)
end

print(x)

Lua 5.4.6 - PUC-Rio
LuaJIT 2.1.1692616192 - Mike Pall

From my point of view, the project should be tied to Lua 5.1 and LuaJIT only.

[jgmdev]

Just in case you didn't know Pragtical already uses LuaJIT by default.

[Guldoman]

Our performance is mostly not degraded by Lua. The only place where it could help slightly is our tokenizer, but even then a rewrite in C would be more appropriate.

The cons of using JIT is that it makes it more complex to ship the same version to all our targets (MacOS requires some additional work afaik), as well as having to consider what distros ship, because we need to use the same version to be sure (native) plugins are compatible. And considering that "version" in the LuaJIT world doesn't mean much...
Last time we "used" it we also had issues with the GC.

All things considered I don't think LuaJIT is a good candidate for this project.

[joaopauloalbq]

Why would you program in C if you can program in LuaJIT which is faster to develop, easier to use, more enjoyable and just as fast as C?

LuaJIT v2.1 only receives non-breaking changes and limited, upwards-compatible features [1]. You will not have compatibility problems with plugins. Furthermore, Lua is very small and embeddable, just embed it in the installer (exe, dmg, appimage) or even the binary. However, I don't think this will be a problem, as in the next version of Lite-XL all operating systems will already have a 2.1 version of LuaJIT.

Last time we "used" it we also had issues with the GC.

That's a problem...I've been using LuaJIT in my window manager (Awesome), so it's running all the time and I haven't had any problems. You should test again.