Hi Davi, thanks for this information, it is really useful. According to bzr history fast mutex was added back in 2005. I have a few guesses why it would have been needed: - probably at that time mutex implementation wasn't as good as it is now - probably mutex implementation on some specific platform isn't good enough As for the hardware: I ran my benchmark on Core 2 Duo (from 2006) but with recent Ubuntu installed. Results were very similar: fast mutex was outsider. Moreover adaptive mutex does very similar job much better. Still not as good as normal mutex. Thanks, Sergey On Thu, Feb 27, 2014 at 09:08:42PM -0800, Davi Arnaut wrote:
Hi Sergey,
I looked into fast mutex in the past [1] and was never able to get a straight answer (even from the original developer) on what was the intention behind it and how it made things faster as it actually made things slower in the past (Bug#38941, others). There is a comment in http://bugs.mysql.com/bug.php?id=58766 highlighting one case where I saw a small performance improvement, but even that was highly workload/hardware dependent (can't recall which workload exactly, might have been sysbench's point select or something similar).
1. http://dev.mysql.com/worklog/task/?id=4601
On Wed, Feb 26, 2014 at 10:36 PM, Sergey Vojtovich <svoj@mariadb.org> wrote:
Hi Sergei,
do you know if we ship any binaries with fast mutex (-DMY_PTHREAD_FASTMUTEX) enabled or officially suggest it? What was it's intention and what loads it was supposed to make faster?
I'm trying to understand if fastmutex is worth fixing. It looks like duplication of PTHREAD_MUTEX_ADAPTIVE_NP, so we have double spinning when they're enabled. According to my recent benchmarks it shown worst performance.
Thanks, Sergey
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp