Computers have their own thread?

Okay, before you scream that its going to cause lag because of tons of computers, know this: it could be a CONFIG OPTION!

I really hate that CC only runs one Lua only executes one thread at a time. I'm not sure if this would cause a lot of problems or not.. but I think it could be done moderately easily… (yes, i'm a programmer, I know what I'm talking about).

Like I said, if you must make it a config option, fine. Or, if each computer can't have its own thread, why not distribute them?

One at a time is just too slow when you have a lot of computers running… :/ I got to the point where I would type and a few seconds later, the character would show up. Simply because I had a large number of computers running (fairly significant code as well…). But IMHO we should be able to do that.

Opinions? Any logical reason not to do this (besides difficulty)? Could this cause issues with Rednet (pretty sure you would just have to synchronize with world tick for that..)?

I really like the idea of having this feature as a config option.

Just thought about another similar idea: there could be one LuaVM per x computers. So, if x is 10 and I have 20 computers running, there would be two LuaVMs and it would cause less computer lag.

Well, there is a Lua VM per computer. The thing I'm talking about is the event queue thread. I.e. if I yield, it may yield to another computer since the event queue is handled on one thread. There is an event queue per computer of course though. (this is all my understanding of CC, Dan may have a better explanation).

To my understanding, each co-routine gets an event queue. Each CC computer is a co-routine running within the one Lua VM. Although each already gets its own thread, only one executes at a time.

For this reason, there's an upper limit on how ComputerCraft can adversely affect the MineCraft world. If one player starts spamming computers running processor-intensive loops, then that only slows down other ComputerCraft systems - the MineCraft world itself won't lag out and die.

(I don't think there are any such restrictions on ComputerCraft's RAM usage, but it's not something I've looked into.)

It seems to me that if you've got enough code running that typing characters into a given system takes seconds, then running multiple threads at once isn't going to help matters (not unless those threads are being spread over cores) - ultimately, there's a real processor somewhere under all those software layers, and you're causing it to struggle.

I strongly suspect that an all-around better solution would be to lower the processor requirements of your other systems. The worst cases I see are typically scripts that make use of sleep within infinite loops when other options are available (or, if there aren't, they don't sleep nearly long enough!).

Okay but if I run TONS of small programs, the same thing will happen.

Also, this depends on how you define "Lua VM" … you're right that a computer runs in a coroutine. The "Lua VM" is simply a bunch of LuaValue objects… its not like theres a "LuaVM" object. Either way though, each coroutine does not get its own event queue (within CC). Each computer does.

This is why if there are tons of computers running, it takes longer because the event queue is global. Thus it runs serially through the computers.

If each computer had a thread to handle its event queue, the limiting factor would be the computer, not all of them.

Like I said, there isn't any reason (that anyone has said) to make this a config option. Not saying it would be "easy" either, but I think it would be VERY worth the effort on the CC team's part…

The thing where tying chars into the system was a problem: if I stopped a bunch of other computers running the same thing (80+), it worked PERFECTLY. It it an issue of number, more than code size. If I have small code, it will just take more computers to get the same effect.

Also, as far as core count and how that relates to this: yeah, If you have few cores it won't help as much. Still though, its better than all of it in one single loop.
Also, I have 4 cores so.. :P/> (not that that's in any way related to this though)

I definitely agree with Bomb Bloke on this one, opening up the computer threads to be running concurrently would open up more problems than it solves. Particularly with taking away processing power from Minecraft itself, reducing TPS, and in turn reducing the response rate of the Computers. 'Attacks' could happen on servers where in people could just start up lots of computers and lag out the entire world, as opposed to lagging out the ComputerCraft thread.

As Bomb stated, you've got to remember that there's a CPU under it all! Potentially a single-core machine.

Bomb Bloke, on 12 October 2014 - 02:00 AM said:

I don't think there are any such restrictions on ComputerCraft's RAM usage, but it's not something I've looked into.

No there isn't, but if you manage to fill it, you're doing good!

sci4me, on 12 October 2014 - 02:07 AM said:

Either way though, each coroutine does not get its own event queue (within CC). Each computer does.

Eh what? If I fire up a bunch of co-routines on a single system, each gets their own queue, containing only the events I let into it.

sci4me, on 12 October 2014 - 02:07 AM said:

The thing where tying chars into the system was a problem: if I stopped a bunch of other computers running the same thing (80+), it worked PERFECTLY. It it an issue of number, more than code size. If I have small code, it will just take more computers to get the same effect.

I'm not saying reducing your code length is a good idea. I'm saying reducing your code's processor usage is a good idea. Think about how you can rig things to ignore events more efficiently. Personally I try to have as few systems handle as many tasks within the one script as possible.

But what do I know - I haven't seen this code you've got your 80 systems running, after all. I'd like to, though. :)/>

Bomb Bloke, on 12 October 2014 - 02:28 AM said:

sci4me, on 12 October 2014 - 02:07 AM said:

Either way though, each coroutine does not get its own event queue (within CC). Each computer does.

Eh what? If I fire up a bunch of co-routines on a single system, each gets their own queue, containing only the events I let into it.

sci4me, on 12 October 2014 - 02:07 AM said:

The thing where tying chars into the system was a problem: if I stopped a bunch of other computers running the same thing (80+), it worked PERFECTLY. It it an issue of number, more than code size. If I have small code, it will just take more computers to get the same effect.

I'm not saying reducing your code length is a good idea. I'm saying reducing your code's processor usage is a good idea. Think about how you can rig things to ignore events more efficiently. Personally I try to have as few systems handle as many tasks within the one script as possible.

But what do I know - I haven't seen this code you've got your 80 systems running, after all. I'd like to, though. :)/>

Not sure if I misunderstand or something.. actually yes, I do. I meant that there is an actual event queue in CC's code which handles the coroutine queues.

Right, I get that… but.. meh.

I had like 80+ systems running a fairly large OS. :P/>


I see no reason to not make it a config option. And if someone has 1 core, they have some serious problems and shouldn't be playing the game! :P/>

Although it seems most reasonable to just not implement this, I think the idea's worth entertaining. As said above, this could easily flood a server, so there needs to be some sort of restriction on the number of threads that can be running. The idea's already been tossed out that maybe there could be X computers per thread. What if on top of that effect, there's a max thread limit? Each time a computer loads up, put it on a thread with less than X computers on it. If no such thread exists, add a new thread unless there's already Y threads, in which case you just start adding more than X computers to threads.

All that said, I don't think its worth implementing. It's complicated and poses several problems.

authough I agree it is complicated to add I do see a lot of potential for it… perhaps you could set how many threads should run at once and the server/client spreads these out evenly… the amount of threads to be used could probably even be set automatically based on your system specs… (I don't really know much about java so that may not be possible but I doubt it wouldn't be) … and then you could adjust it manually if wanted… since an auto-setting method would be in place here, the issue of it nuking an entire server from lag is virtually eliminated… if you edit the setting and that screws your server then its your fault… end of… I think this should be added even if it would be difficult…