> Sorry about the typo and misnaming for the test program. I attached the correct version that prints the right labels.
>
> The results I posted did not use NPTL. (Presumably OpenMP wasn't targeted at NPTL either.) I don't think that NPTL has any bearing on the underlying issues that I mentioned, though path lengths are probably a bit shorter. It should also handle contention substantially better, but that wasn't tested.
>
> I did rerun the test case on a 900 MHz Itanium 2 machine with a more recent Debian installation with NPTL. I get 200msecs (20nsecs/iter) with the custom lock, and 768 for pthreads. (With static linking that decreases to 658 for pthreads.) Pthreads (and/or some of the other infrastructure) is clearly getting better, but I don't think the difference will disappear.
To make things more fair you should test against pthread spinlocks. Also,
for tight loops like that, even an extra call deep level (that pthread is
likely to do) is going to matter.
- Davide
-
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/