Re: Hash Surprises with Fixnum, #hash, and #eql?

On Wed, Apr 27, 2011 at 7:33 AM, Charles Oliver Nutter
<[e-mail]> wrote:
> On Thu, Apr 21, 2011 at 6:28 AM, Robert Klemme
> <[e-mail]> wrote:
>> Please keep in mind that in a multithreaded environment there is
>> synchronization overhead. =A0A solution could use an AtomicBoolean
>> stored somewhere as static final. =A0Now all threads that need to make
>> the decision need to go through this. =A0Even if it is "only" volatile
>> semantics (and not synchronized) and allows for concurrent reads there
>> is a price to pay. =A0Using a ThreadLocal which is initialized during
>> thread construction or lazily would reduce synchronization overhead at
>> the risk of the flag value becoming outdated - an issue which becomes
>> worse with thread lifetime. =A0Applications which use a thread pool
>> could suffer.
>
> In this case, I'm not using a synchronized, atomic, *or* boolean
> field. Because of the rarity of Fixnum and Float modification and the
> potential for heavy perf impact, I'm considering redefinition of
> methods in one thread while another thread is calling those methods as
> somewhat undefined, at least for Fixnum and Float. That's not perfect
> (JVM could optimize such that one thread's modifications never are
> seen by another thread), but it's closer.

Is redefinition per thread a standard JRuby feature or is this
something you would add?  If it was something that would need adding I
wouldn't bother to do it.  That sounds like a major change.

> It's also worth pointing out that usually modifications to Fixnum or
> Float are done for DSL purposes, where there's less likelihood of
> heavy threading effects.
>
> You're right, though...if I made that field volatile (it doesn't need
> to be Atomic, since I only ever read *or* write, never both), the perf
> impact would be higher.

Right you are.  That occurred to me after posting as well but I didn't
bother to correct myself as the memory effects are identical.  The
only difference is one more dereferencing (which can make a difference
as you pointed out).

>> But I agree, the effect vastly depends on the frequency of Hash
>> accesses with a Fixnum key. =A0Unfortunately I guess nobody has figures
>> about this - and even if, those will probably largely vary with type
>> of application.
>
> I operate at too low a level to see the 10000-foot view of application
> performance. In other words, I spend my time optimizing individual
> core methods, individual Ruby language features, and runtime-level
> operations like calls and constant lookup...rather than really looking
> at full app performance. Once you get to the scale of a real app, the
> performance bottlenecks from badly-written code, slow IO, excessive
> object creation, slow libraries and other userland issues almost
> always trump runtime-level speed. As an example, I point at the fact
> that Ruby 1.9 is almost always much faster than Ruby 1.8, but Rails
> under Ruby 1.9 is only marginally faster than Rails on Ruby 1.8 (or so
> I've seen when people try to measure it).

That exactly demonstrates your point: Rails will spend most of its
time doing IO (to and from the database, to and from network clients).
 OTOH the small difference shows that Rails code cannot be awfully
written because otherwise you would likely notice a bigger difference.
:-)

> The benefit of a faster and faster runtime is often outweighed by
> writing better Ruby code in the first place. But I don't live in the
> application world...I work on JRuby low-level performance. You have to
> do the rest :)

Will do. :-)  I'd also love to lend JRuby a hand but unfortunately I
can't find the time right now.

Cheers

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/