ComputerCraft + LuaJIT = CCLuaJIT = WINNING

What do you get when you take ComputerCraft and LuaJIT and mash them together? High-performance Lua programs running in your Minecraft world! On my machine, using a (probably poorly written) SHA-256 benchmark program, I observed a ~10-13x speedup.

This is best expressed visually: https://www.youtube.com/watch?v=RlpAn6MHLC8

This mod currently works on Minecraft 1.7.10 with ComputerCraft 1.7-1.75. In the future, I intend to support other versions.
I hope to release the mod in the coming weeks, if possible. Worst case scenario, in the next month.

Wow, amazing! I want this on 1.12 so badly :D/>

Jummit, on 21 January 2019 - 03:10 PM said:

Wow, amazing! I want this on 1.12 so badly :D/>

Thanks! It will come, hopefully sooner than later! Frankly, I posted this earlier than I wanted to; I've still got work to do between fixing bugs and just generally improving the mod… but it will happen eventually.

If you get it working in 1.12, you next challenge could be getting it working in cobalt (SquidDev's updated runtime used in CC:T).

Lupus590, on 21 January 2019 - 06:32 PM said:

If you get it working in 1.12, you next challenge could be getting it working in cobalt (SquidDev's updated runtime used in CC:T).

I assume this would be an alternative to Cobalt, rather than on top of.

With regards to the OP, really impressed someone managed to actually get this working! It's something that's been talked about for a few years, but super surprised that you've taken the time to implement it!

I've always had a few worries about this, so just a couple of questions:

• How does this play with sandboxing? I assume things like FFI and bytecode loading are disabled, but do you know whether it is safe to enable the debug API or not?
• Are you running with the JIT enabled, or just the interpreter? If so, just curious as to how you're handling too long without yielding - I seem to remember reading that debug hooks aren't fired within JITted code, which makes it a little harder to throw errors.

SquidDev, on 21 January 2019 - 06:46 PM said:

Lupus590, on 21 January 2019 - 06:32 PM said:

If you get it working in 1.12, you next challenge could be getting it working in cobalt (SquidDev's updated runtime used in CC:T).

I assume this would be an alternative to Cobalt, rather than on top of.

With regards to the OP, really impressed someone managed to actually get this working! It's something that's been talked about for a few years, but super surprised that you've taken the time to implement it!

I've always had a few worries about this, so just a couple of questions:

• How does this play with sandboxing? I assume things like FFI and bytecode loading are disabled, but do you know whether it is safe to enable the debug API or not?
• Are you running with the JIT enabled, or just the interpreter? If so, just curious as to how you're handling too long without yielding - I seem to remember reading that debug hooks aren't fired within JITted code, which makes it a little harder to throw errors.

Based on a three-second peek at the CC-Tweaks code, I don't really think there's any major reasons it wouldn't work alongside it, but I don't see why anyone would want to do that, barring any other additions in CC-Tweaks. Probably makes sense to not use them together.

• As for sandboxing, each computer has its own lua_State. FFI and Debug are disabled. I haven't done anything regarding bytecode loading _yet_, but, I don't see any obvious reason to disable it. I haven't determined whether it's safe to enable debug or not yet.
• I am running with the JIT; it's enabled by default. As for 'too long without yielding', yes, hooks don't work properly with JITted code. The trick to that is to just set a debug hook with a count of 1 at the time when a Lua thread needs be yielded. One tricky thing though is the lack of being able to 'yield across C-call boundary'; this led me to have to do some hacky things… as well as write more code than I had originally expected to be necessary.

I intend to write a blog post discussing much of the technical details after the initial release.

sci4me, on 21 January 2019 - 10:13 PM said:

One tricky thing though is the lack of being able to 'yield across C-call boundary'; this led me to have to do some hacky things… as well as write more code than I had originally expected to be necessary.

Weird - I thought LuaJIT had a patch which allowed this functionality. I guess it doesn't cover every case though. Very much looking forward to the blog post though!

SquidDev, on 21 January 2019 - 11:05 PM said:

sci4me, on 21 January 2019 - 10:13 PM said:

One tricky thing though is the lack of being able to 'yield across C-call boundary'; this led me to have to do some hacky things… as well as write more code than I had originally expected to be necessary.

Weird - I thought LuaJIT had a patch which allowed this functionality. I guess it doesn't cover every case though. Very much looking forward to the blog post though!

They do however it apparently isn't supported in 2.0.5… as far as I've been able to tell.

Don't expect anything _too_ soon; I've got a lot of work to do to make this thing sufficient for release. But I suspect that I'll have plenty to write about!

sci4me, on 21 January 2019 - 04:41 AM said:

What do you get when you take ComputerCraft and LuaJIT and mash them together? High-performance Lua programs running in your Minecraft world! On my machine, using a (probably poorly written) SHA-256 benchmark program, I observed a ~10-13x speedup.

This is best expressed visually: https://www.youtube....h?v=RlpAn6MHLC8

This mod currently works on Minecraft 1.7.10 with ComputerCraft 1.7-1.75. In the future, I intend to support other versions.
I hope to release the mod in the coming weeks, if possible. Worst case scenario, in the next month.

This is awesome… will it work on multiplayer?

I'm almost done debugging my Zilog Z80 emulator for lua and LuaJIT would definitely help it out quite a bit.

Since MC 1.3 the game's always been "multiplayer". SP transparently starts a server for you to play on, so you'd practically have to go out of your way to make a non-MP mod.

Bomb Bloke, on 03 February 2019 - 10:08 PM said:

Since MC 1.3 the game's always been "multiplayer". SP transparently starts a server for you to play on, so you'd practically have to go out of your way to make a non-MP mod.

lol… i'm mad at myself because I knew that.

Bomb Bloke, on 03 February 2019 - 10:08 PM said:

So you'd practically have to go out of your way to make a non-MP mod.

It's actually surprisingly easy to write code which accidentally depends on client-only classes. But given that this mod barely touches MC code, I suspect you're good!