Performance (was Re: Selenophobia)

[Frank Kastenholz <fkastenholz@...>]

On 3/25/17 1:30 AM, Alex Larsen wrote:
> Was this with the PUC-Rio Lua?

The work I did was on PUC-Rio Lua 5.3.

The tests that we used were simple "for i=0 to 100,000,000" loops
with the body of the loop simply adding a value. In Lua:
  local i=0
  local j=0
  for i=0,100000000,1 do
     j = j + i
  end

I just redid the tests on my home computer (imac with 3.1ghz core i5)
In Lua the loop took 1.289 seconds to run
In C
   with normal optimization .227s (Lua takes 5.7x longer to run)
   with -O0 optimization    .276s            4.7x
We also coded the C version so that the "j=j+i" operation was not
done in the loop --- rather it was in a separate function, which was
called from within the loop. the notion was to eliminate some of the
locality of reference; the C code probably all fit in a single cache
line whereas Lua would not. The times were
   with normal optimization .255s (Lua takes 5.1x longer to run)
   with -O0 optimization    .391s            3.3x

This is why we felt comfortable saying that if the Lua version
of the application was running 50x slower than the C version, there
were probably issues in the Lua version's implementation that were
not good. The biggest problem was that the application had a loop
of the form
  for i = 0 to a very big number
      if flag==true
         do stuff
      else
         do different stuff
      end
   end
the loop did not change flag.  We recoded it as

  if flag==true
      for i = 0 to a very big number
         do stuff
      end
   else
      for i = 0 to a very big number
         do different stuff
      end
   end
And got the 10x or so improvement in performance.
Any reasonable C computer would have optimized the C
code like this.  Lua didn't.


Also -- as far as the sha reference implementation being slower
in C than in Lua ... reference implementations often are written
so as to be easy for others to read and understand and to be
easy to ensure correctness. Performance usually is secondary;
especially if that performance comes at the expense of code
clarity.

> ------------------------------------------------------------------------
> *From:* lua-l-bounces@lists.lua.org <lua-l-bounces@lists.lua.org> on
> behalf of Vadim A. Misbakh-Soloviov <lua-l@mva.name>
> *Sent:* Friday, March 24, 2017 8:19 PM
> *To:* frank@kastenholz.org; Lua mailing list
> *Subject:* Re: Selenophobia
>
> >   - Lua didn't "just do things" that other languages might. One that
> >     hit us was performance -- initial tests of the application showed it
> >     taking 50x as much time as the same app coded in C++.  A few simple
> >     optimizations got it down to about 5x, which was acceptable. These
> >     were optimizations that any modern C/C++ compiler would do
> >     automatically.
>
> That reminded me the case, when I wrote crypt_sha256 (or 512? Whatever)
> on Lua
> (just for preactice), and it was 2x-5x faster than reference C/C++
> implementation from the author of the document (Ulrich Drepper, AFAIRC) :)