[vlc-devel] [PATCH] LUA: precompile with luac
funman at videolan.org
Wed Feb 15 18:46:33 CET 2012
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>>
> > 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
More information about the vlc-devel