From: "Юрий Соколов" Date: 2015-08-13T04:05:01+03:00 Subject: [ruby-core:70360] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI --f46d043c7f5cc73bff051d26ec62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 : > SASADA Koichi 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). > --f46d043c7f5cc73bff051d26ec62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I've make 16byte headers for coalesce chainging a= nd quadratic probing.

https://github.com/ko1/ruby/pull/3

Quadratic probing (23)= also uses smaller space cause uses same COMPUTED_VALUES layout.

<= div class=3D"gmail_extra">

2015-08-13 2:07 GM= T+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= they
> > 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 lik= e
> updating tables during foreach, and so on. Just now, we need to clear<= br> > usages first. I think impact of flexible array is not so big (compare<= br> > 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.=C2=A0 It makes very complicated corner cases in st.c

> For embedding tables, I also negative because we need to expose table<= br> > 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).

--f46d043c7f5cc73bff051d26ec62--