Speed comparison

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Speed comparison

Nick Trout-2
Does anyone know how Lua compares in speed with other scripting languages.
eg. Python. ?

Is there any timing comparisons anywhere?

Cheers,
Nick




Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Luiz Henrique de Figueiredo
>From [hidden email] Thu Jun  3 09:07:49 1999

>Does anyone know how Lua compares in speed with other scripting languages.
>eg. Python. ?

Lua has been described as "the speed demon of scripting languages":
See http://www.hex.net/~cbbrowne/langscript.html:

  Lua is a scripting language developed in Brazil. It is apparently the
  "speed demon" of scripting languages (as compared to Python and Perl,
  and the nearly glacially slow TCL), and is fairly well suited to
  controlling graphical user interfaces.

>Is there any timing comparisons anywhere?

there are some in the SPE paper, and possibly some discussion about this
in the lua-l archive, but nothing extensive.
timing does seems to depend on the application.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Supratik Champati
In reply to this post by Nick Trout-2
I have personally tested  lua, perl, python, tcl by writing
similar scripts. I found lua to be much faster (sorry cannot quantify
!!).
But the thing that really made me embrace lua is the sheer elegance
of the language.
Although relatively new, it is a very stable code.
The source code is still < 10k lines (compare with 60k+ lines for
perl/python).
I do not think going with lua can be a bad choice any which way one
looks at it.
But again this is just my opinion..

Supratik.

Nick Trout wrote:
> 
> Does anyone know how Lua compares in speed with other scripting languages.
> eg. Python. ?
> 
> Is there any timing comparisons anywhere?
> 
> Cheers,
> Nick

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Bennett Todd-3
1999-06-03-15:44:38 Supratik Champati:
> I have personally tested lua, perl, python, tcl by writing similar scripts.
> I found lua to be much faster [...]

I'd expect that would depend strongly on what exactly you are doing. Many
things will be faster in perl, since many things can be done easily in perl
where the bulk of the actual work is being done by builtins (or by
dynamically-loaded extensions, written in C, that you've pulled down from
CPAN). As soon as you are doing substantial processing in the top-level
scripting language things slow down, and would expect they'd slow down less
for Lua than for most other languages.

> But the thing that really made me embrace lua is the sheer elegance
> of the language.
> Although relatively new, it is a very stable code.
> The source code is still < 10k lines (compare with 60k+ lines for
> perl/python).
> I do not think going with lua can be a bad choice any which way one
> looks at it.

I'd say it would depend on what you're doing.

For places where small is important, Lua is beautiful. For other jobs, where
size doesn't matter:-), I strongly prefer perl; it's so richly expressive,
there are so many high-level extensions available from CPAN, I can do so many
interesting chores with a minimum of code.

But I wouldn't want to e.g. fire up a perl for every local delivery of an
email message, whereas doing that with a Lua seems practical to me.

-Bennett

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Luiz Henrique de Figueiredo
In reply to this post by Nick Trout-2
>From [hidden email] Fri Jun  4 07:14:12 1999
>
>Lua is great on almost every point, except the scoping rules. Why can't we
>have normal scoping rules (i.e a variable is local unless defined
>globally?).  Though I read the rationale behind that decision somewhere, I
>wasn't exactly statisfied by it. 

there's a game you can play with the set/getglobal tag methods and with the
callhook so that global variables seem local to a chunk.

>Is there any who likes these scoping rules?

we do :-)

>Are there any plans on changing this?

sorry, no.
I don't think we're going to change anything in the syntax.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Freek Brysse-2
In reply to this post by Supratik Champati
> 
> I have personally tested  lua, perl, python, tcl by writing
> similar scripts. I found lua to be much faster (sorry cannot quantify
> !!).
> But the thing that really made me embrace lua is the sheer elegance
> of the language.

Lua is great on almost every point, except the scoping rules. Why can't we
have normal scoping rules (i.e a variable is local unless defined
globally?).  Though I read the rationale behind that decision somewhere, I
wasn't exactly statisfied by it. 
Is there any who likes these scoping rules?

Are there any plans on changing this?




Freek B.

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Douglas Lee
Yes, I like these scoping rules.

Freek Brysse wrote:

> >
> > I have personally tested  lua, perl, python, tcl by writing
> > similar scripts. I found lua to be much faster (sorry cannot
> quantify
> > !!).
> > But the thing that really made me embrace lua is the sheer elegance
> > of the language.
>
> Lua is great on almost every point, except the scoping rules. Why
> can't we
> have normal scoping rules (i.e a variable is local unless defined
> globally?).  Though I read the rationale behind that decision
> somewhere, I
> wasn't exactly statisfied by it.
> Is there any who likes these scoping rules?
>
> Are there any plans on changing this?
>
> Freek B.



Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

DASWorks
In reply to this post by Nick Trout-2
lhf wrote:

