David Given wrote:|
And it compiles into real machine code, which is a huge plus; ix86, amd64 and ARM, too. I don't know what the code is like, though.
Well, we've got x86 in the form of LuaJIT (with version 2.0 looking pretty damn good).
On the lack of ARM support in LuaJIT 2.0 (& 1.x for that matter), I've often wondered why Mike Pall didn't use an existing assembler library. NanoJIT has (to my knowledge) the capability of producing ARM, i386, X64, PPC, etc machine code. It's not the only one out there, but it's one I know from following Mozilla code blogs.
I cannot help but wonder what performance hit might prevent the usage of said assemblers of DynASM and whether the small hit might be worth it for the capability of running machine code on many chipsets rather than Intel 32 bit only.
We obviously don't need to be convinced about coroutines, but the idea of moving blocked ones to another thread is intriguing.I'm a bit dubious about that concept. Unless it's doing something clever with asynchronous I/O, it'll need to allocate a new system thread for every blocked coroutine. So if you have a system with 100000 coroutines, and 50% of them end up blocked on system calls at the same time, won't the runtime suddenly have to allocate 50000 system threads
It is my assumption that they simply have a preset number of threads running. Whenever one of these threads are "blocked" on an IO operation, coroutines in it's schedule get moved to other running threads. Say there are five threads, that means I can have five coroutines running simultaneous IO operations before the application blocks. This is not going to help much in IO-focused applications (like databases and the like) but not only would it be better than nothing, but the average application sounds like it would greatly benefit from this.
That said, I don't see how Lua could benefit from the concept. The coroutines are strongly bound to their global Lua state, which is tied to one thread at a time only. If there were a cheap way to move coroutines between states (assuming they make no reference to the global environment) - this would make an awesome modification to the basic Lua VM.
-- Regards, Benjamin Tolputt Analyst Programmer