llvm dev - Sep 2014 - [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>

Yes, of course.

I refer to the  significant slowdown of Rust compiler when compiled with
-pthreads vs -win32threads flavor.
If Rust can be compiled without <mutex> and <thread> on
win32threads, why
should it slow down on pthreads?
Isn't the only difference betwen the win32threads and pthreads is the
addition of pthreads, <mutex> and <thread>?

Yaron


2014-09-26 11:39 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>:
> 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/7dab44f1/attachment.html>

When LLVM's configure finds a usable <pthread.h>, it prefers to use
that
rather than the home-grown stuff.   However if LLVM is configured with
--disable-pthreads, both mingw flavors produce the same results.

BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM
build that uses pthreads is about 10% slower than the one which doesn't.
This is less that I remember seeing last year (something got optimized?),
but still...

Vadim

On Fri, Sep 26, 2014 at 3:29 AM, Yaron Keren <yaron.keren at gmail.com>
wrote:
> Yes, of course.
>
> I refer to the  significant slowdown of Rust compiler when compiled with
> -pthreads vs -win32threads flavor.
> If Rust can be compiled without <mutex> and <thread> on
win32threads, why
> should it slow down on pthreads?
> Isn't the only difference betwen the win32threads and pthreads is the
> addition of pthreads, <mutex> and <thread>?
>
> Yaron
>
>
> 2014-09-26 11:39 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>:
>
>> 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/1a2b50d1/attachment.html>