Terra code can execute independently of Lua’s runtime
How about concurrently? That might be nice to have for asynchronous applications.
Terra – a low-level counterpart to Lua
21–30 of 49 posts
Re: Terra – a low-level counterpart to Lua
#22Terra 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 only allows one thread of Lua execution to run at a time, so if your threads call back into Lua they may serialize on that bottleneck.
Re: Terra – a low-level counterpart to Lua
#23At 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…
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 examples.
edit: I'm doing something more akin to the Accelerate haskell EDSL approach, with some changes
Re: Terra – a low-level counterpart to Lua
#24At 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 haven't done much benchmarking against LuaJIT directly
It would be better to comparing it to LuaJIT with ffi
Re: Terra – a low-level counterpart to Lua
#25This appears to be the perfect language for embedded applications. The combination of lua, high performance, and small generated code footprint is exactly what embedded applications need. I'd recommend the authors head in this direction - maybe try create bindings for Android and you'd get immense traction with this.
Re: Terra – a low-level counterpart to Lua
#26At 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…
Cool stuff :-)
Here's one perhaps relevant paper about LuaJIT for dynamic code generation in QEMU-esque instruction set simulation: http://ieee-hpec.org/2012/index_htm_files/Steele.pdf
Re: Terra – a low-level counterpart to Lua
#27> Terra is a simple, statically-typed, compiled language with manual memory management
How is is like lua then?
Re: Terra – a low-level counterpart to Lua
#28Let me see if I understand well: can I use this such that "terra" code is equivalent to C code and Lua code is equivalent to an extremely powerful preprocessor?
Am I right to think that I can generate dynamic libraries (.so) that do not include any kind of interpreter with this?
If I can do this then this may be my dream static / system language...
Re: Terra – a low-level counterpart to Lua
#29Re: Terra – a low-level counterpart to Lua
#30Let me see if I understand well: can I use this such that "terra" code is equivalent to C code and Lua code is equivalent to an extremely powerful preprocessor? Am I right to think that I can generate dynamic libraries (.so) that do not include any kind of interpreter with this? If I can do this then this may be my dream static / system language...
One of our design goals was to make sure terra could execute independently of Lua. So everything that you describe is possible. For instance our simple hello world program (https://github.com/zdevito/terra/blob/master/tests/hello.t) compiles a standalone executable with the "terralib.saveobj" function. You can also write out object (.o) files that are ABI compatible with C. For instance, gemm.t (https://github.com/zdevito/terra/blob/master/tests/gemm.t) our matrix-matrix multiply autotuner writes out a .o file my_dgemm.o which we then call from a test harness in a separate C program (https://github.com/zdevito/terra/blob/master/tests/reference...). Once you have the .o files, you can use Lua to call the system linker to generate a dynamic library.