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
I think Haitao is right given some stacks we've recently looked at. e.g.
https://gist.github.com/KellenSunderland/893d11165e19d1efcf5c0fe8e8584600
-Kellen
On Thu, Nov 23, 2017 at 7:32 PM, Haitao Wang wrote:
> Hi, Chris,
>
> As far as I know, the mutex implementation in Linux is
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
wrote:
> Do we
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 is
> always preferred
>
> T
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 consistently about 20-30% fast
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