>there's a game you can play with the set/getglobal tag methods and with
>the callhook so that global variables seem local to a chunk.

Would you elaborate on how this can be done?  Thanks...

das

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Luiz Henrique de Figueiredo
In reply to this post by Nick Trout-2
>From [hidden email] Fri Jun  4 11:16:01 1999
>
>lhf wrote:
>
>>there's a game you can play with the set/getglobal tag methods and with
>>the callhook so that global variables seem local to a chunk.
>
>Would you elaborate on how this can be done?  Thanks...

Use the call hook to see when a chunk starts and end.
A chunk starts when line==0. It ends when file=="(return)".
(Since line==0 when a chunk ends, you should test file first.)
See etc/trace.c in the distribution.

Now, when a chunk starts, set the setglobal and the getglobal tag methods
for nil to use a table to store values. Something similar is described in
the FAQ: 3.3 - How do I create read-only variables?. See also some code in
test/trace.lua.

When a chunk ends, simply restore the defaults set/getglobal tag methods.

All this can be written in Lua 3.2 (which includes ldeblib).
In Lua 3.1, you have to write the hook part in C.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison

Russell Y. Webb
In reply to this post by Freek Brysse-2
I don't like the scoping rules either.  I brought this issue up last year 
and even when as far as modifying the scoping rules myself.

The combination of the following attributes makes it difficult to do 
large projects and cause typo bugs that are hard to find:
1. creating variables by assignment
2. variables inside functions defaulting to global (this is the worst one 
in my opinion).
3. having undefined variables be equal to NIL

The two options I thought of are
1. just make variable assignment default to local inside functions
2. require declaration of all globals and locals inside functions

Both options break old code though.  So the would need to be a 
variable_mode or a new "function" keyword.  The second option kind of 
goes against the "easy to write code" model of lua.  Option one coupled 
with requiring all locals to be declared (as it is now) is the best solution.
Assigning to something not declared as local or as an arguement would be 
an error.

Russ


On Fri, 4 Jun 1999, Freek Brysse wrote:

> > 
> > I have personally tested  lua, perl, python, tcl by writing
> > similar scripts. I found lua to be much faster (sorry cannot quantify
> > !!).
> > But the thing that really made me embrace lua is the sheer elegance
> > of the language.
> 
> Lua is great on almost every point, except the scoping rules. Why can't we
> have normal scoping rules (i.e a variable is local unless defined
> globally?).  Though I read the rationale behind that decision somewhere, I
> wasn't exactly statisfied by it. 
> Is there any who likes these scoping rules?
> 
> Are there any plans on changing this?
> 
> 
> 
> 
> Freek B.
> 
> 

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison (now scoping)

Fred Bertsch
On Fri, 4 Jun 1999 [hidden email] wrote:

> The two options I thought of are
> 1. just make variable assignment default to local inside functions
> 2. require declaration of all globals and locals inside functions
> 
> Both options break old code though.  So the would need to be a 
> variable_mode or a new "function" keyword.  The second option kind of 
> goes against the "easy to write code" model of lua.  Option one coupled 
> with requiring all locals to be declared (as it is now) is the best solution.
> Assigning to something not declared as local or as an arguement would be 
> an error.

Here's another possibility:  if you created a getglobal and setglobal
tag that worked on everything, you could implement something yourself.
(Personally, I would just disable global assignment once all the functions
are defined.)  

I'm not sure what the speed penalty would be for that.  Obviously, since I
don't assign to globals very often, a setglobal tag wouldn't slow things
down much.  getglobal might be too slow, though, since it would be used on
all function calls.  I could live with just a setglobal tag, though. 

F

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison (now scoping)

Russell Y. Webb
> Here's another possibility:  if you created a getglobal and setglobal
> tag that worked on everything, you could implement something yourself.
> (Personally, I would just disable global assignment once all the functions
> are defined.)  
> 
> I'm not sure what the speed penalty would be for that.  Obviously, since I
> don't assign to globals very often, a setglobal tag wouldn't slow things
> down much.  getglobal might be too slow, though, since it would be used on
> all function calls.  I could live with just a setglobal tag, though. 

I could live with just the setallglobal tag too.  It would be a great 
addition to lua.  getallglobal would be good if it didn't slow things 
down.

Russ

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison (now scoping)

Luiz Henrique de Figueiredo
In reply to this post by Fred Bertsch
>From [hidden email] Fri Jun  4 18:47:11 1999
>From: [hidden email]
>
>> Here's another possibility:  if you created a getglobal and setglobal
>> tag that worked on everything, you could implement something yourself.
>> (Personally, I would just disable global assignment once all the functions
>> are defined.)  
>> 
>> I'm not sure what the speed penalty would be for that.  Obviously, since I
>> don't assign to globals very often, a setglobal tag wouldn't slow things
>> down much.  getglobal might be too slow, though, since it would be used on
>> all function calls.  I could live with just a setglobal tag, though. 
>
>I could live with just the setallglobal tag too.  It would be a great 
>addition to lua.  getallglobal would be good if it didn't slow things 
>down.

