Yes, here are some links that confirm Haitao Wang’s statement:
The classic book, The linux programming interface, by Michael Kerrisk:
On Linux, mutexes are implemented using futexes(an acronym derived from fast
user space mutexes), and lock contentions are dealt with using the
futex()system
call
implementation in Linux is based on futex
> already.
>
> Thanks,
> Haitao
>
> -Original Message-
> From: dev-return-1553-haitao=openailab@mxnet.incubator.apache.org
> [mailto:dev-return-1553-haitao=openailab@mxnet.incubator.apache.org]
> On Behalf Of Chris Oliv
Hi, Chris,
As far as I know, the mutex implementation in Linux is based on futex already.
Thanks,
Haitao
-Original Message-
From: dev-return-1553-haitao=openailab@mxnet.incubator.apache.org
[mailto:dev-return-1553-haitao=openailab@mxnet.incubator.apache.org] On
Behalf Of Chris
Is there a claim of a mutex bottleneck in mxnet? I am not aware of any,
unless someone knows otherwise.
Database engines tend to be collision-happy, but mxnet does not seem to be
as far as I know, unless someone knows differently.
On Thu, Nov 23, 2017 at 11:06 AM, Bhavin Thaker
Do we have performance/profiling measurement evidence to prove/disprove the
claims of the impact of mutex bottleneck in MXNet?
Bhavin Thaker.
On Thu, Nov 23, 2017 at 11:03 AM Tianqi Chen
wrote:
> If they are not bottleneck. Then resorting to standard library solution
If they are not bottleneck. Then resorting to standard library solution is
always preferred
Tianqi
On Thu, Nov 23, 2017 at 11:01 AM, Chris Olivier
wrote:
> Was doing some timing with futexes (we used them a lot in a previous life
> in database engines) and they're
Was doing some timing with futexes (we used them a lot in a previous life
in database engines) and they're consistently about 20-30% faster than
standard mutexes in Linux.
However, it seems like this is not worth making a change since mutexes
don't tend to get called so much that it would seem to