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

[David Kastrup <dak@...>]

Leo Razoumov <slonik.az@gmail.com> writes:

> 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.

It has no native multidimensional array type.  And no, a vector of
pointer-accessed vectors does not cut it as it bypasses the optimizer
knowledge about storage locations and their relative positions, kills
aliasing analysis and causes out of band memory accesses.  If it weren't
for that design deficiency, C would long have succeeded Fortran for
hardcore numerical work.

> In my tests of event driven processing LuaJIT-1.5 beats MATLAB
> (R2010a) 50 to 1 in processed events per second.

MATLAB is not a language designed for efficient scalar processing.

-- 
David Kastrup