Performance Increase/Switching Compiler

This discussion has resulted in quite an interesting find. Namely, switching to the org.luaj.vm2.luajc.LuaJC compiler results in much faster performance (see post #4). I'm not too knowledgable about it really, SquidDev is the one who made the discovery.

He found that most drawing is twice as fast and 'computing' (which runs a few SHA256 functions from memory) is about three times faster. The results also found that the windowing API has far worse results (the bottom score is a maximum of fifty from memory) when using the current compiler, which I'd guess is caused because of the increased amount processing on the Lua side of things.

SquidDev, on 03 January 2015 - 04:51 PM said:

This really interested me so I've put a little experiment together. I ran ComputerCraft with and without Java bytecode compilation on CCEmuRedux. Running 1lann/GravityScore's benchmark script produces these results:

		  | Current | Bytecode
==========|=========|===================
Text	  | 16.25   |  7.6
Color	 | 46.55   | 24.5
Advanced  | 31.75   | 14.35
Computing |  6.15   |  2.4  (Lower is better)

Overall   |-45.7	| 6.15  (Higher is better)

It is obvious that compiling to bytecode is quicker, but has quirks such as files with hyphens cannot be compiled (but I'm sure that could be avoided).

Without Window API: just in case you wanted it

			Current | Bytecode
==========|=========|===================
Text	  |  4.9	|  2.75
Color	 |  3.15   |  2.45
Advanced  |  6.1	|  4.85
Computing |  8.85   |  2.4   (Lower is better)

Overall   | 32.0	| 42.55  (Higher is better)

While SquidDev did point out that there are some quirks, it seems like switching to this and fixing these small issues would be very beneficial to fairly graphical or processing intensive programs, of which there is an increasing amount.

This would be good. And if the JVM JITs that bytecode to machine code, it means that JVML-JIT compiles java to lua to java to machine and that's awesome =P

I hope this suggestion doesn't die out like the other good ones…
Faster Computercraft = Better. We can live with it's little bugs.

I support this. That is all.

I've looked a little bit more at this.

If Computer Craft were to switch to using the LuaJC compiler, the ByteCode Engineering Library would have to be included in the ComputerCraft package adding an extra 500kB to the 1500KB ComputerCraft download, this is slightly undesirable.

An alternative would be to use ASM to compile it. This is already included in Forge, so would not change the size and is apparently faster than BCEL, so compilation would be quicker.

The only class that needs to be changed is the org.luaj.vm2.luajc.JavaBuilder class, though I don't know how hard that would be.

I'm +1

As to additional .5MB, this would not be a real problem, wouldn't it? Either for download, HDD usage or RAM.

All in.
Computercraft's performance nowadays is just not as good as it used to be, and it disappoints me to see things barely being able to keep up with user input.
That graphics boost I'm sure would be extremely helpful for me with Game-engine, considering maps are 200x200(by default) which is on a single buffer object, which that buffer must then be written to the object buffer, then the player on then, then that written to the screen. And there's no way around that, trying to take the player back off the map buffer would take a lot longer.

SquidDev, on 11 January 2015 - 11:21 AM said:

I've looked a little bit more at this.

If Computer Craft were to switch to using the LuaJC compiler, the ByteCode Engineering Library would have to be included in the ComputerCraft package adding an extra 500kB to the 1500KB ComputerCraft download, this is slightly undesirable.

An alternative would be to use ASM to compile it. This is already included in Forge, so would not change the size and is apparently faster than BCEL, so compilation would be quicker.

The only class that needs to be changed is the org.luaj.vm2.luajc.JavaBuilder class, though I don't know how hard that would be.

Yea, I'd rather an extra 500kb if means faster performance.

oeed, on 11 January 2015 - 08:58 PM said:

SquidDev, on 11 January 2015 - 11:21 AM said:

I've looked a little bit more at this.

If Computer Craft were to switch to using the LuaJC compiler, the ByteCode Engineering Library would have to be included in the ComputerCraft package adding an extra 500kB to the 1500KB ComputerCraft download, this is slightly undesirable.

An alternative would be to use ASM to compile it. This is already included in Forge, so would not change the size and is apparently faster than BCEL, so compilation would be quicker.

The only class that needs to be changed is the org.luaj.vm2.luajc.JavaBuilder class, though I don't know how hard that would be.

Yea, I'd rather an extra 500kb if means faster performance.

I'd prefer ASM if it were down to ASM and BCEL

If ASM is even faster than BCEL then it would probably be better. Also, a few kilobytes shouldn't be a big problem to anyone IMO.

It's stuff like this that really makes me wish CC were open source. There's so much that could be done to improve it, and we have a team of moderators who would be able to filter bad pull requests. And Dan only seems to update it mostly for major MC updates nowadays.

ElvishJerricco, on 15 January 2015 - 03:07 AM said:

It's stuff like this that really makes me wish CC were open source. There's so much that could be done to improve it, and we have a team of moderators who would be able to filter bad pull requests. And Dan only seems to update it mostly for major MC updates nowadays.

I agreed with what you're saying. Dan, understandably, seems to have lost interest (at least the majority of it) in ComputerCraft. I completely understand if he doesn't want to open-source it, it is his own work after all. But yes, I'm sure it would be beneficial for it to be open-sourced.

OK. I've been working on this and I've ported it to ASM. There should be complete compatibility with Forge, though I haven't tested.

You can have a read of the code here, if anyone uses it, please let me know just because I am interested to see what people can do with it.

You can see some example usage in the really rubbish test I wrote.

I don't think this topic is getting enough attention. Everything is all planned and ready to be used, and their are very minor drawbacks to switching to this.

I guess dan just lacks an incentive.

Detective_Smith, on 04 February 2015 - 10:14 PM said:

I don't think this topic is getting enough attention. Everything is all planned and ready to be used, and their are very minor drawbacks to switching to this.

I guess dan just lacks an incentive.

I don't think Dan lacks incentive. Dan is trying to juggle ComputerCraft and more importantly, Redirection (which is a really good game - go buy it guys!).

I am sure there are bugs in my code, and it isn't the neatest in the world, this isn't ready for production yet. I'm going to update CC-Tweaks to include this, and see if there is as much performance gain as I have advertised. This should help me iron out most of the bugs.

Another progress update: I've been doing a lot of work on this and have fixed most bugs. Here are some initial performance results:

LuaC
   Compilation: 0.022322
   Running: 4.056888
LuaJC
   Compilation: 0.139363
   Running: 1.921846

This is from running my AES encryptor 10,000 times. They are measured in seconds so smaller is better. This is about 40 kByte/s (LuaC) compared with 100 kByte/s (LuaJC).

If my mental maths serves me correctly: LuaJC is x2 quicker (and can be up-to 5x quicker), however it is also between 2 and 5 times slower at compiling the code. My suggestion is to lazy-load the bytecode - loadfile will run LuaC but when the function is first executed, then bytecode compilation happens. This means using loadfile to verify sources will not be very slow.

There are however, some issues:

Error messages
The original version reported error messages in the form: function ffffff: Error message rather than chunkname:line: Error message. I've fixed that, though in a very hacky way. Every line executed sets the current line number of the function to be the a line. This will totally break if co-routines or recursive functions are abused so I need to think of a better way. Line number debug info is also stored in the class (Like normal Java classes) so it might be possible to get a stack trace and parse it, though I'm not hopeful.

The alternative would be to create a HashMap style element for LuaThreads so we store the line number for each thread. This shouldn't be any slower than the current method.

Debug API:
Whilst be don't have access to it, CC uses it to force a yield every 100000 instructions. Debug hooks on instructions or lines will not work any more, and so this will have no effect. ComputerThread will still force an abort, though I don't know if that will still have the desired effect. Any feedback from people more knowledgeable about Java threading than me would be ideal. I don't know if wrapping stuff in lots of pcalls would catch InterruptedExceptions.

Slow:
Oh my, oh my. This is slow. I've talked a bit above about strategies to prevent compilation being slow having too big an effect, but I think this really needs to be sped up a lot more to be worth file implementing this.

As before the code is on GitHub, so please send me a pull request with some fixes if you have any, PM me, or post a message here.

SquidDev, on 08 February 2015 - 12:42 PM said:

Another progress update: I've been doing a lot of work on this and have fixed most bugs. Here are some initial performance results….
Slow:
Oh my, oh my. This is slow. I've talked a bit above about strategies to prevent compilation being slow having too big an effect, but I think this really needs to be sped up a lot more to be worth file implementing this.

The thing is, the majority of times you're RUNNING programs on CC, not loading them. So a 2x performance increase is definitely worth–what, 1 1/2 seconds of wait?

A bit of a bump, a bit of a progress update. I've fixed most of the above issues. Some of you may have seen I've written a mod that implements this compiler so I would really appreciate it if people used it, just to help iron out the bugs.

The performance increase is pretty impressive. Tracebacks work perfectly, compilation is slightly quicker now, it takes about 0.08 seconds for one 19kB file which is pretty impressive. string.dump is implemented as of today so I think this is ready for normal use. The one remaining issue is with the debug hook on instructions, though some this could be done on function calls/returns instead.

---

Edit (August 2015):
For those who are interested, the source now exists at luaj.luajc instead of being embedded in CCTweaks.
There is, however, a bug that I cannot fix (not for want of trying). If you are interested in continuing this, or have
any other performance ideas do PM me.

Edit (January 2016)
I fixed the above bug (typically a 1 line fix), this will be integrated in the new CCTweaks version.