798 replies to this topic

[ElvishJerricco]

Creator, on 30 November 2015 - 06:59 PM, said:

Running it on Java would be slow. Isn't there a C/C++ implementation? I believe it'd be faster.

This is a common misconception about Java. It isn't slow. According to benchmarks, it's actually quite fast. The JIT makes it able to keep up with C in real world applications. Occasionally, Java can even beat C, because of its ability to consolidate optimizations between libraries (optimizations through dynamic linking). Truthfully, it will often be on the wrong side of C, and perform marginally slower. But it's forgivable, and still very fast.

Java's performance problems come in the way of the garbage collector, and programming poorly for it. Minecraft is so much less performant than its Win10 and mobile C/C++/C# (whichever it is) equivalents because those versions have been properly optimized, and aren't destroying a GC. Java Minecraft is written such that it hammers the GC, which slows it down significantly.

That said, I have no evidence to claim whether LuaJ is slower or faster than Lua. That's dependent on how well / poorly LuaJ and Lua are written. I'd have to look at benchmarks.

Edited by ElvishJerricco, 01 December 2015 - 03:52 PM.

[SquidDev]

ElvishJerricco, on 01 December 2015 - 12:02 PM, said:

That said, I have no evidence to claim whether LuaJ is slower or faster than Lua. That's dependent on how well / poorly LuaJ and Lua are written. I'd have to look at benchmarks.

Based off the benchmarks for LuaJ 3.0 some elements run faster, most run slower than native Lua (some are up to half the speed). LuaJC is much faster than Lua, but is still beaten by Lua on some benchmarks. There are some elements of LuaJ which could be optimised - I guess it could also be possible to write a runtime JIT compiler for LuaJ like JRuby has.

[FUNCTION MAN!]

I'd rather see it using LuaJIT than the alternatives. It beats HotSpot by miles, and most times is faster than C for common applications, in both dev-time and run-time.

[Creeper9207]

Looks like a CC is being made for 1.8 as well

Edited by Creeper9207, 01 December 2015 - 10:52 PM.

[FUNCTION MAN!]

Yea, but that's boring CC.

[Bomb Bloke]

Sounds like good news to me, but I DO hope that the monitor and bit API bugs are fixed for MC 1.7.10.

[FUNCTION MAN!]

Bomb Bloke, on 02 December 2015 - 12:41 AM, said:

Sounds like good news to me, but I DO hope that the monitor and bit API bugs are fixed for MC 1.7.10.

Ah, yes, that would be good news indeed.

[oeed]

Yeah, it was a CC update after all.

https://twitter.com/...824488883965954

Sounds like it'll delay CraftOS 2.0 by a few weeks, but it'll certainly be a great update.

[SquidDev]

Are we allowed to do feature requests? (I know suggestions exists, but most of these have been said there before and I don't want to bump topics).

Lua 5.2
I know Dan has mentioned it - 1.8 is such a change for most mods that I feel it would be fine breaking most programs too. Then we also suffer the pain of updating our code to 1.8! Also I love _ENV, and LuaJ 3.0 is multithreaded.

Binary fix
Its possible, just a pain to do. Something like CCTweaks's IArguments to handle both binary and string arguments would be nice.

Bit operators fix
This is just the matter of casting to long then int. Also, Lua 5.3 uses longs (64 bit) instead of 32 bit integers, so it would be nice to have a bit64 library as well as a bit32 one.

Network API
So CCTweaks doesn't have to. Puppy eyes

I'm really grateful that Dan has started the port (and to those who have sponsored him).

Edited by SquidDev, 02 December 2015 - 05:10 PM.

[apemanzilla]

SquidDev, on 02 December 2015 - 05:10 PM, said:

Are we allowed to do feature requests? (I know suggestions exists, but most of these have been said there before and I don't want to bump topics).

Lua 5.2
I know Dan has mentioned it - 1.8 is such a change for most mods that I feel it would be fine breaking most programs too. Then we also suffer the pain of updating our code to 1.8! Also I love _ENV, and LuaJ 3.0 is multithreaded.

Binary fix
Its possible, just a pain to do. Something like CCTweaks's IArguments to handle both binary and string arguments would be nice.

Bit operators fix
This is just the matter of casting to long then int. Also, Lua 5.3 uses longs (64 bit) instead of 32 bit integers, so it would be nice to have a bit64 library as well as a bit32 one.

Network API
So CCTweaks doesn't have to. Puppy eyes

I'm really grateful that Dan has started the port (and to those who have sponsored him).

What do you mean by network API?

[Creator]

Like TCP and stuff. Enhanced HTTP.

[SquidDev]

Creator, on 02 December 2015 - 07:23 PM, said:

Like TCP and stuff. Enhanced HTTP.

No (though I'd like it and CCTweaks also does it). Actually I meant the ability to extend the wired network with custom components - it is a really useful thing for mod developers to be able to do. Also a turtle refuel API.

Edited by SquidDev, 02 December 2015 - 08:29 PM.

[Creator]

SquidDev, on 02 December 2015 - 08:28 PM, said:

Creator, on 02 December 2015 - 07:23 PM, said:

Like TCP and stuff. Enhanced HTTP.

No (though I'd like it and CCTweaks also does it). Actually I meant the ability to extend the wired network with custom components - it is a really useful thing for mod developers to be able to do. Also a turtle refuel API.

But CC2.0 will be outside of MCN, then why an enhanced modem API?

[apemanzilla]

SquidDev, on 02 December 2015 - 08:28 PM, said:

Creator, on 02 December 2015 - 07:23 PM, said:

Like TCP and stuff. Enhanced HTTP.

No (though I'd like it and CCTweaks also does it). Actually I meant the ability to extend the wired network with custom components - it is a really useful thing for mod developers to be able to do. Also a turtle refuel API.

Ah, yes, both of those would be useful. I assumed you meant an in-game API.

[SquidDev]

Creator, on 02 December 2015 - 08:41 PM, said:

But CC2.0 will be outside of MCN, then why an enhanced modem API?

I was talking about the pending 1.8 release - this has become more of a "look what Dan has tweeted" thread.

[Bomb Bloke]

SquidDev, on 02 December 2015 - 05:10 PM, said:

Lua 5.2
I know Dan has mentioned it - 1.8 is such a change for most mods that I feel it would be fine breaking most programs too. Then we also suffer the pain of updating our code to 1.8!

Truth be told, we can already make a start on such updates; there's a config option in ComputerCraft.cfg which attempts to disable all 5.1-specific functions in favour of their 5.2 counterparts.

Beats me how "complete" the conversion is, but I'd wager it's sufficient for most scripters to get their compatibility tweaks in place before 5.2 appears for reals.

[FUNCTION MAN!]

I personally really don't care about Lua 5.2. Lua 5.3 is where it's at! Bitwise operators and utf8 and actual integers yes please.

[Creeper9207]

Does LuaJ support java 8 or just 7?

[Bomb Bloke]

Most software compiled under an older JDK will operate just fine with a newer JRE. Heck, I still use Java 6 to build the few classes I make (though I'm obviously a bit better about keeping my runtime environments up to date). Granted, compatibility isn't 100% for all programs, but it's pretty good.

In the case of LuaJ, I'm using it just fine under Java 8. I suspect over half of ComputerCraft's userbase is doing the same.

[Lupus590]

I use java 8 for Minecraft (and everything else) not had any problems caused by it yet.