Even though we occassionally talk about Lua on HN, it frankly still doesn't get enough attention - nor does Mike Pall and his fantastic work on LuaJIT.
Please considering sponsoring [1] LuaJIT so that Mike can continue working on it.
Lua Fun looks like a wonderful addition to the Lua ecosystem.
> Even though we occassionally talk about Lua on HN, it frankly still doesn't get enough attention - nor does Mike Pall and his fantastic work on LuaJIT.
Because most HNers are web developers and care only about the browser.
Lua is really strong in the game developer community.
Yes, but usually in the context of web development as these are common server side languages for web apps.
pjmpl just meant we don't see a lot of game developer content on here, which is largely a C++ dominated area (with Lua game scripting becoming a lot more common).
openresty is getting a lot more attention with web developers. and I think its actually strongest in the "other" category but a lot is not very public.
The initial idea was to make a functional library that works best with tracing JIT compiler. Functional paradigm on tracing JIT is the core innovation in the project.
Lua 5.1 can run fun.lua after minor changes (I'll make patch soon), but I am not sure that performance will be good enough.
Do you think the performance is really going to be that bad in the regular Lua interpreter? I wonder if its going to be better or worse than the underscore.lua approach of using arrays instead of iterators.
Also, are you using lots of 5.1 specific stuff (setfenv, ...) or would this also be easily ported to 5.2?
The library code is Lua 5.1 compatible (except bitwise functions in "operator" submodule, but it can be easily replaced with "bit32" or even removed).
Some high-order functions heavily use recursion just to support multireturn iterators (yes, you can use multireturn with map, reduce, filter and so on). I plan to benchmark these parts and add optimized versions for non-JIT Lua if necessary.
I will try to make a patch in the next couple of days.
Thanks for your interest!
There is a BIG difference between Lua Fun and Underscore.
Lua Fun is based on iterators. High-order functions such as map, filter, etc. don't create temporary tables and don't allocate extra memory.
Since all operations are performed on the fly during iteration, most expressions use constant amount of memory to evaluate.
You should use it for all of what you use Python for. Python is a sinking language, that has taken too much input from a community of bikeshedders, to the point it can barely move. LuaJIT makes PyPy look like a high school technology project.
Yeah, the library has some common functions with "itertools" Python's module [1]. fun.range syntax was even copied from Python's range. What is more, you can also take a look on Haskell's Data.List [2] or StandardML's List [3] packages.
probably not. this is the first time I have seen the outcome of optimising this type of code. I knew it was possible as it optimises my tail recursion.
The point is not about expressiveness; it's that while this code composes several higher-order functions, it's compiled into the kind of assembly code you'd expect from a fully optimized C routine.
It's quite interesting to see essencially the ideas used in stream fusion [1] to produce practically the same results produced in Haskell, avoiding allocations and often making it much easier for the compiter ro produce vectorised code. At least that's what it looks like to me, correct me if I'm wrong.
Edit: [3] has a good exlanation of how stream fusion works, and it should make it clearer why the linked code appears to be doing the same thing.
see also here[2] for a further paper on stream fusion being used to produce vectorised code. I've linked to the reddit comments because there's some useful discussion there too.
according to antirez, redis does not (and will not) support LuaJIT. Even though at one point there was someone who had got it working. From experience I know that replacing Lua with LuaJIT, even in a statically compiled project, is quite easy. The reasoning is of course that lua code for redis shouldn't have to do a lot of processing, and thus won't benefit from the extra performance (it also shouldn't run long enough for the JIT to come into action).
33 comments
[ 5.1 ms ] story [ 95.0 ms ] threadPlease considering sponsoring [1] LuaJIT so that Mike can continue working on it.
Lua Fun looks like a wonderful addition to the Lua ecosystem.
[1] http://luajit.org/sponsors.html
Because most HNers are web developers and care only about the browser.
Lua is really strong in the game developer community.
pjmpl just meant we don't see a lot of game developer content on here, which is largely a C++ dominated area (with Lua game scripting becoming a lot more common).
All of them languages which are mostly used for web.
Any particular reason for that?
Lua 5.1 can run fun.lua after minor changes (I'll make patch soon), but I am not sure that performance will be good enough.
Also, are you using lots of 5.1 specific stuff (setfenv, ...) or would this also be easily ported to 5.2?
Some high-order functions heavily use recursion just to support multireturn iterators (yes, you can use multireturn with map, reduce, filter and so on). I plan to benchmark these parts and add optimized versions for non-JIT Lua if necessary.
I will try to make a patch in the next couple of days. Thanks for your interest!
http://mirven.github.io/underscore.lua/
Two more up-to-date forks can be found here....
- https://github.com/jtarchie/underscore-lua
- https://github.com/mark-otaris/underscore.lua
NB. The jtarchie fork seems best because its got 59 stars & 5 contributors.
[1] http://docs.python.org/2/library/itertools.html [2] http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Li... [3] http://www.standardml.org/Basis/list.html
Take this example containing functional composition and higher-order functions:
reduce(operator.add, 0, map(function(x) return x^2 end, range(n)))
LUA converts this into 10 lines of assembler (2 jumps). Also, the LUA compiler is directly generating SSE.
Anyone have any good benchmarks comparing simple functional examples in LUA with Clojure or Common Lisp?
Is -- calculate sum(x for x^2 in 1..n) a comment or is it the output of a code transform?
The point is not about expressiveness; it's that while this code composes several higher-order functions, it's compiled into the kind of assembly code you'd expect from a fully optimized C routine.
Edit: [3] has a good exlanation of how stream fusion works, and it should make it clearer why the linked code appears to be doing the same thing.
see also here[2] for a further paper on stream fusion being used to produce vectorised code. I've linked to the reddit comments because there's some useful discussion there too.
[1] http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7...
[2] http://www.reddit.com/r/haskell/comments/1br0ls/haskell_beat...
[3] http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c...
http://www.tarantool.org/