Thorsten Behrens wrote:
Stephan Bergmann <[EMAIL PROTECTED]> writes:
So, depending on CPU type, the version with LOCK is 2--8 times slower
than the version without LOCK. Would be interesting to see whether
this has any actual impact on overall OOo performance.
Hm. First off, I'd try to inline those asm snippets (except for the
sparc ones, which use a function ptr to dynamically distinguish
between v8 and v9 instruction sets).
We can inline the sparc ones, too. Since the last compiler change we
support only v8plus (V9 architecture, but in 32 mode). The distinction
between the spin lock implementation and the (faster) "cas" based
implementation is no longer necessary, maybe with the exception of
NetBSD/Sparc (have to ask sparcmoz if he still supports v7/v8 architectures)
If there is a consent that inlining osl_[in|de]crementInterLockedCount()
is worthwhile, I'm volunteering to do the change.
I can't see what we could do about the costs of the "lock" instruction
on x86. I mean, if we need an atomic increment/decrement for our
reference counter we can't work with non-atomic instructions here,
especially now when multi-processor/multi-core PCs are entering the
mainstream.
Heiner
Function call overhead for a
simple increment appears somewhat disproportionate to me...
Apart from that, with the integration of the UNO threading framework,
there's opportunity to bin thread-safe implementations at tons of
places, isn't there?
Cheers,
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
