Re: Is Lua the next big thing?

[Asko Kauppi <askok@...>]

Initial tests on Lua Lanes, run yesterday on a Core Duo MacBook:

	2000 calls in single thread:		29.72 real 29.47 user 0.09 sys
	2000 threads (and Lua states):		18.60 real 33.26 user 1.43 sys

That means -38% conceived time (18.6 vs 29.7 seconds), while +18% CPU  
cycles (and thus power consumption). The percentages will vary a lot,  
based on how much data is passed between the states.

Thread initialization itself is plenty fast, here are times for  
launching 5000 threads with differing stdlib support:

    no libs:		0.99 real 0.46 user 0.92 sys
    base+math:	1.14 real 1.06 user 0.94 sys
    all stdlibs:		2.06 real 2.82 user 0.97 sys

In the future, serialization code can be optimized to further enhance  
the multicore usability.

-asko


Sam Roberts kirjoitti 14.3.2007 kello 22:28:

> On Tue, Mar 13, 2007 at 06:31:45PM -0800, Lothar Scholz wrote:
> > For threading the answer is simple and not satisfying: There is no
> > really usefull scripting language yet. Python supports it a little  
> > bit,
> > Ruby not at all, Perl is using a fork like modell and TCL is going  
> > the
> > LUA way of complete isolated threads.
>
> Thats a pretty good summary, but alone among the Python/Ruby/Perl/Lua,
> Lua allows itself to be compiled with thread-aware locking, LuaThread
> uses this capability.
>
> Does anybody know what the granularity of this locking is? Even though
> its a feature only lua has, there is almost no published information I
> can find about it! What is the performance of LuaThread? Can it be  
> used
> profitably on a multi-core machine, for example, to get higher cpu  
> usage?
>
> Or, if you want to spin off worker threads to do file i/o operations,
> but have all your network i/o running with select-driven  
> coroutines, is
> the locking of such granularity that LuaThread is a reasonable tool?
>
> Cheers,
> Sam