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

[David Kastrup <dak@...>]

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

> On Thu, Oct 14, 2010 at 02:56, David Kastrup <dak@gnu.org> wrote:
>>
>> 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
>>
>
> Actually, C/C++ chips aways on numerics from Fortran quite aggressively.
> Most of high performance vector/matrix operations in C/C++ libraries
> are implemented in assembler, see Goto BLAS,

And just why is it implemented in assembler?  Because the C compilers
can't be persuaded that two pointers passed into one function don't
access overlapping memory areas.  Recent language standards allow
conveying this information, but the required syntax is utterly obtuse,
so nobody actually uses that.  In particular, you can't give this
information when using multidimensional array syntax in the function
arguments.  You need to use pointer syntax for the largest-stride
dimension.

Anyway, having overlapping arrays passed into a function is legal in C,
undefined in Fortran, and very likely leads to unpredictable behavior in
the assembly language Goto BLAS.

The original, higher language version of BLAS is written in Fortran.  C
ports have never been popular due to performance reasons: instead you
use external interfaces to call the Fortran routines.  Go figure.

-- 
David Kastrup