Re: bit.lshift and performance - luabitop v.s. lua-5.2.0-work4

[Leo Razoumov <slonik.az@...>]

On 2010-10-13, KHMan <keinhong@gmail.com> wrote:
>
>  Doing stuff like coding in terms of bit.band(blah blah), bit.lshift(blah
> blah), and so on is largely more tedious. Most developers will not be doing
> stuff like implementing compression in Lua for 'normal' apps. Of course, it
> has never stopped anyone before. Even I have coded the deflate CRC before...
>
>  Anyway most app developers do not need to code DCTs and FFTs nowadays.
> Those who need them should be matured enough that they know what they are
> doing (hopefully) and don't need me to tell them anything. So it was just
> conversational bait, and not in any sense targeting anything.
>

What is a 'normal' app is in the eyes of a beholder. Let's not limit
the scope of Lua applications.

Lua and especially LuaJIT are well suited to become a next MATLAB for
numeric and DSP R&D. Its ability to bind easily to C/C++ libraries
plus its own great run time performance (LuaJIT) is unmatched among
scripting languages. In my tests of event driven processing LuaJIT-1.5
beats MATLAB (R2010a) 50 to 1 in processed events per second. LuaJIT-2
will do even better.
DSP algorithms are not limited to just DCT and FFT. Besides, FFT comes
in variety of forms and multi-dimension FFTs you might want to code
yourself. Any language positioned for numeric/DSP applications must
have a decent bit manipulation library. Lua's design is based on
Virtual Machine and has some freedom to come up with a set of BitOPs
consistent across several underlying CPU types.

And in any case for the sake of heavy bitop applications, LuaJIT is a
preferred implementation for its run time speed. It would be
regrettable if stock Lua and LuaJIT start diverging.

--Leo--