[Maria-developers] MDEV-5081 - Simple performance improvement for MariaDB
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
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
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
Hi, Sergey! On Feb 27, Sergey Vojtovich 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?
As far as I understand, we built with fastmutex on Linux. See cmake/build_configurations/mysql_release.cmake
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.
Disable it then :) Regards, Sergei
Hi Sergei, indeed, but that's only for -DBUILD_CONFIG=mysql_release or explicit -DWITH_FAST_MUTEXES=ON. I though it should be enabled by -DCMAKE_BUILD_TYPE=Release (the way I was attempting to get it). Ok, I'll disable it in 5.5. Thanks, Sergey On Fri, Feb 28, 2014 at 09:52:00AM +0100, Sergei Golubchik wrote:
Hi, Sergey!
On Feb 27, Sergey Vojtovich 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?
As far as I understand, we built with fastmutex on Linux. See cmake/build_configurations/mysql_release.cmake
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.
Disable it then :)
Regards, Sergei
Hi, Sergey! On Feb 28, Sergey Vojtovich wrote:
Hi Sergei,
indeed, but that's only for -DBUILD_CONFIG=mysql_release or explicit -DWITH_FAST_MUTEXES=ON. I though it should be enabled by -DCMAKE_BUILD_TYPE=Release (the way I was attempting to get it).
We build release binaries (I believe) with -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release Regards, Sergei
participants (3)
-
Davi Arnaut -
Sergei Golubchik -
Sergey Vojtovich