[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70360] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
From:
Юрий Соколов <funny.falcon@...>
Date:
2015-08-13 01:05:01 UTC
List:
ruby-core #70360
I've make 16byte headers for coalesce chainging and quadratic probing. https://github.com/ko1/ruby/pull/3 Quadratic probing (23) also uses smaller space cause uses same COMPUTED_VALUES layout. 2015-08-13 2:07 GMT+03:00 Eric Wong <normalperson@yhbt.net>: > SASADA Koichi <ko1@atdot.net> wrote: > > On 2015/08/13 4:29, =D0=AE=D1=80=D0=B8=D0=B9 =D0=A1=D0=BE=D0=BA=D0=BE= =D0=BB=D0=BE=D0=B2 wrote: > > > I thought to suggest to embed hash_id_table directly into places when > it > > > is used (instead of pointer to). > > > It will use 24byte on 64bit platform, so not too big. > > > It has benefit when used with jemalloc/tcmalloc which are good at > > > allocating sizes =3D 2**x. > > > With flexible array size will be not equal to power of 2, so that the= y > > > will consume a bit more memory on big tables. > > > > > > But I think flexible array are also very good idea. > > > Let me know, if I need to fix hash variant for this. > > > > For flexible array, I'm negative because it can conflict usage like > > updating tables during foreach, and so on. Just now, we need to clear > > usages first. I think impact of flexible array is not so big (compare > > with current implementation), or so big? > > Probably makes most difference with few (1..5) maybe? elements. > Since this is for internal use, we should disallow updates during > iteration. It makes very complicated corner cases in st.c > > > For embedding tables, I also negative because we need to expose table > > data structure for users. Just now, I want to hide it into id_table.c. > > Of course, if we decide this implementation finally, we can try it. > > I see no problem exposing data structures to internal.h users. > Just keep it out of public C API. > Only downside is increased compile time for C Ruby devs (I use ccache). >