lua-users home
lua-l archive

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


On Wed, 14 Nov 2018 at 19:55, Egor Skriptunoff
<egor.skriptunoff@gmail.com> wrote:
>
>
> OK, let's test it!
>
> 1)
> A bug: correct Lua 5.3 program doesn't run on Ravi.
>    C:\Software\ravi\bin>ravi -e"for x = 1, 2 do x = 42.0 end"
>    ravi: (command line):1: Invalid assignment: integer expected near 'end'
>

In this case Ravi is deciding that x is an integer type and hence
doesn't like that you are assigning a floating point value.

> 2)
> Ravi shows some warnings in JIT mode.  (Nevertheless, the program works correctly despite of the warnings)
>    buffer:2113:1: warning: constant 4023233417 is so big it is long long
>    buffer:2113:1: warning: decimal constant 4023233417 is between LONG_MAX and ULONG_MAX. For C99 that means long long, C90 compilers are very likely to produce unsigned long (and a warning) here
>    buffer:2115:1: warning: constant 2562383102 is so big it is long long
>    buffer:2115:1: warning: decimal constant 2562383102 is between LONG_MAX and ULONG_MAX. For C99 that means long long, C90 compilers are very likely to produce unsigned long (and a warning) here
>    buffer:2119:1: warning: constant 3285377520 is so big it is long long
>    buffer:2119:1: warning: decimal constant 3285377520 is between LONG_MAX and ULONG_MAX. For C99 that means long long, C90 compilers are very likely to produce unsigned long (and a warning) here
>    buffer:2190:1: warning: constant 4294967296 is so big it is long long
>    buffer:2370:1: warning: constant 4294967297 is so big it is long long
>    buffer:2946:1: warning: constant 1099511627776 is so big it is long long

Yes sorry about that - this is coming from the C parser - I will
switch off this warning.

>
> 3)
> Most frustrating problem: compiled functions run slower than not compiled (what am I doing wrong?).
> Simple example (compiled function takes 28 seconds, non-compiled 13 seconds):
>
>    C:\Software\ravi\bin>type program.lua
>       local function f()
>          local tm = os.clock()
>          local o = 0
>          for j = 1, 1e4 do
>             local x = 0
>             for k = 1, 1e5 do
>                x = x ~ (j + k)
>             end
>             o = o | x
>          end
>          print("   Result = "..o)
>          print("   CPU time = "..(os.clock() - tm))
>       end
>       print"Benchmarking non-compiled function"
>       f()
>       print"Compiling the function"
>       assert(ravi.compile(f))
>       print"Benchmarking compiled function"
>       f()
>
>    C:\Software\ravi\bin>ravi program.lua
>       Benchmarking non-compiled function
>          Result = 114656
>          CPU time = 13.425
>       Compiling the function
>       Benchmarking compiled function
>          Result = 114656
>          CPU time = 28.568
>

Okay - there are a few things here.
Firstly the JIT backend in ravi-distro is not inlining normal Lua
arithmetic / bitwise operators. Partly because I haven't got around to
doing this, and partly because I feel that inlining normal Lua ops
results in code bloat as each op has several branches.

I have changed your program as follows to help Ravi:

local function f()
   local tm = os.clock()
   local o: integer = 0
   for j = 1, 10000 do
      local x: integer = 0
      for k = 1, 100000 do
         x = x ~ (j + k)
      end
      o = o | x
   end
   print("   Result = "..o)
   print("   CPU time = "..(os.clock() - tm))
end
print"Benchmarking non-compiled function"
f()
print"Compiling the function"
-- ravi.dumplua(f)
assert(ravi.compile(f))
print"Benchmarking compiled function"
f()

Timings on Mac OSX:

Original code interpreted: 9.063722
Above code interpreted: 6.832995
For some reason the above modified version fails to JIT compile with
the OMR JIT backend; I need to investigate this.
Using LLVM backend original: 6.995143
Using LLVM backend above: 0.230904

So once type annotations are used, the LLVM backend can really improve
performance. The OMR backend should too, except that it is failing to
compile the code for some reason.

I realise that you may not want to annotate your code with types ... I
can try to amend your SHA2 code with types for Ravi if you like. It
will be a good piece of benchmark code for Ravi.

Thank you very much for sharing your findings - it really helps.

Regards
Dibyendu