Re: Re[2]: Bookworm Adventures Postmortem

[Gé Weijers <ge@...>]

On Mar 18, 2007, at 4:39 PM, Lothar Scholz wrote:

I must say i think the same same. I like the programming model but it

is very slow and i really don't know why the design of lua wants to

use slow hashtable access anywhere. My performance tests show that for

function calls there is a lot (i really mean a lot) room for

optimization.

Warning for those reading this message: "There are lies, damn lies, and benchmarks"

I did a quick, unscientific test and ran an 'nfib' benchmark. 'nfib' is a recursive function returning the number of function calls executed. It's useful for a quick assessment of function call overhead. The Lua code:

local clock = os.clock

function nfib(n)

    if n <= 1 then

        return 1

    else

        return 1 + nfib(n-1) + nfib(n-2)

    end

end

local start = clock()

local r = nfib(32)

local stop = clock();

print(math.floor(r/(stop - start)))

By dividing the result of the function call by the time elapsed you get then number of function calls/second. You can trivially speed this program up by declaring 'nfib' as a local function, but I ignored that.

I also implemented the same function in a number of other languages. On my PowerPC Mac laptop I obtained the following results:

C: 97301516   (optimization flag: -O3)

C: 34003218   (no optimization)

Lua: 3119095

Python: 1077014

Perl: 453289

Relative to Lua's performance:

C: 31.20   (optimized)

C: 10.90   (unoptimized)

Lua: 1.00

Python: 0.35

Perl: 0.15

Lua is quite a bit faster than the common interpreted languages I tried. The optimized C performance number is unrealistically high because the compiler performs a kind of inline substitution to lower the number of recursive calls made. If your turn that off the speed advantage relative to Lua drops to 10.9.

It seems to me that Lua is doing very well relative to the established scripting languages, at least in the function call department.

And sorry i never understood why simplicity is a positive value in a

language implementation. A clean simple API is but internal

implementation is _NOT_. Thats a very academic point of view.

I'm now using lua because there is nothing else with this memory

footprint, but i have to say i'm not as impressed as i was after

reading the first tutorial.

There's nothing else with this memory footprint because simplicity was not an objective in other languages. Python and Perl do not fit in a megabyte, and that's not counting their libraries.

I'm impressed with Lua because it provides a lot of functionality in a small footprint, and in version 5.1 gets a lot right:

- it implements real closures,  nice for those of us who were taught real programming languages.

- it implements tail recursion correctly.

- it can handle cyclic structures without additional overhead.

- tables when used as arrays have O(1) operations.

- it's quite a bit easier to interface C code to Lua than to Python.

- it's small.

- it's embedable.

- it's portable.

- it's well supported by a community.

And by the way, please offer real arrays and a builtin performance

optimized object system soon.

The arrays are real enough. Lua does not use hash table access for tables that have a contiguous set of numeric indices between 1 and N. Try it. I found that a Lua routine reversing a million entry array is at least twice as fast as the Python builtin 'reverse' method on arrays. Sad, really :-)

There are plenty of other scripting languages out there, with different compromises between speed, size and utility. Maybe Lua is not right for you.

Gé

--

Gé Weijers

ge@weijers.org