From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2003-11-17 20:13:14
> On Behalf Of Philippe A. Bouchard
> > For win32 the fastest approach I've found is to turn on the using
> > intrinsics optimization for win32... though your mileage may vary.
> > Also
> > be warned I've found a roughly 3 to 1 difference between AMD and
> > P4s on this because of the processor differences.
> Interesting... Intel is usually faster for those memory-access
Yep, in the past Intel has seemed to have advantage there.
W.r.t. interlocked increment, I don't know why it is faster on AMD, but
I suspect it has something to do with flushing the pipeline perhaps and
the P4 has a long one. FWIW, I've profiled the P3 to beat a P4 on
interlocked increment at around a third the clock ;-)
At least it is something to take into account when you see a benchmark.
You might see a 200% slow down between relative speeds on different
architectures just due to this kind of factor.
> The interesting part is to speed up existing code with minimal
> knowing it cannot be faster. I am looking forward for eventual
> against Hans-Boehm's garbage collectors ;) To be honest with you,
> on this full-time... I would implement my "real-time" collector to
> instantaneously of cyclic references and add atomic reference count
> operations immediately.
Yep, a reference without the need for a lock would be a big win. Not
sure how you would make this safe in the garbage collector though as a
mark sweep could cause a pause. Perhaps there is an optimistic
technique, such as a timestamp/cyclestamp, than can rollback on
conflict, perhaps over two phases. I'll have to think some more about
such optimism, perhaps you could use such an approach for updating the
reference count with a roll-back and try again semantics... Hmmm.
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk