Asp Forum - Re: JRuby performance questions answered

M. Edward (Ed) Borasky

7/20/2008 4:14:00 AM

Roger Pack wrote:
> Rick Denatale wrote:
>
>> Roger, you REALLY need to read the literature on GC which has been
>> accumulating for the past 50 years.
>>
>> Reference counting is pretty much an obsolete approach to GC. It was
>> probably the first approach taken for lisp back in the 1950s. Other
>> language implementations usually started with reference counting (e.g.
>> the first Smalltalk).

[snip]

I spent a good bit of time the other day downloading some of this =20
"literature". From a theoretical computer science perspective, it can =20
be shown that all garbage collection schemes are equivalent in a broad =20
sense. And when you benchmark them, all of them have strengths and =20
weaknesses that are workload-dependent.

And IIRC the first Lisp garbage collector was pure mark-and-sweep. I =20
forget where reference counting was first used -- maybe Snobol. And =20
stop-and-copy was also developed very early, maybe for Scheme. All =20
three of them are quite simple to understand, once you've bitten the =20
bullet and learned recursion. :)

> This is somewhat confusing for me, because it seems that using a =20
> mark and sweep generational style GC slows down Ruby, as per
>
> Matz's observations: http://www.ruby-forum.com/to...

At a higher level, if you are doing a lot of garbage collection, you =20
need to look at your algorithms. And you need to supply a large enough =20
working set of real memory before you go finger-pointing at the =20
garbage collector, regardless of its type. There are some pretty good =20
web sites out there that have, via profiling, made some tremendous =20
improvements in Rails performance this way.

> I suppose I'm just naive, but it doesn't seem clear to me which is =20
> the 'best' GC style, from the above observations. There appears to =20
> be no clear answer.

That's because it's workload-dependent. What's worse, overall =20
performance on "modern" architectures is highly dependent on spatial =20
and temporal locality in your interpreter, whether it's method =20
dispatch, garbage collection, regular expression processing, bignum =20
operations, etc. It's not just garbage collection by any stretch of =20
the imagination. That's why I profile Ruby interpreters. :)

--=20
M. Edward (Ed) Borasky
http://pdxfoscon....
http://ruby-perspectives.blo...

"A mathematician is a machine for turning coffee into theorems." -- =20
Alfr=E9d R=E9nyi via Paul Erd?s

M. Edward (Ed) Borasky <znmeb@cesmail.net>

comp.lang.ruby

Re: JRuby performance questions answered

M. Edward (Ed) Borasky

x Login to ForumsZone