Vadim Chugunov
2014-Sep-25 06:52 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
Hi, I think I can at least answer why the Rust project prefers to use mingw-w64-win32threads: 1. It does not inject dependency on libwinpthread.dll, which is nice. 2. Those who tried building LLVM with mingw-w64-pthreads, had reported significant slowdown of the resulting Rust compiler (as compared to one linked to LLVM compiled with the win32threads flavor). Profiling seemed to point towards libpthreads' implementation of mutex. I had checked the source, and indeed, it looked not very efficient ( http://sourceforge.net/p/mingw-w64/bugs/344). It would be nice to get a second opinion, though, maybe I missed something. Vadim On Wed, Sep 24, 2014 at 10:55 AM, Chandler Carruth <chandlerc at google.com> wrote:> > On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > >> The best thing for understanding their reasons is to ask them to speak >> up. >> > > I asked them directly, and this thread is a chance for them to speak up > again. I *think* I've addressed the concerns of those I've spoken to > directly, but there may be other folks or other concerns or I may have > messed it up. =] > > >> My experience on the MinGW/MinGW-w64 communities is that those who >> choose MinGW is because of ignorance about MinGW-w64 and because there >> are lots of documents on the 'net that references MinGW. MinGW is, to >> all practical effects, a zombie project and there is no reason to prefer >> it over MinGW-w64 nowadays. >> > > :: shrug :: > > I'm not such a user, and so I don't want to speculate as to what motivates > them. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/df878b17/attachment.html>
Yaron Keren
2014-Sep-25 08:24 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
Vadim, Thanks for the feedback on the -win32. A dependency on a small DLL with BSD license does not sound too bad, but performance regression is obviously a serious problem. However, by disabling <mutex> use with -pthreads rust performance should be same as -win32 threads? Saying it another way, does the -win32 version have any feature that -pthreads vesion do not have? Yaron 2014-09-25 9:52 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>:> Hi, > I think I can at least answer why the Rust project prefers to use > mingw-w64-win32threads: > 1. It does not inject dependency on libwinpthread.dll, which is nice. > 2. Those who tried building LLVM with mingw-w64-pthreads, had reported > significant slowdown of the resulting Rust compiler (as compared to one > linked to LLVM compiled with the win32threads flavor). Profiling seemed > to point towards libpthreads' implementation of mutex. I had checked the > source, and indeed, it looked not very efficient ( > http://sourceforge.net/p/mingw-w64/bugs/344). It would be nice to get a > second opinion, though, maybe I missed something. > > Vadim > > > On Wed, Sep 24, 2014 at 10:55 AM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> >>> The best thing for understanding their reasons is to ask them to speak >>> up. >>> >> >> I asked them directly, and this thread is a chance for them to speak up >> again. I *think* I've addressed the concerns of those I've spoken to >> directly, but there may be other folks or other concerns or I may have >> messed it up. =] >> >> >>> My experience on the MinGW/MinGW-w64 communities is that those who >>> choose MinGW is because of ignorance about MinGW-w64 and because there >>> are lots of documents on the 'net that references MinGW. MinGW is, to >>> all practical effects, a zombie project and there is no reason to prefer >>> it over MinGW-w64 nowadays. >>> >> >> :: shrug :: >> >> I'm not such a user, and so I don't want to speculate as to what >> motivates them. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140925/10b1ce60/attachment.html>
Vadim Chugunov
2014-Sep-26 08:39 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
Hi Yaron, Not sure I understand your question. Wasn't <mutex> one of the more important C++11 features that LLVM would like to use? On Thu, Sep 25, 2014 at 1:24 AM, Yaron Keren <yaron.keren at gmail.com> wrote:> Vadim, > > Thanks for the feedback on the -win32. A dependency on a small DLL with > BSD license does not sound too bad, but performance regression is obviously > a serious problem. > > However, by disabling <mutex> use with -pthreads rust performance should > be same as -win32 threads? > Saying it another way, does the -win32 version have any feature that > -pthreads vesion do not have? > > Yaron > > > 2014-09-25 9:52 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>: > >> Hi, >> I think I can at least answer why the Rust project prefers to use >> mingw-w64-win32threads: >> 1. It does not inject dependency on libwinpthread.dll, which is nice. >> 2. Those who tried building LLVM with mingw-w64-pthreads, had reported >> significant slowdown of the resulting Rust compiler (as compared to one >> linked to LLVM compiled with the win32threads flavor). Profiling seemed >> to point towards libpthreads' implementation of mutex. I had checked the >> source, and indeed, it looked not very efficient ( >> http://sourceforge.net/p/mingw-w64/bugs/344). It would be nice to get a >> second opinion, though, maybe I missed something. >> >> Vadim >> >> >> On Wed, Sep 24, 2014 at 10:55 AM, Chandler Carruth <chandlerc at google.com> >> wrote: >> >>> >>> On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: >>> >>>> The best thing for understanding their reasons is to ask them to speak >>>> up. >>>> >>> >>> I asked them directly, and this thread is a chance for them to speak up >>> again. I *think* I've addressed the concerns of those I've spoken to >>> directly, but there may be other folks or other concerns or I may have >>> messed it up. =] >>> >>> >>>> My experience on the MinGW/MinGW-w64 communities is that those who >>>> choose MinGW is because of ignorance about MinGW-w64 and because there >>>> are lots of documents on the 'net that references MinGW. MinGW is, to >>>> all practical effects, a zombie project and there is no reason to prefer >>>> it over MinGW-w64 nowadays. >>>> >>> >>> :: shrug :: >>> >>> I'm not such a user, and so I don't want to speculate as to what >>> motivates them. >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140926/a889cead/attachment.html>
Maybe Matching Threads
- [LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
- [LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
- [LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
- [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
- [LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex