Luvit - Lua + UV + Jit = NodeJS re-implemented in Lua(lua-list.2524044.n2.nabble.com)
lua-list.2524044.n2.nabble.com
Luvit - Lua + UV + Jit = NodeJS re-implemented in Lua
http://lua-list.2524044.n2.nabble.com/ANN-Luvit-Lua-UV-Jit-NodeJS-re-implemented-in-Lua-td7048032.html
11 comments
Coroutines are available in Node via the fibers package (https://github.com/laverdet/node-fibers). For benchmarks comparing performance to purely asynchronous webapps, check out the README to my Common Node project (https://github.com/olegp/common-node), which implements a number of synchronous CommonJS proposals on Node using fibers.
My opinion about the common thought saying "NodeJS forces you to code many callbacks that seem ugly" is that some people hesitate to abstract that functions.
Also take a look at OpenResty, which bundles LuaJIT for Lua/nginx-based web app development, using the nginx event loop to do async I/O:
OpenResty aims to run your server-side web app completely in the Nginx server, leveraging Nginx's event model to do non-blocking I/O not only with the HTTP clients, but also with remote backends like MySQL, PostgreSQL, Memcached, and Redis.
http://openresty.org/
OpenResty aims to run your server-side web app completely in the Nginx server, leveraging Nginx's event model to do non-blocking I/O not only with the HTTP clients, but also with remote backends like MySQL, PostgreSQL, Memcached, and Redis.
http://openresty.org/
Wow.
OpenResty seems to offer considerably lower app connect time compared with bare PHP in a FastCGI process manager for this "hello world" benchmark, in addition to some unbelievable throughout.
Data rounded for easier comparisons. See the gory details at http://openresty.org/#Benchmark
Thanks for the pointer!
OpenResty seems to offer considerably lower app connect time compared with bare PHP in a FastCGI process manager for this "hello world" benchmark, in addition to some unbelievable throughout.
app GETs/sec throughput time to 1st byte, min/mean/max, milliseconds
Nginx + PHP/FPM 5,941 65KB/sec 0.72 / 1.63 / 6.75
Node 0.6.1 10,242 123KB/sec 0.08 / 0.92 / 14.24
OpenResty 27,924 335KB/sec 0.07 / 0.26 / 5.36
Data rounded for easier comparisons. See the gory details at http://openresty.org/#Benchmark
Thanks for the pointer!
Dahl's original reason for preferring JS to Lua was apparently that Lua had too many blocking libraries already:
No matter what I did, someone was going to load an existing blocking Lua library in and ruin it.
No matter what I did, someone was going to load an existing blocking Lua library in and ruin it.
Indeed, this is a problem. I've mitigated it somewhat by changing how require works (to be more node-like) and disabling the built-in I/O library. This will make most offending libraries unable to run in Luvit. Also this means I don't get the large existing community of modules either.
I understand that this project is very immature compared to Node.js, but how does it compare performance-wise?
Can modern Lua virtual machines outperform V8?
Can modern Lua virtual machines outperform V8?
LuaJIT could do this a long time ago already
http://news.ycombinator.com/item?id=1187901
Alright after some research I fould that LuaJIT is way faster than V8:
V8: node fib.js 6.40s user 0.02s system 99% cpu 6.423 total LuaJIT: ./luajit fib.lua 2.02s user 0.00s system 99% cpu 2.026 total
http://www.saltwaterc.eu/but-the-question-is-will-it-recur-p...
V8: node fib.js 6.40s user 0.02s system 99% cpu 6.423 total LuaJIT: ./luajit fib.lua 2.02s user 0.00s system 99% cpu 2.026 total
http://www.saltwaterc.eu/but-the-question-is-will-it-recur-p...
[deleted]
The only thing I see if from the official Github page : "This project is still under heavy development, but it's showing promise. In initial benchmarking with a hello world server, this is between 2 and 4 times faster than nodeJS."
Memory usage should be lower too.
Indeed. In that benchmark I did, it was 2 times faster on 32-bit linux and 4 times faster on 64-bit linux. In both the Luvit version used about 40x less ram. Also startup time is much faster in Luvit. This doesn't matter as much for servers, but for embedded devices like writing webOS games for the TouchPad, it makes all the difference in the world!
Node depending on how you build it can take between 300 and 1000 ms of time and 10Mb of ram to just start up on the TouchPad. Luvit starts instantly and uses much less ram.
Larger programs are needed to see how the memory usage and performance scales with real work. That could be completely different.
Node depending on how you build it can take between 300 and 1000 ms of time and 10Mb of ram to just start up on the TouchPad. Luvit starts instantly and uses much less ram.
Larger programs are needed to see how the memory usage and performance scales with real work. That could be completely different.
Lua uses memory efficiently at scale.
I have used Lua at the command line on machines with 64GB of RAM to do ad hoc data mining that would have otherwise required several days of prep time for writing and debugging C before each run.
Using Lua, I could do things in hours that used to take overnight, or several days.
I have used Lua at the command line on machines with 64GB of RAM to do ad hoc data mining that would have otherwise required several days of prep time for writing and debugging C before each run.
Using Lua, I could do things in hours that used to take overnight, or several days.
You mean how fast can it compute fib(40) without memorization? ;)
Did you mean memoization? http://en.wikipedia.org/wiki/Memoization ;)
Without memoization. Also, these benchmarks forgo tail recursion as well, which is even less forgiveable.
It's a much leaner VM and it much faster and uses less memory in all my tests. However Lua and JS aren't the same language so real applications may show something different.
"I understand that this project is very immature compared to Node.js"
Good thing you added "compared" there, because I wouldn't call Node.js exactly "mature".
Good thing you added "compared" there, because I wouldn't call Node.js exactly "mature".
What makes languages like Python so great is the stdlib that goes with them -- I hope that projects like this can help grow Lua into a more mainstream language.
Lua Rocks is quite interesting. A lot of the ground work that was done for server-side JavaScript after Node became popular already exists, as do many modules. So you "just" need to add more, not invent something spanking new.
Never mind that I don't think this will make huge inroads. The big thing about NodeJS is that it's JavaScript, so that some frontend coder could use his already existing knowledge to quickly make a high-performing web service. And it came out with just enough hype to make it popular and create a community.
Lua doesn't really have those advantages. I do like the language a lot better than the mess that's JavaScript, but if a bunch of young coders are looking at a tool to fill a gap in their tech stack, it's not that likely that they'll look for Lua, unless they're all WoW extension programmers…
[1]: http://luarocks.org/
Never mind that I don't think this will make huge inroads. The big thing about NodeJS is that it's JavaScript, so that some frontend coder could use his already existing knowledge to quickly make a high-performing web service. And it came out with just enough hype to make it popular and create a community.
Lua doesn't really have those advantages. I do like the language a lot better than the mess that's JavaScript, but if a bunch of young coders are looking at a tool to fill a gap in their tech stack, it's not that likely that they'll look for Lua, unless they're all WoW extension programmers…
[1]: http://luarocks.org/
Maybe I am biased coming from another gaming community (Facepunch / Garry's Mod) but speaking for myself (as a young coder/developer) I like Lua.
As I wrote above, I like it a lot, too. It's a very simple, clean language without any silly flourishes, a good implementation and easily added to most projects.
But in your average web shop, the chances of finding someone who has already worked with it is pretty low, whereas JavaScript itself runs at about 100%. And I firmly believe that this is the biggest reason for the popularity of NodeJS. Not the concept (cf. eventlet, EventMachine, POE etc.), but the fact that you've been offered a simple package where you don't have to learn anything really new.
Still, I'm grateful for an extended toolkit myself, and I'm looking forward to what people can do with coroutines and tables to make the programming experience more pleasant.
But in your average web shop, the chances of finding someone who has already worked with it is pretty low, whereas JavaScript itself runs at about 100%. And I firmly believe that this is the biggest reason for the popularity of NodeJS. Not the concept (cf. eventlet, EventMachine, POE etc.), but the fact that you've been offered a simple package where you don't have to learn anything really new.
Still, I'm grateful for an extended toolkit myself, and I'm looking forward to what people can do with coroutines and tables to make the programming experience more pleasant.
Maybe this could leverage the Lua/APR binding to get a starting stdlib?. Modules like xml, crypto, base64 and memcached would round it up nicely, not sure about the IO and threading ones, perhaps those are redundant to luvit.
memcached would presumably be an issue because of it not being non blocking, so you would want a smaller subset.
Interesting, also it worth mentioning ngx_lua https://github.com/chaoslawful/lua-nginx-module It's like a swiss army knife for nginx.
I've looked at the lua/nginx integration a while ago, an all the examples struck me as somewhat confusing. A lot of work was done using lua as inline nginx configuration (or just normal nginx config). Mongrel2's Tir[1] looked a lot cleaner and better documented.
[1]: http://tir.mongrel2.org/
[1]: http://tir.mongrel2.org/
and also https://github.com/ezmobius/super-nginx, an even bigger Swiss Army knife.
I really love how this project copies how the node require resolution works. That is by far my favorite thing about node and it lets programmers do version management and reusability really well.
It's also worth mentioning Ignacio Burgueño's LuaNode, an older project with similar goals:
https://github.com/ignacio/LuaNode
https://github.com/ignacio/LuaNode
It is interesting that javascript and lua are so similar in many ways, while one was hacked together in a few weeks and the other one was carefully designed by an academic.
They both have the same root business case: make Scheme palatable to mere mortals, by adding a familiar syntax and abandonning some features: no more macros, and most data structures made mutable.
Where Lua diverges from Javascript:
* time has been taken to design it properly;
* backward compatibility has been broken more than once, to allow cleaning up design mistakes.
Also, it's not accurate to describe Lua as "designed by academinc": early developments have been driven by Petrobras' needs, more recent ones by the gaming industry and some prominent users such as Adobe's Photoshop Ligthroom. If you look at Lightroom team's rants about Lua 5.0 (http://www.lua.org/wshop05/Hamburg.pdf), then at the Lua 5.0 -> Lua 5.1 diff, you'll see that the latter is closely inspired by the former.
Where Lua diverges from Javascript:
* time has been taken to design it properly;
* backward compatibility has been broken more than once, to allow cleaning up design mistakes.
Also, it's not accurate to describe Lua as "designed by academinc": early developments have been driven by Petrobras' needs, more recent ones by the gaming industry and some prominent users such as Adobe's Photoshop Ligthroom. If you look at Lightroom team's rants about Lua 5.0 (http://www.lua.org/wshop05/Hamburg.pdf), then at the Lua 5.0 -> Lua 5.1 diff, you'll see that the latter is closely inspired by the former.
Traditionally in Scheme all data structures are mutable (the PLT folks made the gutsy move of making conses immutable only recently and they're basically the only ones doing that, I think), so no difference there. But both Lua and JavaScript are organized around hashtables rather than lists; maybe that's the biggest difference data structure-wise.
the devil in the details
With MoonScript you even have CoffeeScript there.
http://moonscript.org/
http://moonscript.org/
I really hope someone will do the same with Io. Such a lovely little language.
Being able to use Lua's coroutines makes this quite interesting.
https://github.com/luvit/luvit/blob/master/examples/fs-corou...