[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>

Hi, developers,

21 messages 2008/03/01

[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

31 messages 2008/03/03
[#15742] Re: Copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/03/03

Hi,

[#15829] Re: Copy-on-write friendly garbage collector — Daniel DeLorme <dan-ml@...42.com> 2008/03/08

Yukihiro Matsumoto wrote:

[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>

Hello,

18 messages 2008/03/03
[#15759] Re: embedding Ruby 1.9.0 inside pthread — Nobuyoshi Nakada <nobu@...> 2008/03/04

Hi,

[#15760] Re: embedding Ruby 1.9.0 inside pthread — Yukihiro Matsumoto <matz@...> 2008/03/04

Hi,

[#15762] Re: embedding Ruby 1.9.0 inside pthread — "Suraj N. Kurapati" <sunaku@...> 2008/03/04

Yukihiro Matsumoto wrote:

[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>

Hi all,

15 messages 2008/03/04

[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>

I've been reworking JRuby's stdlib to improve performance and fix

10 messages 2008/03/09

[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>

Hi,

35 messages 2008/03/23
[#15991] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#15993] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/23

Hi Dave,

[#15997] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#16024] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

Hi Dave,

[#16025] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16026] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16027] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16029] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16030] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16031] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16032] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:

[#16033] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16041] Re: Recent changes in Range#step behavior — David Flanagan <david@...> 2008/03/26

Dave Thomas wrote:

Re: Copy-on-write friendly garbage collector

From: Hongli Lai <hongli@...99.net>
Date: 2008-03-20 12:54:04 UTC
List: ruby-core #15965
Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: Copy-on-write friendly garbage collector"
>     on Thu, 20 Mar 2008 19:59:16 +0900, Hongli Lai <hongli@plan99.net> writes:
> 
> |Sorry for mentioning this again, but it has been almost a week since my 
> |last patch. I'd really appreciate it if a core committer can comment on it.
> 
> It works on my machine.  But since it slows down Ruby a bit, we
> haven't decided yet to merge it officially.  Do you (or anyone else)
> have something we can use for GC benchmark?
> 
> 							matz.

Hi.

Yes, I use the following tool for benchmarking:
http://pastebin.com/m26839d72

The results are as follows:

- Standard Ruby: 13.600 seconds
- My Ruby: 16.600 seconds

So the copy-on-write friendly GC seems to be about 20% slower. (At 
least, on this machine. I've noticed that the percentage can vary wildly 
depending on the specific machine. On some machines it only seems to be 
about 5% slower.)

However, I've recently submitted a patch which implements pluggable 
marking tables. By default, it uses the non-copy-on-write-friendly 
implementation (i.e. the same as the old one, which uses mark flags on 
the objects directly). So if I remove the "GC.copy_on_write_friendly = 
true" line, then the result is as follows:

- My Ruby: 13.394 seconds

So by default, performance is on par with standard Ruby. Only if the 
programmer has explicitly set "GC.copy_on_write_friendly = true" will 
there be a speed hit.

The standard Ruby version I use is 1.8.6 patchlevel 114. My modified 
Ruby is also based on that version. Both Ruby binaries are compiled with 
'-g' (i.e. no optimizations).

Finally, I've benchmarked some Ruby on Rails applications. Only 10% of 
the total application time seems to be spent on the garbage collector. 
So if the garbage collector is 20% slower, then it only results in a 2% 
speed reduction in total.

I'd like to know whether my patches are acceptable, now that it's just 
as fast as the normal Ruby by default. And if it's not acceptable, I'd 
like to know how many % speed hit would be acceptable.

Thanks.

- Hongli Lai

In This Thread