lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, Jun 22, 2011 at 10:17 PM, Dimiter "malkia" Stanev
<> wrote:
>        LuaJIT is great, but don't buy into JIT would rule over the rest of
> the stuff. Think about it as a tool, not as the silver bullet. There are
> always going to be faster ways to achieve something, given dedication to the
> problem. Use LuaJIT to solves general programming problems. So far it works
> very good for me.
>        What I find cool about JIT is really that you gain very good speed,
> and you don't have to worry about configurations (architecture),
> preprocessing (compilation, linking, etc.) + one can communicate using
> source code send over the network to get executed, rather than scripts that
> need to get compiled.
>        For example I'm sitting from on my Mac OS X book, and uploading
> scripts to my Efika MX SmartTop (ARM cpu), and they just work. But I had to
> spend some time finding proper (for me) "C" and "C++" libraries to use with
> it - ZeroMQ, OpenGL, GLES, GLFW, etc, and thanks to the awesome FFI I don't
> lose much speed (in fact it might be faster sometimes than called directly
> from "C" - not sure).
>        But you won't be able to use easily LuaJIT to speed up a DXT
> compression for example, while it takes just OpenMP and "C" to do it with
> one or two pragmas (split the image by 4x4 blocks, or 4xNNN rows, NNNx4
> columns, and call the DXT encoding routine). Then again LuaJIT would allow
> me to easily encode this problem in another language - be it OpenCL, CUDA,
> or if needed call gcc and compile "C".

The voice of experience.. completely agree.. use the right tool for
the right job.