Forum: Ruby-core [ruby-trunk - misc #8962][Open] [DOC] add step to enable Generational GC merits in README.EXT*

C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 tad (Tadashi Saito) (Guest)
on 2013-09-28 10:06
(Received via mailing list)
Issue #8962 has been reported by tad (Tadashi Saito).

----------------------------------------
misc #8962: [DOC] add step to enable Generational GC merits in
README.EXT*
https://bugs.ruby-lang.org/issues/8962

Author: tad (Tadashi Saito)
Status: Open
Priority: Normal
Assignee: zzak (Zachary Scott)
Category: doc
Target version: current: 2.1.0


=begin

Is there any chance to reap the benefit of new Generational GC merits
for
C-extension library authors?

== Background

First of all: RGenGC is great.  Ko1 showed that it could make
significant
performance improvement at RubyKaigi2013. (especially P82)
http://www.atdot.net/~ko1/activities/RubyKaigi2013-ko1.pdf

I guess the improvement is triggered by marking most (or all?) of
built-in
classes as WB-protected struct to work with Generational GC.

== Motivation

As a extension library author, I want to try to get the performance
merit.
But there is no document or guide to enable it.

The PDF says "Inserting WBs step by step, and increase performance
gradually",
and I believe it is the greatest point of RGenGC, but there is no guide
to
proceed with the steps for now. It's sad.

== Subject

Could you write about it as a document, ko1 or anyone?
I guess it's good to be written at README.EXT*.
(The case of iseq.c may be used as an example.)

I'm glad to see the documents are written before Ruby 2.1 release.

== Restriction

Sorry for the absence of my knowledge.  Because I'm not good at
RGenGC, I could't write the document by myself but could only request.

PS
I guess this issue depends on #3064 (sorry, in Japanse), the request of
documenting RTypedData, because there is no interface to specify
FL_WB_PROTECTED flag with traditional RData.

=end
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-09-28 13:38
(Received via mailing list)
Issue #8962 has been updated by nobu (Nobuyoshi Nakada).

Description updated


----------------------------------------
misc #8962: [DOC] add step to enable Generational GC merits in
README.EXT*
https://bugs.ruby-lang.org/issues/8962#change-42069

Author: tad (Tadashi Saito)
Status: Open
Priority: Normal
Assignee: zzak (Zachary Scott)
Category: doc
Target version: current: 2.1.0


=begin

Is there any chance to reap the benefit of new Generational GC merits
for
C-extension library authors?

== Background

First of all: RGenGC is great.  Ko1 showed that it could make
significant
performance improvement at RubyKaigi2013. (especially P82)
((<RubyKaigi2013-ko1.pdf|URL:http://www.atdot.net/~ko1/activities/RubyKaigi2013...))

I guess the improvement is triggered by marking most (or all?) of
built-in
classes as WB-protected struct to work with Generational GC.

== Motivation

As an extension library author, I want to try to get the performance
merit.
But there is no document or guide to enable it.

The PDF says "Inserting WBs step by step, and increase performance
gradually",
and I believe it is the greatest point of RGenGC, but there is no guide
to
proceed with the steps for now. It's sad.

== Subject

Could you write about it as a document, ko1 or anyone?
I guess it's good to be written at ((%README.EXT*%)).
(The case of ((%iseq.c%)) may be used as an example.)

I'm glad to see the documents are written before Ruby 2.1 release.

== Restriction

Sorry for the absence of my knowledge.  Because I'm not good at
RGenGC, I could't write the document by myself but could only request.

PS
I guess this issue depends on #3064 (sorry, in Japanse), the request of
documenting (({RTypedData})), because there is no interface to specify
(({FL_WB_PROTECTED})) flag with traditional (({RData})).

=end
054b5f6b8afdd5f6190bad08e46cd782?d=identicon&s=25 zzak (Zachary Scott) (Guest)
on 2013-10-15 17:10
(Received via mailing list)
Issue #8962 has been updated by zzak (Zachary Scott).

Status changed from Open to Assigned

Koichi, could you add some notes on this, maybe link to helpful RGenGC
documentation.

I will bug you again at RubyConf :)
----------------------------------------
misc #8962: [DOC] add step to enable Generational GC merits in
README.EXT*
https://bugs.ruby-lang.org/issues/8962#change-42473

Author: tad (Tadashi Saito)
Status: Assigned
Priority: Normal
Assignee: zzak (Zachary Scott)
Category: doc
Target version: current: 2.1.0


=begin

Is there any chance to reap the benefit of new Generational GC merits
for
C-extension library authors?

== Background

First of all: RGenGC is great.  Ko1 showed that it could make
significant
performance improvement at RubyKaigi2013. (especially P82)
((<RubyKaigi2013-ko1.pdf|URL:http://www.atdot.net/~ko1/activities/RubyKaigi2013...))

I guess the improvement is triggered by marking most (or all?) of
built-in
classes as WB-protected struct to work with Generational GC.

== Motivation

As an extension library author, I want to try to get the performance
merit.
But there is no document or guide to enable it.

The PDF says "Inserting WBs step by step, and increase performance
gradually",
and I believe it is the greatest point of RGenGC, but there is no guide
to
proceed with the steps for now. It's sad.

== Subject

Could you write about it as a document, ko1 or anyone?
I guess it's good to be written at ((%README.EXT*%)).
(The case of ((%iseq.c%)) may be used as an example.)

I'm glad to see the documents are written before Ruby 2.1 release.

== Restriction

Sorry for the absence of my knowledge.  Because I'm not good at
RGenGC, I could't write the document by myself but could only request.

PS
I guess this issue depends on #3064 (sorry, in Japanse), the request of
documenting (({RTypedData})), because there is no interface to specify
(({FL_WB_PROTECTED})) flag with traditional (({RData})).

=end
852ee3dd3c2f9889e49cbec473a58e75?d=identicon&s=25 Tadashi Saito (Guest)
on 2013-11-30 16:44
(Received via mailing list)
ping?


2013/10/16 zzak (Zachary Scott) <e@zzak.io>
054b5f6b8afdd5f6190bad08e46cd782?d=identicon&s=25 zzak (Zachary Scott) (Guest)
on 2013-12-06 06:34
(Received via mailing list)
Issue #8962 has been updated by zzak (Zachary Scott).

Assignee changed from zzak (Zachary Scott) to ko1 (Koichi Sasada)

During the 2013-12-05 developers meeting[1] Koichi was given this
assignment, and I will help him write the documentation.

1:
http://bugs.ruby-lang.org/projects/ruby/wiki/Devel...
----------------------------------------
misc #8962: [DOC] add step to enable Generational GC merits in
README.EXT*
https://bugs.ruby-lang.org/issues/8962#change-43446

Author: tad (Tadashi Saito)
Status: Assigned
Priority: Normal
Assignee: ko1 (Koichi Sasada)
Category: doc
Target version: current: 2.1.0


=begin

Is there any chance to reap the benefit of new Generational GC merits
for
C-extension library authors?

== Background

First of all: RGenGC is great.  Ko1 showed that it could make
significant
performance improvement at RubyKaigi2013. (especially P82)
((<RubyKaigi2013-ko1.pdf|URL:http://www.atdot.net/~ko1/activities/RubyKaigi2013...))

I guess the improvement is triggered by marking most (or all?) of
built-in
classes as WB-protected struct to work with Generational GC.

== Motivation

As an extension library author, I want to try to get the performance
merit.
But there is no document or guide to enable it.

The PDF says "Inserting WBs step by step, and increase performance
gradually",
and I believe it is the greatest point of RGenGC, but there is no guide
to
proceed with the steps for now. It's sad.

== Subject

Could you write about it as a document, ko1 or anyone?
I guess it's good to be written at ((%README.EXT*%)).
(The case of ((%iseq.c%)) may be used as an example.)

I'm glad to see the documents are written before Ruby 2.1 release.

== Restriction

Sorry for the absence of my knowledge.  Because I'm not good at
RGenGC, I could't write the document by myself but could only request.

PS
I guess this issue depends on #3064 (sorry, in Japanse), the request of
documenting (({RTypedData})), because there is no interface to specify
(({FL_WB_PROTECTED})) flag with traditional (({RData})).

=end
C4e88907313843cf07f6d85ba8162120?d=identicon&s=25 ko1 (Koichi Sasada) (Guest)
on 2013-12-24 06:33
(Received via mailing list)
Issue #8962 has been updated by ko1 (Koichi Sasada).

Status changed from Assigned to Closed


----------------------------------------
misc #8962: [DOC] add step to enable Generational GC merits in
README.EXT*
https://bugs.ruby-lang.org/issues/8962#change-43863

Author: tad (Tadashi Saito)
Status: Closed
Priority: Normal
Assignee: ko1 (Koichi Sasada)
Category: doc
Target version: current: 2.1.0


=begin

Is there any chance to reap the benefit of new Generational GC merits
for
C-extension library authors?

== Background

First of all: RGenGC is great.  Ko1 showed that it could make
significant
performance improvement at RubyKaigi2013. (especially P82)
((<RubyKaigi2013-ko1.pdf|URL:http://www.atdot.net/~ko1/activities/RubyKaigi2013...))

I guess the improvement is triggered by marking most (or all?) of
built-in
classes as WB-protected struct to work with Generational GC.

== Motivation

As an extension library author, I want to try to get the performance
merit.
But there is no document or guide to enable it.

The PDF says "Inserting WBs step by step, and increase performance
gradually",
and I believe it is the greatest point of RGenGC, but there is no guide
to
proceed with the steps for now. It's sad.

== Subject

Could you write about it as a document, ko1 or anyone?
I guess it's good to be written at ((%README.EXT*%)).
(The case of ((%iseq.c%)) may be used as an example.)

I'm glad to see the documents are written before Ruby 2.1 release.

== Restriction

Sorry for the absence of my knowledge.  Because I'm not good at
RGenGC, I could't write the document by myself but could only request.

PS
I guess this issue depends on #3064 (sorry, in Japanse), the request of
documenting (({RTypedData})), because there is no interface to specify
(({FL_WB_PROTECTED})) flag with traditional (({RData})).

=end
This topic is locked and can not be replied to.