An idea on multithreading implementation

[Jeffrey Massung]

On Jan 28, 2011, at 7:59 AM, Geoff Canyon Rev wrote:

> On Fri, Jan 28, 2011 at 1:16 AM, Jeffrey Massung <massung at gmail.com> wrote:
> 
>> 
>> Coroutines have absolutely no advantage over what's already provided by LC.
>> There's zero difference between saying "yield()" and "wait 0 ticks with
>> messages".
>> 
> 
> I realized that, apart from the fact that this isn't true, ....

It is. I'm sorry. I wish it weren't. :-(


>> The purpose of mutli-threading is to take advantage of one or more of the
>> following: a completely separate hardware thread (program/code runs 100% in
>> parallel with another program/set of code - the only bottlenecks being
>> memory and I/O) or preemptive threading, typically by way of hyper-threading
>> on a single hardware thread (basically letting the hardware or OS decide
>> when to context switch for you).
>> 
> 
> This is true, but it's not a fair description of the current limitations of
> livecode. Currently it is very difficult simply to program any sort of
> background task whatsoever: processing a log file, making aliens attack,
> etc. "wait 0 ticks" simply isn't a good answer for those sorts of issues.
> Ask Malte what he could do for animationEngine (and how much more simply)
> with coroutines.

Agreed that "wait 0 ticks" isn't a good solution to these sorts of issues, and I wasn't trying to imply that it was (if my original email came across that way).


> [... Snipped some iPhone video game examples ..]
> 
> I'd be happy to be proven wrong.

Coroutines are not pre-emptive. They are called "cooperative threads" because you have to manage them with your own scheduling. That means yielding within a single hardware thread, which means you get no more benefit out of them than what LC already provides (except maybe a slightly different engine architecture that *might* be faster, but that's unprovable - or disprovable - by us without the LC source code). This isn't to say coroutines aren't great - Lua and other languages use them to much fanfare. Just that you pretty much have them already.

As far as games go, I also have to disagree there (that LC will always be too slow by orders of magnitude). This is an area I know a *lot* about and do this for a living. Now, I'm not suggesting that LC is what I would jump up and down to use to make my next video game with, but most video games are broken into two bits: simulation and rendering. 

As long as someone took the time to make an OpenGL plugin for LC, rendering could be made fast enough for most simple 2D games (the real issue would be the fact that "Everthing Is A String" in LC - and manipulating matrices with strings would be **SLOW**). So that leaves simulation. 

The problem with yielding (or "waiting" in LC terms) is that it basically puts me back into the Atari 2600 days of cycle counting, without the precision of being able to actually count cycles ;-). I have no idea how often I should yield in order to make things nice and smooth. It would be SOOO much more convenient if I could just make LC pre-emptive and wait for me like so:

send "renderFrame" to me every 30 milliseconds

And I'm done with it. It's like pretending to be a fake "green thread". All I care about is that it's pre-emptive. Anyway, I'd love to talk about this more offline if you want -- just shoot me an email. 

Summary:

* What people seem to want here is pre-emption (however that happens).
* Coroutines are cooperative threads, which means they are not pre-emptive.
* If you have to yield, it doesn't matter how many HW threads you use.

Jeff M,