On Mon, Apr 11, 2011 at 1:31 PM, Robert G. Jakabosky
<bobby@sharedrealm.com> wrote:
On Sunday 10, Benoit Germain wrote:
> 2011/4/10 Robert G. Jakabosky <bobby@sharedrealm.com>:
> > Announcing lua-llthreads 1.0 release.
>
> Hello,
>
> Since I maintain Lanes, I can't help but reflect that this is some
> sort of a Lanes subset where the inter-thread communication lindas are
> gone. But I suppose that zeromq would be usable with Lanes threads?
Originally this module had been part of my lua-zmq project, but the first
person I showed it to said that it would be interesting to see it as s
separate module (since it wasn't dependent on zmq).
> Also your documentation seems to show that the thread function must be
> provided as unparsed Lua code that will be compiled in the target VM.
This is a Low-Level threads module. People can use string.dump() or some
other serialization library if they want to pass complex Lua values to the
child thread. I wanted to keep this module as simple as possible.
> Lanes also offers this possibility, but the only reason is to start
> the path toward LuaJIT compatibility, since the other way (using
> lua_dump to move the function proto) isn't available in LuaJIT. Is
> this why you have restricted to this solution?
lua-llthreads & lua-zmq work with LuaJIT2. Lua-zmq is also optimized to use
LJ2's FFI support.
> Also, since you have
> felt the need for llthreads, there is probably some use case that is
> not properly adressed by Lanes. What would that be?
Lanes doesn't fit my needs like ZeroMQ does. I need a message passing library
that handles thread-to-thread & host-to-host communication and that supports
multiple languages [1]. Also most of the programs I write are network
services that use event loops for non-blocking network IO and ZeroMQ sockets
can be used in an event loop like normal sockets.
I ported the latency & throughput benchmarks from lua-zmq to the Lanes
interface (see the two attached lua scripts). I wasn't able to get Lanes to
work on LuaJIT2 even when using unparsed Lua code for the thread function.
Latency:
Message size: 512 bytes
roundtrip count: 1,000,000
Lanes 2.1 Lua 5.1.4:
mean latency: 10.318 microseconds.
ZeroMQ Lua 5.1.4:
mean latency: 7.027 microseconds
ZeroMQ LuaJIT2:
mean latency: 6.280 microseconds
Throughput for Lanes is much lower then ZeroMQ:
Message size: 512 bytes
message count: 1,000,000
Lanes 2.1 Lua 5.1.4:
mean throughput: 97,141 msg/second
mean throughput: 398 MBits/second
ZeroMQ Lua 5.1.4:
mean throughput: 1,275,092 msg/second
mean throughput: 5,223 MBits/second
ZeroMQ LuaJIT2:
mean throughput: 1,777,966 msg/second
mean throughput: 7,283 MBits/second
For Lanes I had to tweak the queue limit, since it was taking way to long with
the default queue length.
For smaller messages (1-30 bytes) ZeroMQ+LuaJIT2 can get above 4Million
message per second.
The above tests where run on Linux 2.6.36 x86_64 CPU: AMD Athlon II X2 250
(Dual-core 3Ghz).
Also sometime the lanes_*.lua scripts would crash with a double free error
(See the attached lanes_lat_errors.log for the output from valgrind).
1. http://www.zeromq.org/bindings:_start
--
Robert G. Jakabosky
Cool benchmarks. Cool release.
I'll have to have a play some time.
