RE: Lua 5.1 (work0) -- 1st torture test

["Joshua Jensen" <jjensen@...>]

> > Just for fun, I tried the same script on python (v. 2.3.3), 
> which uses 
> > reference counting and whose strings are immutable. Got similar 
> > results, except (again, untimed, just looking at the 
> console) response 
> > degrades it better than lua's (as far as n=493000).
> 
> One interesting question is whether it would be productive to 
> have a reference counting collector backed up by an 
> incremental mark-and-sweep collector. I could also see, 
> however, that getting relatively complicated to define and 
> the overhead might get to be too high.
> 
> Where I'm having pause concerns with the existing Lua 
> distribution has been while running tracking loops. Naïve 
> implementations that generate new data structures each time 
> we get a mouse location will trigger the garbage collector. 
> These sort of data structures are prime candidates for 
> reference counting management (or presumably a really good 
> generational collector).

Using Subversion, grab the ref counting Lua 5.0.2 I have at:

svn co svn://24.2.105.59/root/luarc

I'm running on a 2.8 ghz HT Intel box, and the results I get are (memory
reported by the Windows Task Manager):

Lua 5.0.2: at n =  200000   time =         23.968   Mem Usage 2588 K / VM
1972 K
Lua 5.1w0: at n =  200000   time =         23.64    Mem Usage 3580 K / VM
2580 K
luarc:     at n =  200000   time =         11.546   Mem Usage 1800 K / VM
1168 K

Note that without the collectgarbage() calls in Lua 5.0.2 and Lua 5.1w0, the
whole system eats massive amounts of RAM around n = 36000.

luarc requires no special collectgarbage() calls, although without a
beginning collectgarbage() call with a relatively high number of bytes, just
the size of the strings alone cause the mark/sweep collector to run every
string concatenation.  This is because the ref counting collector is built
on top of the mark/sweep collector.

The interesting thing about luarc is that it would be entirely possible to
take advantage of the ref count on the string being 1 and resize the string
buffer in-place, bringing the results more in-line with the previously
reported Perl results.

If the ref counting collector was built on top of the incremental collector,
it wouldn't have mattered in this torture test.  The incremental collector
would never need to run, as the ref counting collector would clean up before
the incremental collector ever got a chance.

Josh