Vadim Chugunov
2014-Sep-26 19:47 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
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>
Yaron Keren
2014-Sep-26 20:01 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
Hi Vadim, Yes, exactly, what is the point of having two versions -pthreads and -win32threads when you can make -pthreads behave like -win32threads by disabling the use of pthreads etc? Yaron 2014-09-26 22:47 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>:> 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/c8dd4132/attachment.html>
Richard Gorton
2014-Sep-26 20:29 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
Really: STOP IT re: whining about windows threading vs. pthreads on windows.
A compiler is not, by design, a multi-threaded application.
Windows is, NOT, by design, amenable to posix threading. GET OVER IT.
If you want to build a high performance application, you are NOT using
Windows.
The reality is that Windows has been focused on programming for the
masses, not on performance.
There is nothing wrong with that, but trying to use LLVM as a 'forcing
function' to increase Windows performance is utterly silly.
On 9/26/2014 4:01 PM, Yaron Keren wrote:> Hi Vadim,
>
> Yes, exactly, what is the point of having two versions -pthreads and
> -win32threads when you can make -pthreads behave like -win32threads by
> disabling the use of pthreads etc?
>
> Yaron
>
>
> 2014-09-26 22:47 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com
> <mailto:vadimcn at gmail.com>>:
>
> 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 <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto:chandlerc at
google.com>>
> wrote:
>
>
> On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes
> <ofv at wanadoo.es <mailto: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 <mailto: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 <mailto: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/2df0ba45/attachment.html>
Vadim Chugunov
2014-Sep-27 01:52 UTC
[LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
This might be a better question for mingw devs, but apparently these days GCC itself needs threads for something, and may be built on top of either win32 or posix threads. Vadim PS: I did some more testing, and it looks like when parallel code generation is actually used (4 threads), the difference becomes >20%. On Fri, Sep 26, 2014 at 1:01 PM, Yaron Keren <yaron.keren at gmail.com> wrote:> Hi Vadim, > > Yes, exactly, what is the point of having two versions -pthreads and > -win32threads when you can make -pthreads behave like -win32threads by > disabling the use of pthreads etc? > > Yaron > > > 2014-09-26 22:47 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>: > >> 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 >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140926/7e6e5c64/attachment.html>