In a similar vein is Red/System which is a low-level system dialect (DSL) of the Red (Rebol inspired) programming language.
Terra – a low-level counterpart to Lua
41–49 of 49 posts
Re: Terra – a low-level counterpart to Lua
#42Hah, props on the pun of "Terra" being the low-level counterpart of "Lua". Good naming, there.
Re: Terra – a low-level counterpart to Lua
#43Terra code can execute independently of Lua’s runtime How about concurrently? That might be nice to have for asynchronous applications.
Yes! One of the benefits of making sure that Terra code can execute independly of Lua is that you can use multi-threading libraries pretty much out-of-the box. For instance, we have an example that launches some threads using pthreads ( https://github.com/zdevito/terra/blob/master/tests/pthreads.... ). There are still some limitations. You'd still have to manage thread synchronization manually, and I think LuaJIT onl…
So it's using LuaJIT and not PUC Lua? (A good thing to be sure, as LuaJIT is much faster, even without the JIT.)
Is there a way to run Terra with a separate Lua state per thread? So as to not have the problem with serializing when calling Lua from Terra?
Re: Terra – a low-level counterpart to Lua
#44Earlier quoted context omitted.
Yes! One of the benefits of making sure that Terra code can execute independly of Lua is that you can use multi-threading libraries pretty much out-of-the box. For instance, we have an example that launches some threads using pthreads ( https://github.com/zdevito/terra/blob/master/tests/pthreads.... ). There are still some limitations. You'd still have to manage thread synchronization manually, and I think LuaJIT onl…
So it's using LuaJIT and not PUC Lua? (A good thing to be sure, as LuaJIT is much faster, even without the JIT.) Is there a way to run Terra with a separate Lua state per thread? So as to not have the problem with serializing when calling Lua from Terra?
LuaJIT definitely has sweet-spots where it just flies, but there are other cases where LuaJIT isn't faster than PUC Lua, e.g. where you're doing a lot of string manipulation and calling into non-Lua libraries. In "average" code, it varies a lot, but you often don't get the insane speedups that makes LuaJIT look so great on small benchmarks.
Given that LuaJIT has some other drawbacks (e.g. it has memory limitations that PUC Lua doesn't have, due to the details of LuaJIT's NaN-encoding), the usual lesson applies: YMMV, so benchmark... :]
Re: Terra – a low-level counterpart to Lua
#45Earlier quoted context omitted.
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…
This is really great CS work. Props. The fact that your numerical example is DGEMM, AND that you're comparing against ATLAS and MKL is very compelling, especially since you're only showcasing the kernel itself! I'm taking a different albeit related approach for dynamic runtime code gen, but either way this is rock solid work, though I'm pretty terrible at deciphering the lua + macro heavy code that is your code examp…
It's also a very rare research paper that actually uses blas dgemm as the benchmark, that isn't a paper by someone explicitly focused on writing blas. Usually they just use dot product or a local convolution kernel (whereas in some sense matrix mult is a global convolution).
Just what they've done is a pretty solid. That said, it's not really done as part of a framework for numerics, which just means its a great validation benchmark of their code Gen.
Re: Terra – a low-level counterpart to Lua
#46Earlier quoted context omitted.
So it's using LuaJIT and not PUC Lua? (A good thing to be sure, as LuaJIT is much faster, even without the JIT.) Is there a way to run Terra with a separate Lua state per thread? So as to not have the problem with serializing when calling Lua from Terra?
LuaJIT definitely has sweet-spots where it just flies, but there are other cases where LuaJIT isn't faster than PUC Lua, e.g. where you're doing a lot of string manipulation and calling into non-Lua libraries. In "average" code, it varies a lot, but you often don't get the insane speedups that makes LuaJIT look so great on small benchmarks. Given that LuaJIT has some other drawbacks (e.g. it has memory limitations th…
Yes, that's true, except for the calling into non-Lua libraries, this is where LuaJIT + ffi really shines. It can actually optimize away boxing/unboxing and inline the native function call into the trace (not the body of the native function, but the call itself.) Surely you're referring to something else? The often repeated wisdom on the LuaJIT mailing list is only use the Lua C API for legacy code as it can't come close to the performance or ease of use of the ffi. If your experience is otherwise, maybe the JIT bailed on your test code? The ffi is very slow without the JIT.
String and memory limitations have yet to bother me at all because anywhere speed matters you get order of magnitude improvements by managing the strings/memory yourself via the ffi. With Terra, it's clear that's the approach being advocated as well. I agree it really bolluxes small benchmarks, especially if the code is written for Lua and not done the "LuaJIT way" with the ffi. Outside of embedded or other exotic environments I think one would be hard-pressed to come up with a real-world workload where Lua PUC outperforms LuaJIT and there's no easy way to turn the tables. There are just far more options for optimization with LuaJIT and more ability to get closer to the metal than you have with Lua PUC.
None of that is to take away from what the Lua PUC guys have accomplished. Like any craftsmen who enjoys his work, I just like to use the best tools. That's LuaJIT in my opinion, and now Terra too.
Re: Terra – a low-level counterpart to Lua
#47Earlier quoted context omitted.
Yes! One of the benefits of making sure that Terra code can execute independly of Lua is that you can use multi-threading libraries pretty much out-of-the box. For instance, we have an example that launches some threads using pthreads ( https://github.com/zdevito/terra/blob/master/tests/pthreads.... ). There are still some limitations. You'd still have to manage thread synchronization manually, and I think LuaJIT onl…
So it's using LuaJIT and not PUC Lua? (A good thing to be sure, as LuaJIT is much faster, even without the JIT.) Is there a way to run Terra with a separate Lua state per thread? So as to not have the problem with serializing when calling Lua from Terra?
To answer my own questions, yes it uses (relies on) LuaJIT and there seems to be no problem running multiple Lua states, each using Terra. In fact because of the independent nature of compiled Terra code, I would wager you can create the Lua states with Terra and threads from within Terra itself. LuaJIT actually can't do this currently, you need a little bit of C code, because the callback passed to pthread_create will be invoked in a new thread on the old state (which would be invalid in LuaJIT as you can't share a state across threads like that.) Anyway I'll try it out and submit it as a test case for Terra if it works.
Re: Terra – a low-level counterpart to Lua
#48Well, I guess this is going to be a fairly down-to-earth language.
Re: Terra – a low-level counterpart to Lua
#49At 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…
I saw LLVM IR being referenced, but I am not sure if you are referring to the LLVM bitcode. If you are, wouldn't it be possible to compile Terra to JavaScript by using Emscripten?