Interesting stuff
Terra – a low-level counterpart to Lua
11–20 of 49 posts
Re: Terra – a low-level counterpart to Lua
#12This fits perfectly with my desire to work on a lower level lisp with out having to work entirely in C. Great work!
Re: Terra – a low-level counterpart to Lua
#13As a speaker about Lua, this is awesome news. Yet, it also feels kinda pointless, most Lua use right now is in embedded interpreters in other software, and Terra would be hard to use, since most projects probably won't incorporate it at all.
Isn't that true of every new language project though?
More or less.
When it is a new language, you fight for space into another languages turf, your "potential" is illimited, if your language is better, it will win.
This language is obviously made to use with Lua and C at the same time, kind of a bridge of sorts, and thus it has much more limited scope and utility, and many of the uses of Lua even if they might need Terra performance, they cannot shoehorn Terra on their interpreter.
For example for coders of Corona SDK, or WoW, or many other game engines and application SDKs out there that rely on Lua.
Re: Terra – a low-level counterpart to Lua
#14> The keyword 'terra' introduces a new Terra function. Why would anyone do this? What's wrong with func, function, def, etc. ?
because a terra file is a lua file, so lua functions are allowed / encouraged.
a terra function denotes a region of code with (slightly) different rules (arrays indexed at 0, use of C apis, etc). Making all of lua low level is interesting, but that's not what this project was going for.
Re: Terra – a low-level counterpart to Lua
#15> The keyword 'terra' introduces a new Terra function. Why would anyone do this? What's wrong with func, function, def, etc. ?
Lua already has a keyword for declaring functions
Something like "tfunction" may have been better - it's obvious that its still a function, and the leading t let's you easily guess / remember the connection to Terra.
That minor gripe aside, this looks awesome.
Re: Terra – a low-level counterpart to Lua
#16At first I was confused because the pitch seemed to be mainly about writing fast code with Lua. If that's what they're going for, then a comparison with LuaJIT is sorely missing.
But it appears that what they're actually pitching is a simple and flexible code generation environment. It's a way to generate statically-typed code at runtime that targets LLVM but looks nicer than this: http://llvm.org/releases/2.6/docs/tutorial/JITTutorial2.html (C++ code that conjures up LLVM SSA IR directly). You could almost think of this as a high-level API for LLVM code generation and execution that is exceptionally well-integrated into Lua.
For example, in their example where they create a Terra function from a BF program, the equivalent in plain Lua would be to compile the BF program into a Lua program (represented as a big string), load it into the interpreter, and then let LuaJIT JIT it. But with Terra, you can represent the code you're generating symbolically with the "quote" construct instead of having to compile it to a big string. Of course you could just writer a BF interpreter in Lua directly, but if you compile it instead you'll get better performance because you won't pay an interpreter overhead and the optimizer can analyze the program flow to look for optimization opportunities.
[EDIT: removed incorrect criticism about the BF codegen being incomplete]
It's an interesting approach and I look forward to learning more about it.
Re: Terra – a low-level counterpart to Lua
#17Earlier quoted context omitted.
Lower level, so more control for advanced programs performance-wise.
Is this aiming to be a semi-replacement for C then? I guess I'm a bit confused as to where it fits in ... Lua is already tiny and performant. We're considering it for some embedded projects soon as a extensibility hook.
It's aimed at people who would like to design a very performant DSL. Roughly speaking, your Lua code is the compiler, your Terra code is the runtime. Because the Lua code can metaprogram the Terra code, it's possible to perform dynamic tuning of Terra even while the program is running.
Re: Terra – a low-level counterpart to Lua
#18I'm reminded quite a bit of OMeta and the other VPRI work on DSLs, although this is more targeted towards a specific application(dynamically optimized DSLs) and uses a more familiar imperative environment, rather than being parser-focused.
Re: Terra – a low-level counterpart to Lua
#19At first I was confused because the pitch seemed to be mainly about writing fast code with Lua. If that's what they're going for, then a comparison with LuaJIT is sorely missing. But it appears that what they're actually pitching is a simple and flexible code generation environment . It's a way to generate statically-typed code at runtime that targets LLVM but looks nicer than this: http://llvm.org/releases/2.6/docs/…
Author here. You're right that we designed Terra primarily to be an enviornment for generate low-level code.
In particular, we want to be able to easily design and prototype DSLs and auto-tuners for high-performance programming applications.
We explain this use-case in more detail in our upcoming PLDI paper (http://terralang.org/pldi071-devito.pdf).
Since we are primarily using it for dynamic code generation, I haven't done much benchmarking against LuaJIT directly. Instead, we have compared it C by implementing a few of the language benchmarks (nbody and fannkuchredux, performance is normally within 5% of C), and comparing it against ATLAS, which implements BLAS routines by autotuning x86 assembly. In the case of ATLAS, we're 20% slower, but we are comparing auto-tuned Terra and auto-tuned x86 assembly.
Small note, the BF description on the website does go on to implement the '[' and ']' operators below. I just left them out of the initial code so it was easier to grok what was going on. The full implementation is at (https://github.com/zdevito/terra/blob/master/tests/bf.t).
Re: Terra – a low-level counterpart to Lua
#20At first I was confused because the pitch seemed to be mainly about writing fast code with Lua. If that's what they're going for, then a comparison with LuaJIT is sorely missing. But it appears that what they're actually pitching is a simple and flexible code generation environment . It's a way to generate statically-typed code at runtime that targets LLVM but looks nicer than this: http://llvm.org/releases/2.6/docs/…
Author here. You're right that we designed Terra primarily to be an enviornment for generate low-level code. In particular, we want to be able to easily design and prototype DSLs and auto-tuners for high-performance programming applications. We explain this use-case in more detail in our upcoming PLDI paper ( http://terralang.org/pldi071-devito.pdf ). Since we are primarily using it for dynamic code generation, I hav…
Thanks for the info! Sorry for missing the implemented '[' and ']' -- you might want to replace the "NYI" comment with "Implemented below". :)