Messages in this thread |  | | Subject | Re: [PATCH] rw_semaphores, optimisations try #4 | Date | Thu, 26 Apr 2001 08:39:16 +0100 | From | David Howells <> |
| |
Andrea Arcangeli <andrea@suse.de> wrote: > It seems more similar to my code btw (you finally killed the useless > chmxchg ;).
CMPXCHG ought to make things better by avoiding the XADD(+1)/XADD(-1) loop, however, I tried various combinations and XADD beats CMPXCHG significantly.
Here's a quote from Borland assembler manual I managed to dig out, giving i486 timings on memory access:
ADDL/SUBL 3 cycles XADDL 4 cycles CMPXCHG 8 cycles (success) / 10 cycles (failure) LOCK +1 cycle minimum on this CPU
In reality, however, XADDL gives at least as good a result as ADDL/SUBL, maybe just a little bit better, but its hard to say. However, the penalty imposed on the other CPU (when it has to flush it's cache) probably more than makes up for the difference.
> I only had a short low at your attached patch, but the results are quite > suspect to my eyes beacuse we should still be equally fast in the fast > path and I should still beat you on the write fast path because I do a > much faster subl; js while you do movl -1; xadd ; js, while according to > your results you beat me on both. Do you have an explanation or you > don't know the reason either?
MOVL $1,EDX SUBL EDX,(EAX)
Works out faster than:
SUBL $1,(EAX)
as well... probably due to an avoided stall when the instruction before the snippet loads EAX from memory. Oh yes... "STC, SUBL" may also be faster too.
> I will re-benchmark the whole thing shortly. But before re-benchmark if you > have time could you fix the benchmark to use the variable pointer and send > me a new tarball? For your code it probably doesn't matter because you > dereference the pointer by hand anyways, but it matters for mine and we want > to benchmark real world fast path of course.
No, not till this evening now, I'm afraid.
As for real-world benchmarks, I suspect the fastpath is going to be sufficiently few cycles that it's drowned out by whatever bit of code is actually using it, like my Wine server module, which is where all this started for me.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |