Lua Interpreter

Is it possible to change the lua interpreter with luaj interpreter?

Errrrr...maybe? But why? What do you gain from injecting a Java VM?

Well it says its faster then lua in its website

Also my main reason is you can reach java abilities with it.

Actually, the luaj website says the interpreter is slightly faster on _some_ benchmarks and is much slower on others. Even using their lua-to-java-bytecode compiler only gets you allegedly better performance on some subset of benchmarks and worse performance on others. That doesn't sound very compelling.

If you want better performance, use LuaJIT. It's a drop in replacement DLL that doesn't require a bunch of work punching through an injected Java VM with JNI.


For what? What Java abilities are we talking about here?

As I recently replied to another poster, the standard Lua is still quite fast. See this page:

http://www.gammon.com.au/forum/?id=10346

That shows scrolling chat, a map window that is redrawn rapidly, even a 3D view where each pixel is calculated individually, in Lua.

Fiendish uses LuaJIT in the Aardwolf release to get some extra performance out of Lua, and he is happy with that.

Unless you are into a lot of graphics-based stuff (like Aardwolf is with a lot of miniwindows) then you would hardly need much extra speed for a text-based MUD.

Honestly, I'm not even sure I get much extra performance out of it. I guarantee that most of my time is spent waiting on disk and network I/O and screen drawing which are both outside of Lua's hands, and the JIT compiler likely never has a chance to warm up, so at best we have a small speedup from a more optimized interpreter. I challenge anyone to demonstrate a purely algorithmic plugin of the sort that would benefit from a faster interpreter.
I think the main benefit is unfettered Win32 access via FFI.

Which is used for what purpose?

I'm sure Fiendish knows this, but for the benefit of others who may not, you can extend Lua to call any Win32 function by writing your own custom DLLs. A write-up on doing this is here:

http://www.gammon.com.au/forum/?id=4915

Not only can you call Windows functions, you can also call "back" into the Lua code if you need to (eg. to do a ColourNote).

Now of course you need to compile (and supply if you distributing copies) the DLL, but if you are going to distribute the LuaJIT DLL you may as well distribute one written to your own requirements.

Plus, you can compile using Cygwin which is a free compiler for Windows (amongst other things).

In the case I'm thinking of, I think it's just one call to CreateDirectoryA. But it's a really useful call! :)


With FFI you really get much more than just Win32 (you can use native C arrays interleaved with your Lua code, for example, if you _really_ want to press the GOFAST button). And it doesn't require compiling a new DLL to wrap one function at a time. I don't use it much, but I like that the option is there.

<raises eyebrows>

From: http://www.gammon.com.au/forum/?id=12496



That seems a lot of work to get one function call. A tiny DLL called from standard Lua would give you the same result without having to keep an eye on LuaJIT bug fixes.

Can't you use os.execute to create a directory?

Keep in mind that my goals are different than the average user's. I'm creating a package for an entire community, users and developers both, not just for me. I think that LuaJIT gives significantly greater flexibility, even if nobody uses that flexibility yet.

Also it's fun

I also can't discount that there is /some/ performance gain. I do remember doing tests at some point a long time ago, running around on Aardwolf with the mapper going. I remember the results being statistically significant. But I don't remember the results being particularly impressive, and we know that Aardwolf pulses runs much faster than most (all?) other games, so any significance would be yet diminished for other MUDs.


Sure, but try it and report your experience? I started with that and then switched to a direct Win32 call because I was seeing a cmd.exe window flashing across my screen. The experience of rapidly transient black boxes that I couldn't quite read gave me a horrible sense of dread that I didn't want to pass on to other players.

You can hide that annoying extra window by passing SW_HIDE (ie. zero) as the fifth argument to utils.shellexecute.

For example, this code creates "foo" at the root level of C: without any window flickering into view.



Omit that last "0" parameter and you see the window.

Heh. ShellExecute returns before the file operation completes (noticeable on file copy), so it could be dangerous.