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 Olivier Sent: Friday, November 24, 2017 3:02 AM To: dev@mxnet.incubator.apache.org Subject: 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 make a noticeable difference, although I could be wrong -- so far besides the queue, I am not aware of any major bottlenecks on mutexes. Any thoughts? -Chris
RE: The Exchange Layer Support of MXNet
Just a quick question: Where to find the document to describe the standardized core operator set of Mxnet/gluon? Thanks, Haitao -Original Message- From: workc...@gmail.com [mailto:workc...@gmail.com] On Behalf Of Tianqi Chen Sent: Friday, October 20, 2017 11:43 AM To: dev@mxnet.incubator.apache.org Subject: The Exchange Layer Support of MXNet I will start forking the previous discussion and it has gone awry and I hope to start a pure technical discussion thread. I said in another email that we could do a vote to settle this issue. I now think that I was wrong and would like to apology for my rush proposal on this. I hope to reopen this email thread to gain consensus on what we want. There has been express of concerns that the code should reside on ApacheMXNet repo. I think that discussion is already over and at least I would want the code to be in the repo as long as we reach the consensus. The leftover point is how should we do it. There are two ways of doing this 1) Doing it on top of existing Symbol API. 2) Moving most of the exchange layer on standardized core operator set, namely mxnet/gluon spec. Both approaches are feasible. There is some advocation on which way might be simpler, but the additional effort of engineering won't be that much. The reason why I am seeing this decision so seriously is that it will affect how we can influence the design of the exchange format we act on, and how easily it is to integrate future features that are made available. I am in favor of (2) because technically it gives us a clean future compatibility, offers compilation and articulates clearly what ApacheMXNet's stance on core operators. These things could bring more impact to the community in general. Tianqi
Slack channel
Hi, Plz add me to the slack channel. Thanks, Haitao
