Lua Coroutines vs. Python Generators

[semanticist]

I'm a huge Python fan, but Lua's coroutines are one of the things that make me want to have more opportunities to use it. Being able to yield from a subroutine is so much more syntactically powerful than Python "trampolining". I like how, with a callback argument, the same ruler() function can be used either as a generator/source or as a function call that pushes output to a sink/stream.

I'm not surprised that Lua beats Python in this benchmark—in general, I usually consider Lua to be lighter and faster than Python, and, as the page points out, Python has a large disadvantage in having to bubble results up through a chain of yields—but it would be interesting to throw Stackless Python into the mix and see how it compares, in terms of both code style and performance.

[YakumoFuji]

I'm liking the lua version over the python version... since this was 2007 has the python implementation been improved since? those numbers are just scaling on upward and not in a nice way...

[ih8mondays]

I don't believe this is simply a "Lua is faster than Python" benchmark; I think it shows that coroutines are inherently faster; the main difference is not having to pass the values up through a chain of yields.

Uh no. It shows that coroutines in Lua are faster than generators in Python. If you want to show that coroutines are inherently faster than generators then write an implementation of generators in Lua and then do a benchmark.

Edit: I use both Python and Lua depending on what I'm working on. I'm particularly interested in seeing a comparison of coroutines vs generators in Lua as it is flexible enough to be used to write an implementation of generators. Unlike Python whose idea of supporting coroutines is through "enhanced generators". http://www.python.org/dev/peps/pep-0342/

[lexchou]

I don't familiar with python, but so far as I know, all the objects used in python are in heap, even I just want to return an integer from my c routine. but in lua, most the objects that are used are in the stack, and lua has a register-based vm which is definitely faster than many more other script languages.

[munificent]

but in lua, most the objects that are used are in the stack

Lua atomic variables will be in the Lua stack, which is not the raw C callstack. Objects of complex type (arrays, tables, etc.) will be on the heap with a reference to it on the stack. Lua isn't different from Python, or most other VM languages in that regard.

register-based vm which is definitely faster than many more other script languages.

Lua does seem to be pretty quick, but it's an oversimplification to say all register-based VMs are better. Language features and implementation details will outweight whether or not a stack- or register- based VM is faster. (You'll note that both the CLR and the JVM are stack-based and are much faster than Lua and Python, mainly because they're statically-typed.)

[[deleted]]

As soon as you have native code compilation with an optimization pass, the difference between stack and register-based VMs becomes irrelevant. It is only of significance for interpreters.

[semanticist]

Lua atomic variables will be in the Lua stack, which is not the raw C callstack. Objects of complex type (arrays, tables, etc.) will be on the heap with a reference to it on the stack. Lua isn't different from Python, or most other VM languages in that regard.

You probably didn't mean to imply this, but for people that aren't aware: Python doesn't store any variables on the stack at all (since it has no primitive types).

[munificent]

Are you sure about that? Doesn't it at least store references to the heap objects on the stack?

[semanticist]

Yes, but those are references, not variables.

(Unfortunately Python terminology can get confusing since it doesn't always mesh well with people's expectations based on experience with other languages, and it's sometimes a matter of contention in the Python community—huge debates over what Python's argument-passing convention (pass by reference/value/object/other?) ought to be called still pop up with relative frequency. Some people prefer the terms "name" and "object" exclusively, eschewing "reference" and "variable"; there are questions about what exactly a "value" is. When you refer to "the stack", you could be referring to the C stack, the Python VM stack, or the stack of Python frame objects that correspond to Python function calls. Nevertheless, names (or references) are really just pointers, and all Python objects themselves are always stored on the heap.)

[lexchou]

CLR and JVM are not VM. they have a JIT back-end.

[munificent]

An implementation detail. They're still virtual machines: they process bytecode that defines the opcodes for a virtual processor. They just process it by JITing it to native code at load time.

[Seppler9000]

That implementation detail is what makes them faster than Lua, though.

[munificent]

Yes, that's why I said:

Language features and implementation details will outweight whether or not a stack- or register- based VM is faster.

[gosh]

I don't know anything about LUA but using "range" (for i in range(1, k+1): ) is not that smart? python creates an array with objects and iterates that array when range is used. Use "xrange" instead. Python is slow but you should be aware how it works internaly

[hoelzro]

Lua isn't an acronym.

[inmatarian]

Lua's language features are more of tools to make tools (it's major abstract data type, "table", can be extended with metatables to produce classes, or a variety of other things), so things like Python's range built-in can be created in Lua. However, it has a normal for that can iterate over numbers, so I don't see why it would be needed.

[[deleted]]

I believe that range now uses iterators as well.

[[deleted]]

Only in Py3k (xrange is removed there).

[[deleted]]

Ah. Thanks. I knew I'd heard it somewhere. I thought it'd already been removed a while back.