[#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;

13 messages 2014/03/12

[ruby-core:61576] Re: [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops

From: =?KOI8-R?B?4NLJyiDzz8vPzM/X?= <funny.falcon@...>
Date: 2014-03-18 09:43:24 UTC
List: ruby-core #61576
Can you test this
 + if (SYMBOL_P(a)) a = (a >> RUBY_SPECIAL_SHIFT) ^ (a >>
(RUBY_SPECIAL_SHIFT + 3)); /* 3=ID_SCOPE_SHIFT */


2014-03-18 13:02 GMT+04:00 Eric Wong <normalperson@yhbt.net>:

> normalperson@yhbt.net wrote:
> >       hash_aref_sym   1.000
>
> Lack of improvement here was disappointing since symbol keys are common,
> and this showed a regression on my x86 (32-bit) VMs.
>
> I tweaked rb_any_hash to be symbol-aware:
>
>         http://bogomips.org/ruby.git/patch?id=497ed6355
>
> 12-30% improvement on this test from trunk depending on CPU so far \o/
> (Phenom II X4 got 30%, newer/faster x86-64 CPUs show less speedup).
>
> I'm comfortable with improvements of this series on x86 VMs running on
> x86-64 (and of course native x86-64).
>
> Can anybody with real 32-bit hardware verify this series?  Not sure I
> can trust VM results; my remaining x86 hardware is on its last legs
> and showing occasional HW errors.
>
> git://80x24.org/ruby.git st-noprime-v4
>
>       st: use power-of-two sizes to avoid slow modulo ops
>       add hash benchmarks
>       st.c: tweak numhash to match common Ruby use cases
>       hash.c: improve symbol hash distribution
>

In This Thread