[vlc-devel] [PATCH] LUA: precompile with luac

[Rafaël Carré]

Le 12-02-15 04:39, John Freed a écrit :
> I see the problem but wonder if there might be a better solution. In
> particular, as I understand Lua,  execution of a program basically
> consists of two parts:
> 1) Loading. By this I mean reading the .lua file from disk and
> precompiling via luac into bytecode.
> 2) Executing. By this I mean running the bytecode in the host's luac
> virtual machine.
> 
> Step 2 is exactly the same speed for both lua and luac files. So the
> only speed difference is the overhead involved in Step 1.
> 
> We've seen that while standard Lua might produce identical luac files
> across 32-bit architectures, and perhaps across 64-bit as well, the luac
> files differ between 32 and 64 bit. It also seems clear to me that Lua
> (because it doesn't offer the ability to create 32-bit luac files using
> the 64-bit precompiler) is intended to be used on the host system and
> isn't well designed for cross-compiling.
> 
> One solution is to fork Lua.

Yeah that way is fine but we forked only loading code, not the tool to
build .luac files.

Rémi refuses to mix host & build tools in the contrib, but doesn't
acknowledge that he didn't fork the necessary luac build tool.

> Another, it seems to me, is to load *time critical* lua files when VLC
> starts. These could be placed in a special lua/init directory. By
> performing Step #1 above during VLC startup, the speed issues noted by
> Rémi disappear.

There is no time critical lua file; the compile times I benchmarked and
mentioned are easily lost in the noise.

> I think it's tremendously advantageous to distribute lua files rather
> than luac files. For one, it encourages people to write their own, and
> to make minor local modifications where necessary. Neither is feasible
> with luac files.

Yeah this is an advantage even if those lua files normally are in an
admin owned folder.

> For another, it avoids the problem of either forking Lua or waiting for
> upstream to make fixes.

There is no upstream intention to make luac output a cross platform
format according to discussion on #lua channel.

> On Wed, Feb 15, 2012 at 9:52 AM, <vlc-devel-request at videolan.org
> <mailto:vlc-devel-request at videolan.org>> wrote:
> 
>     Message: 3
>     Date: Wed, 15 Feb 2012 09:12:40 +0100
>     From: R?mi Denis-Courmont <remi at remlab.net <mailto:remi at remlab.net>>
>     To: Mailing list for VLC media player developers
>            <vlc-devel at videolan.org <mailto:vlc-devel at videolan.org>>
>     Subject: Re: [vlc-devel] [PATCH] LUA: precompile with luac
>     Message-ID: <482b6b20d03fac50f58e2c9ef0b47fc0 at chewa.net
>     <mailto:482b6b20d03fac50f58e2c9ef0b47fc0 at chewa.net>>
>     Content-Type: text/plain; charset=UTF-8
> 
>     On Tue, 14 Feb 2012 12:14:37 -0500, Rafa?l Carr?
>     <funman at videolan.org <mailto:funman at videolan.org>>
>     wrote:
>     > Le 2012-02-14 03:27, R?mi Denis-Courmont a ?crit :
>     >> On Mon, 13 Feb 2012 21:39:24 -0500, Rafa?l Carr?
>     >> <rafael.carre at gmail.com <mailto:rafael.carre at gmail.com>>
>     >> wrote:
>     >>> Le 2010-02-14 14:09, R?mi Denis-Courmont a ?crit :
>     >>>> ---
>     >>>>  share/Makefile.am |   64
>     >>>>  +++++++++++++++++++++++++++++++++++++++++++++++-----
>     >>>>  1 files changed, 57 insertions(+), 7 deletions(-)
>     >>>
>     >>> Do we need this at all?
>     >>
>     >> Yes.
>     >
>     > Why?
> 
>     Because it is faster.

That micro optimization just makes packaging difficult, and distributing
.lua files could make lua scripting awareness better like John mentions
so I still don't see the point.

The speed increase is just not noticeable so I'm enclined to remove it
altogether.