Unless I'm missing something, there's no need for a setallglobal.
The setglobal for nil suffices because when a global is created, its value
is nil. Then, inside the tag method you create a table wrapper for the global
and give this table a tag. This same tag method is used for the setglobal
for this tag.
I can come up with some code if it's still obscure.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Speed comparison (now scoping)

Fred Bertsch
On Fri, 4 Jun 1999, Luiz Henrique de Figueiredo wrote:

> Unless I'm missing something, there's no need for a setallglobal.
> The setglobal for nil suffices because when a global is created, its value
> is nil. Then, inside the tag method you create a table wrapper for the global
> and give this table a tag. This same tag method is used for the setglobal
> for this tag.

Thanks!  I hadn't noticed that setglobal got the tag from the old value...

That does what I need it to do.

F

Reply | Threaded
Open this post in threaded view
|

Re: chunk/local variables

David Jeske-3
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Jun 04, 1999 at 11:42:05AM -0300, Luiz Henrique de Figueiredo wrote:

>>>lhf wrote:
>>>there's a game you can play with the set/getglobal tag methods and with
>>>the callhook so that global variables seem local to a chunk.
>>
>>Would you elaborate on how this can be done?  Thanks...

> Use the call hook to see when a chunk starts and end.  A chunk
> starts when line==0. It ends when file=="(return)".  (Since line==0
> when a chunk ends, you should test file first.)  See etc/trace.c in
> the distribution.
>
> Now, when a chunk starts, set the setglobal and the getglobal tag
> methods for nil to use a table to store values. Something similar is
> described in the FAQ: 3.3 - How do I create read-only
> variables?. See also some code in test/trace.lua.
>
> When a chunk ends, simply restore the defaults set/getglobal tag
> methods.

I'm confused about how this works. Correct me if I'm mistaken, but
functions do not inherit their tag methods when they are defined. They
use the tag methods which are setup when they are called. I believe
the above solution will only work if the execution of code in the
chunk begins and ends completely within the chunk. If you define a
function within the chunk which uses global variables, and you call
that function after the chunk is loaded, the variables are no longer
chunk local.

Is some of my analysis incorrect? Can you think of a way to get
chunk-local variables which work even when you call functions after
the chunk is loaded?

The only method I can think of involves overriding the global set and
table set tag methods to detect function assignments and have them
create wrapper functions which set the tag methods appropriately. This
definetly won't have good performance consequences (doubling the
number of function invocations to do anything), however, I think it
would give the desired effect (i.e. a chunk/module variable scope).

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: chunk/local variables

Luiz Henrique de Figueiredo
>From [hidden email] Wed Jun  9 16:38:00 1999
>From: David Jeske <[hidden email]>
>
>I'm confused about how this works. Correct me if I'm mistaken, but
>functions do not inherit their tag methods when they are defined.

Right.

>They>use the tag methods which are setup when they are called.

>I believe
>the above solution will only work if the execution of code in the
>chunk begins and ends completely within the chunk. If you define a
>function within the chunk which uses global variables, and you call
>that function after the chunk is loaded, the variables are no longer
>chunk local.

Right.

>Is some of my analysis incorrect? Can you think of a way to get
>chunk-local variables which work even when you call functions after
>the chunk is loaded?
>
>The only method I can think of involves overriding the global set and
>table set tag methods to detect function assignments and have them
>create wrapper functions which set the tag methods appropriately.

That's the only way I can right now.

>This definetly won't have good performance consequences

I can say withou testing. You'd be amazed how fast Lua is?
(Or, to say it differently: in a interpreted language, everything is more or
less slow, so what difference could this make?)

>would give the desired effect (i.e. a chunk/module variable scope).

If your functions never *set* global variables, then it is easier and cleaner
to use upvales:

 local A="something"
 ...
 function f(x,y,z) print(%A..(x+y+z)) end

The % is not hard to write and is signals an access to a "global" var.
if you need to set "global" variables, then the best solution seems to use
a local table explicitly:

 local G={}
 ...
 function g(x,y) %G.sum=x+y end


The tag method game I posted was simply to make a point.
the solutions above seem to me to be much simpler and cleaner, and within
the philosophy of Lua.

We're planning an extensible preprocessor, which will make this even easier
to write. The code above could be written as something like:

 local G={}
 ...
 function g(x,y) $$sum=x+y end

$$ would invoke a user function called "$" *during* compilation and this
function could return "%G." to the lexer.

--lhf

Reply | Threaded
Open this post in threaded view
|

scoping rules

