Does someone have a reason why VM based real multithreading would have better performance?
Lanes can do stack-to-stack copying of values at thread creation, and return value fetching, since the other thread is not running free at those cases. Therefore, I don't see that VM support would significantly change anything. Maybe on systems which do a lot of message passing, something can be done. Other than that, the whole of Lua will fit in modern CPU's cache, and all the OS threads will use the same code.
Jailing user-provided code and simplifying programming are surely benefits. Even when running on a single core CPU. But also extension module based multithreading offers them conveniently.
-asko Rob Kendrick kirjoitti 13.8.2007 kello 22:20:
Asko Kauppi wrote:To take this thread ;) in a helthier direction... Can you please list such tasks, where built-in pre-emptive parallelism would have been useful. My curiosity is as the author of Lanes, wanting to know what couldn't be achieved by the current, extension module based approach. "Certain tasks" was too vague.Well, I've certainly wished for similar when writing systems that needto run user-provided code at the same time as other user-provided code.Also, while in most cases you could use co-routines, having a pre-emptive system simplifies the programmer's task, and having themimplemented in the VM would yeild significantly better performance thanjust using the OS's threads, I'd expect. B.