Performance (was Re: Selenophobia)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Performance (was Re: Selenophobia)
- From: Frank Kastenholz <fkastenholz@...>
- Date: 2017年3月25日 11:30:36 -0400
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) :)