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 <vadi...@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 <chandl...@google.com>
> wrote:
>
>>
>> On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes <o...@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
>> llvm...@cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to