Re: Futex

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

Re: Futex

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

RE: Futex

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

Re: Futex

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

Re: Futex

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

Re: Futex

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

Futex

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