[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
(2014/03/07 19:09), normalperson@yhbt.net wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
Hi Eric,
SASADA Koichi <ko1@atdot.net> wrote:
(2014/03/14 2:12), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
(2014/03/18 8:03), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
what's the profit from using binary tree in place of hash?
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
[ruby-core:61568] hash function for global method cache
I came upon this because I noticed existing st numtable worked poorly with power-of-two hashes in [ruby-core:61243]. Global method cache is power-of-two-sized; so it should have a good hash function. In vm_method.c: #define GLOBAL_METHOD_CACHE_KEY(c,m) ((((c)>>3)^(m))&GLOBAL_METHOD_CACHE_MASK) Where c = klass; m = id (method ID) I'm a bit puzzled by the existing hash, since: 1) low 3 (scope) bits of method ID are infrequently set 2) c is a heap address, where c % sizeof(RValue) == 0 is always true 3) high bits of ID are always zero 4) high bits of klass tend to not vary within the process Has anybody else looked into improving the hash function? So I think we can do better (but I'm not an expert in hashing). One thing I've also been meaning to do is use 21-bits of the SipHash(sym) value to generate IDs, which ought to hash better in st numtable than incrementing integers (but we will need to handle resolving ID potential collisions). This will be on my TODO list;