Roberto Ierusalimschy
In reply to this post by Freek Brysse-2
> Lua is great on almost every point, except the scoping rules. Why can't we
> have normal scoping rules (i.e a variable is local unless defined
> globally?).

What is a "normal" scoping rule? In many languages (AWK, Snobol, Perl, etc) 
a variable is global unless declared local. Most other languages (C, C++, 
Pascal and its heirs, Haskell, Lisp, etc) do need global and local 
declarations, but we usually only care for the locals when reading a 
program. In C, for instance, when you read inside a function something like 

  varname = 1;

you do not go all over the file (and includes) to see whether "varname" is 
declared as global. You just check if varname is declared local; if it's 
not, then it is a global variable. A compiler does the same, and only 
*after* seeing that the variable is not local it will need a global 
declaration. 

Very few languages do create local variables without some kind of explicit 
declarations. This is because local variables are local to a given scope, 
and so we must specify this scope. If we get the rule that "a variable is 
local unless defined globally", we will have some weird behaviours; for 
instance, in Lua (and also in C and Java) the scope of a variable is not a 
whole function, but the inest block where the variable is declared. So, if 
you write something like 

  if a then i=1 else ... end

the scope of the variable 'i' (now local by default) would be only the 
"then" part of the if!! (the inner block...) 

In Lua you do not need global declarations. You can complain about this 
(and many people do); but to assume that a variable without this global 
declaration should be automatically considered local does not look "normal" 
to most languages, and certanly is not the right way to solve the problem 
with undeclared global variables. 

If the real problem is the use of global variables without declaration, 
there is an easy and efficient way to solve that, using tag methods. The 
idea is to set the tag methods 'getglobal' and 'setglobal' over the tag nil 
(which is the value of any "undeclared" variable), and to keep a table with 
the name of all declared global variables. When you read or write a nil 
global variable, the tag method goes to the table to check whether the 
variable has been declared. When you read or write a non-nil global, the 
most frequent case, there is no cost at all. 

==================================================================
_Globals = {}   -- a set to keep the names of global variables

function declare (globalname)
  _Globals[globalname] = 1
end

function undeclare (globalname)   -- optional
  rawsetglobal(globalname, nil)
  _Globals[globalname] = nil
end


settagmethod(tag(nil), 'setglobal', function (name, oldvalue, newvalue)
  if not _Globals[name] then
    error("cannot write undeclared variable `"..name.."'")
  end
  return rawsetglobal(name, newvalue)
end)

settagmethod(tag(nil), 'getglobal', function (name, value)
  if not _Globals[name] then
    error("cannot read undeclared variable `"..name.."'")
  end
  return value   -- or nil (value must be nil...)
end)

==================================================================
Example:

> dofile'temp'   -- the above code
> print(i)
lua: cannot read undeclared variable `i'
Active Stack:
        function error [in file (C)]
        `getglobal' tag method [in file temp]
        main of (dostring) >> "print(i)"
> declare'i'
> print(i)
nil     
> i=10
> print(i)
10      
> a = 10
lua: cannot write undeclared variable `a'
Active Stack:
        function error [in file (C)]
        `setglobal' tag method [in file temp]
        main of (dostring) >> "a = 10"
> undeclare'i'
> i='hello'
lua: cannot write undeclared variable `i'
Active Stack:
        function error [in file (C)]
        `setglobal' tag method [in file temp]
        main of (dostring) >> "i='hello'"


-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: scoping rules

Russell Y. Webb
Thanks for the good points.  I think most of us had missed the technique 
of setting the nil tag methods.  Another thing that some people might 
like to add to your code to control lua globals is an effective 'global' 
keyword so that one can not create globals without declaring them first.  
To do this one could add a global("name") function that would store 
allowed global names to a table and then have the setglobal function 
check that table when it creates variables (the check only happens on 
global creation, so there isn't really a speed penalty).

Amazing language.  Reminds me of all the cool things you can do in Forth 
or Scheme, but with better structure than Forth and easier syntax than 
Scheme.

Thanks,
Russ

On Thu, 10 Jun 1999, Roberto Ierusalimschy wrote:

> In Lua you do not need global declarations. You can complain about this 
> (and many people do); but to assume that a variable without this global 
> declaration should be automatically considered local does not look "normal" 
> to most languages, and certanly is not the right way to solve the problem 
> with undeclared global variables. 
> 
> If the real problem is the use of global variables without declaration, 
> there is an easy and efficient way to solve that, using tag methods. The 
> idea is to set the tag methods 'getglobal' and 'setglobal' over the tag nil 
> (which is the value of any "undeclared" variable), and to keep a table with 
> the name of all declared global variables. When you read or write a nil 
> global variable, the tag method goes to the table to check whether the 
> variable has been declared. When you read or write a non-nil global, the 
> most frequent case, there is no cost at all. 
> 
> ==================================================================
 <Code deleted>