RE: conditional compilation of debug facilities in LUA core

[Benoit Germain <bgermain@...>]

oops, bad coordination :-)

So. I have run a few samples modified to disable screen outputs and recorded
some speeds:

LUA_REFLEXIVEDEBUG		ON		OFF
life.lua ( 2000 )			5.29		5.4
sieve.lua ( 10000 )		5.9		5.4
fib.lua ( 32 )			4.43		4.65

I don't quite unterstand why some sample run slower with LUA_REFLEXIVEDEBUG
disabled. Either time measurement under W$ is not very precise because of
multitasking (but I have run every test a few times to make sure I had
consistent results), or there is something strange that occurs with the
cache because the binary is not the same and code moved around. Anoter
hypothesis is that my modification is not correct, but in that case times
are too similar to strongly validate it.

All in all, performance does not seem to be much changed, in a direction or
the other, and the memory gain is still quite interesting, especially in the
light of the size increase from 4.0 to 5.0alpha.

Regards,

Benoit.

> -----Original Message-----
> From: Benoit Germain 
> Sent: lundi 9 septembre 2002 15:35
> To: 'lua-l@tecgraf.puc-rio.br'
> Subject: RE: conditional compilation of debug facilities in LUA core
> 
> 
> I have run a modified life.lua 
> 
> > -----Original Message-----
> > From: Benoit Germain [mailto:bgermain@ubisoft.fr]
> > Sent: lundi 9 septembre 2002 12:36
> > To: Multiple recipients of list
> > Subject: RE: conditional compilation of debug facilities in LUA core
> > 
> > 
> > Well, I have added a few 
> > 
> > #ifdef LUA_REFLEXIVEDEBUG
> > 
> > all over the code (41 places are touched). I don't know about 
> > performance,
> > but I have a 8K code size reduction because of this. In 
> > itself it justifies
> > the change, to my mind.
> > A script of mine, where no error should occur, still runs fine :-).
> > 
> > The changes are as follows:
> > 
> > - removed support for hooks and setjmp/longjmp from the 
> > lua_State structure
> > - lua_Debug structure keeps only its i_ci field
> > - several error checking functions are redefined as empty macros
> > 
> > However, since I have no deep knowledge of the core's 
> > internals, I cannot
> > guarantee that it is truly operational.
> > Maybe someone would care to have a look ?
> > 
> > Cheers,
> > 
> > Benoit.
> > 
> > 
> > > -----Original Message-----
> > > From: Benoit Germain [mailto:bgermain@ubisoft.fr]
> > > Sent: lundi 9 septembre 2002 09:28
> > > To: Multiple recipients of list
> > > Subject: RE: conditional compilation of debug facilities 
> in LUA core
> > > 
> > > 
> > > I am not working in an environment where the measures I 
> could do are
> > > significant (W2K, to name it). Also, measures on an 
> > > intel-based system with
> > > a few hundred Kb of L1 cache might not provide information as 
> > > to the gain we
> > > get, say, on a R5900 core with 8K of L1 code cache :-)
> > > And I haven't yet had the time to do it, but I am going to 
> > > take it real
> > > soon.
> > > 
> > > Cheers,
> > > 
> > > Benoit.
> > > 
> > > > -----Original Message-----
> > > > From: Jani Kajala [mailto:jani@sumea.com]
> > > > Sent: vendredi 6 septembre 2002 19:34
> > > > To: Multiple recipients of list
> > > > Subject: Re: conditional compilation of debug facilities 
> > in LUA core
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Have you profiled the difference in your application? How 
> > much more
> > > > performance you get by removing the debug stuff?
> > > > 
> > > > 
> > > > Regards,
> > > > Jani Kajala
> > > > 
> > > > ----- Original Message -----
> > > > From: "Benoit Germain" <bgermain@ubisoft.fr>
> > > > To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
> > > > Sent: Friday, September 06, 2002 5:10 PM
> > > > Subject: conditional compilation of debug facilities in LUA core
> > > > 
> > > > 
> > > > > Hi all (well, game developers might be more specifically 
> > > > concerned, I
> > > > think)
> > > > >
> > > > > I was thinking that when using LUA as a scripting extension 
> > > > for a game,
> > > > once
> > > > > the scripts are debugged they will not change, because 
> > > the scripting
> > > > engine
> > > > > won't be exposed to the player (unless you use LUA as a 
> > > > console language).
> > > > > In that case, all the debug stuff is no longer necessary, 
> > > > as well as the
> > > > > hook mechanism. Therefore, in order to make LUA leaner and 
> > > > faster, it
> > > > might
> > > > > be interesting to be able to compile the core with all 
> > this being
> > > > disabled.
> > > > > Of course the setjmp/longjmp mechanism should remain, but 
> > > > testing for a
> > > > > count hook at each VM instruction, and keeping 
> > lua_Debug structure
> > > > pointers
> > > > > in some places is something I would want to be able to 
> > > control, for
> > > > example
> > > > > by commenting out a -DLUA_REFLEXIVEDEBUG directive in the 
> > > > config file...
> > > > >
> > > > > I guess this shouldn't be too much work for anybody, but if 
> > > > this could
> > > > > become a feature of the official lua distribution, it would 
> > > > spare many of
> > > > us
> > > > > the throes of despair at not having found all the places to 
> > > > touch, and of
> > > > > doing all this all over again when upgrading.
> > > > >
> > > > > I suppose that it would mean that the associated compiler 
> > > > would be unable
> > > > to
> > > > > generate unstripped bytecode files, and that a virtual 
> > > > machine without
> > > > debug
> > > > > facilities would have to fail gracefully upon being handled 
> > > > a precompiled
> > > > > file with debug infos (even if crashing would'nt bother me 
> > > > too much).
> > > > >
> > > > > Anybody with me to convince the authors to include this 
> > > > feature in 5.0
> > > > final
> > > > > :-) ?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Benoit.
> > > > >
> > > > 
> > > 
> > 
>