Re: lua_newstate

On Thu, Dec 28, 2017 at 1:40 AM, Sean Conner <sean@conman.org> wrote:

> I seriously question the methods used for the Python programs. In each case where Python won (with the exception of mandelbrot), it included a multiprocessing module, whereas Lua was just the stock Lua, so it's not a fair "apples-to-apples" comparison (in this case, Python's "batteries included" gives it a boost with respect to Lua's "batteries not included."

In fact, even in the mandelbrot case the Python program used multiprocessing, it is just a little less obvious. And the fasta test, too, uses multiprocessing.

That is interesting indeed, but that also means that the test suite I referenced does not say much about strictly serial Lua vs strictly serial Python performance, there is only one relevant comparison. Worse yet, the fasta test, which you used below as a benchmark of Python's "slowness" vs Lua, and then stock Lua vs patched Lua, was originally parallel Python vs serial Lua.

> As for what is being measured, it's the overhead of the "global interpreter lock" (a concept in Python, not in Lua) to make Lua thread safe, and such locks do take time.

I understand embedding Python much less than Lua, but somehow I thought that "global" means really global, so that multiple instance of Python's equivalents of the Lua state (if that is possible at all) would share the same lock. Your patch introduces one lock per state. This is probably the right thing to do, given the context of this thread.

Secondly, your patch uses a pthread mutex initialised with default attributes. A different mechanism or different attributes might yield different results.

> And the ratio between these results (32.4 / 36.8 or .88) is close enough to the benchmark results (50.0 / 59.5 or .84) seems to indicate that yes, the modified version may be a slow as Python [4].

As I said above, "(50.0 / 59.5 or .84)" is serial Lua vs parallel Python.

I cannot say with certainty, but I would guess that the original Python fasta implementation uses multiprocessing to achieve better performance, which means the same test without multiprocessing would take longer. The only test where strictly serial Lua was compared with strictly serial Python was n-body, where Python was over 100% slower. In your test, the slowdown was less that 15%, which does not look like "as slow as Python", but, in fairness, this is still comparing results of two different tests.

Cheers,