[#54777] [ruby-trunk - Feature #8368][Open] Socket.getifaddrs — "akr (Akira Tanaka)" <akr@...>
6 messages
2013/05/04
[#54784] Call setlocale(LC_ALL, "") instead of setlocale(LC_CTYPE, "") — Nikolai Weibull <now@...>
Hi!
6 messages
2013/05/04
[#54786] Re: Call setlocale(LC_ALL, "") instead of setlocale(LC_CTYPE, "")
— Tanaka Akira <akr@...>
2013/05/04
2013/5/5 Nikolai Weibull <[email protected]>:
[#54800] Re: Call setlocale(LC_ALL, "") instead of setlocale(LC_CTYPE, "")
— Nikolai Weibull <now@...>
2013/05/05
On Sun, May 5, 2013 at 12:56 AM, Tanaka Akira <[email protected]> wrote:
[#54810] Re: Call setlocale(LC_ALL, "") instead of setlocale(LC_CTYPE, "")
— KOSAKI Motohiro <kosaki.motohiro@...>
2013/05/05
>> I think it is acceptable that make ruby more robust.
[#54850] [ruby-trunk - Feature #8377][Open] Deprecate :: for method calls in 2.1 — "charliesome (Charlie Somerville)" <charliesome@...>
27 messages
2013/05/07
[#54915] [ruby-trunk - Feature #8377] Deprecate :: for method calls in 2.1
— "jeremyevans0 (Jeremy Evans)" <merch-redmine@...>
2013/05/11
[#54900] [ruby-trunk - Bug #8386][Open] OpenSSL thread safety — "dbussink (Dirkjan Bussink)" <d.bussink@...>
12 messages
2013/05/10
[#54924] Re: [ruby-changes:28599] hsbt:r40651 (trunk): fixed wrong document for Socket.tcp by @lann [fix GH-302] — Tanaka Akira <akr@...>
2013/5/12 hsbt <[email protected]>:
4 messages
2013/05/12
[#54939] [ruby-trunk - Bug #8399][Open] Remove usage of RARRAY_PTR in C extensions when not needed — "dbussink (Dirkjan Bussink)" <d.bussink@...>
32 messages
2013/05/12
[#54963] [ruby-trunk - Bug #8399] Remove usage of RARRAY_PTR in C extensions when not needed
— "dbussink (Dirkjan Bussink)" <d.bussink@...>
2013/05/13
[#55001] [ruby-trunk - Bug #8399] Remove usage of RARRAY_PTR in C extensions when not needed
— "dbussink (Dirkjan Bussink)" <d.bussink@...>
2013/05/15
[#55004] Re: [ruby-trunk - Bug #8399] Remove usage of RARRAY_PTR in C extensions when not needed
— SASADA Koichi <ko1@...>
2013/05/15
(2013/05/15 14:38), dbussink (Dirkjan Bussink) wrote:
[#55053] [ruby-trunk - Feature #8426][Open] Implement class hierarchy method caching — "charliesome (Charlie Somerville)" <charliesome@...>
21 messages
2013/05/19
[#55077] Re: [ruby-trunk - Feature #8426][Open] Implement class hierarchy method caching
— SASADA Koichi <ko1@...>
2013/05/20
Great work!
[#55083] Re: [ruby-trunk - Feature #8426][Open] Implement class hierarchy method caching
— Charlie Somerville <charlie@...>
2013/05/20
On Monday, 20 May 2013 at 1:35 PM, SASADA Koichi wrote:
[#55085] Re: [ruby-trunk - Feature #8426][Open] Implement class hierarchy method caching
— SASADA Koichi <ko1@...>
2013/05/20
(2013/05/20 18:21), Charlie Somerville wrote:
[#55058] [ruby-trunk - Feature #5458] DL should be removed — "luislavena (Luis Lavena)" <luislavena@...>
3 messages
2013/05/19
[#55068] Re: [ruby-cvs:48003] zzak:r40834 (trunk): * lib/pp.rb: Document PP::ObjectMixin [Fixes GH-312] — Tanaka Akira <akr@...>
2013/5/20 <[email protected]>:
7 messages
2013/05/20
[#55071] Re: [ruby-cvs:48003] zzak:r40834 (trunk): * lib/pp.rb: Document PP::ObjectMixin [Fixes GH-312]
— Zachary Scott <zachary@...>
2013/05/20
@akr Oh, thank you for pointing that out!
[#55072] Re: [ruby-cvs:48003] zzak:r40834 (trunk): * lib/pp.rb: Document PP::ObjectMixin [Fixes GH-312]
— Tanaka Akira <akr@...>
2013/05/20
2013/5/20 Zachary Scott <[email protected]>:
[#55073] Re: [ruby-cvs:48003] zzak:r40834 (trunk): * lib/pp.rb: Document PP::ObjectMixin [Fixes GH-312]
— Zachary Scott <zachary@...>
2013/05/20
On Sun, May 19, 2013 at 10:11 PM, Tanaka Akira <[email protected]> wrote:
[#55075] Re: [ruby-cvs:48003] zzak:r40834 (trunk): * lib/pp.rb: Document PP::ObjectMixin [Fixes GH-312]
— Tanaka Akira <akr@...>
2013/05/20
2013/5/20 Zachary Scott <[email protected]>:
[#55096] [ruby-trunk - Feature #8430][Open] Rational number literal — "mrkn (Kenta Murata)" <muraken@...>
28 messages
2013/05/21
[#55197] [ruby-trunk - Feature #8461][Open] Easy way to disable certificate checking in XMLRPC::Client — "herwinw (Herwin Weststrate)" <herwin@...>
11 messages
2013/05/29
[#55198] [ruby-trunk - Feature #8462][Open] Module.remove_const inconsistant naming — "kyledecot (Kyle Decot)" <kyle.decot@...>
7 messages
2013/05/29
[ruby-core:54941] Re: [ruby-trunk - Bug #8399][Open] Remove usage of RARRAY_PTR in C extensions when not needed
From:
Eric Wong <normalperson@...>
Date:
2013-05-12 22:30:31 UTC
List:
ruby-core #54941
"dbussink (Dirkjan Bussink)" <[email protected]> wrote: > Rubinius uses quite a few C extensions directly from MRI. Some of > these use functionality such as RARRAY_PTR which is not necessary. For > compatibility reasons, RARRAY_PTR works on Rubinius but suffers from a > heavy performance penalty. Take for example the test of the parser gem > (http://github.com/whitequark/parser). These run over 10x faster with > the patch applied to Racc that is submitted here: I am curious how Rubinius implements RARRAY_PTR and why it cannot be made faster (especially in the non-resizing case). Are the native (for Rubinius) memory region for arrays not contiguous? I also remember asking for RSTRUCT_PTR in Rubinius a few years ago and was turned down. I expect Array/Struct to use a contiguous memory region (regardless of programming language, but I learned C/ASM first) I don't know much about GC implementation, but I think non-resizing accesses from C API ought to have no effect (though entering C code in the first place may be expensive). > https://gist.github.com/dbussink/57c32c08fb21c7a41719 What is the performance change for MRI? > Consider issue #8339 where there is work being done on generational > GC, I think it is also beneficial to remove usage of internal > structures such as RARRAY_PTR where there is the problem of going > around the write barrier. In Rubinius, an array is treated special if > RARRAY_PTR is used on it in the C-API, so I can imagine MRI being able > to optimize the GC better if extensions don't do this. There are > functions available for both getting and setting elements in an array > and they work fine. > > I have only make a patch against Racc here as a showcase, I also want > to update all the other extensions to remove RARRAY_PTR. Please > consider this change to MRI since in my opinion it has benefits also > for MRI and so Rubinius can keep using these extensions directly > without having to maintain custom versions just for the considerations > described here. I'm also already actively checking C extension gems > and sending pull requests for updating this. Since I maintain a few C extensions myself, I'll be following this and see how it plays out.