PSA: GHC can now be built with Clang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Austin Seipp-4
Hi all,

As of commit 5dc74f it should now be possible to build a working
stage1 and stage2 compiler with (an extremely recent) Clang. With some
caveats.

You can just do:

$ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
$ make

I have done this work on Linux. I don't expect much difficulty on Mac
OS X, but it needs testing. Ditto with Windows, although Clang/mingw
is considered experimental.

The current caveats are:

 * The testsuite will probably fail everywhere, because of some
warnings that happen during the linking phase when you invoke the
built compiler. So the testsuite runner will probably be unhappy.
Clang is very noisy about unused options, unlike GCC. That needs to be
fixed somewhere in DriverPipeline I'd guess, but with some
refactoring.
 * Some of the stage2 libraries don't build due to a Clang bug. These
are vector/primitive/dph so far.
 * There is no buildbot or anything to cover it.

You will need a very recent Clang. Due to this bug (preventing
primitive etc from building,) you'll preferably want to use an SVN
checkout from about 6 hours ago at latest:

http://llvm.org/bugs/show_bug.cgi?id=16363

Hilariously, this bug was tripped on primitive's Data.Primitive.Types
module due to some CPP weirdness. But even with a proper bugfix and no
segfault, it still fails to correctly parse this same module with the
same CPP declarations. I'm fairly certain this is another bug in
Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
it will *probably* work if we just get rid of the CPP tomfoolery in
primitive. I'll be testing it in the next few days to see if we can
get 3.3 supported. (I'm sort of kicking myself in the head for not
doing this a week or two ago...)

Anyway, there are some rough edges but it should be in shape for 7.8 I
hope. It should be especially welcome for Mac users. (I'm also hoping
modern Macs could even go all-clang-all-the-time if my fix for #7602
can go in soon...)

PS. If you use ASSERT, I just fixed a lot of instances of using that
macro, involving whitespace between the name and arguments (commit
d8ee2b.) Clang does not forgive you for this. Should I note this
anywhere for the future in the wiki or something?

--
Regards,
Austin - PGP: 4096R/0x91384671


Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Carter Schonwald
Awesome!

I'm actually hitting another CPP bug right now in building ghc head with
clang head, also I'll reach out to an apple dude i know to find out if we
can get any help from them on this or the related TLS issue.


On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp <aseipp at pobox.com> wrote:

> Hi all,
>
> As of commit 5dc74f it should now be possible to build a working
> stage1 and stage2 compiler with (an extremely recent) Clang. With some
> caveats.
>
> You can just do:
>
> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
> $ make
>
> I have done this work on Linux. I don't expect much difficulty on Mac
> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
> is considered experimental.
>
> The current caveats are:
>
>  * The testsuite will probably fail everywhere, because of some
> warnings that happen during the linking phase when you invoke the
> built compiler. So the testsuite runner will probably be unhappy.
> Clang is very noisy about unused options, unlike GCC. That needs to be
> fixed somewhere in DriverPipeline I'd guess, but with some
> refactoring.
>  * Some of the stage2 libraries don't build due to a Clang bug. These
> are vector/primitive/dph so far.
>  * There is no buildbot or anything to cover it.
>
> You will need a very recent Clang. Due to this bug (preventing
> primitive etc from building,) you'll preferably want to use an SVN
> checkout from about 6 hours ago at latest:
>
> http://llvm.org/bugs/show_bug.cgi?id=16363
>
> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
> module due to some CPP weirdness. But even with a proper bugfix and no
> segfault, it still fails to correctly parse this same module with the
> same CPP declarations. I'm fairly certain this is another bug in
> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
> it will *probably* work if we just get rid of the CPP tomfoolery in
> primitive. I'll be testing it in the next few days to see if we can
> get 3.3 supported. (I'm sort of kicking myself in the head for not
> doing this a week or two ago...)
>
> Anyway, there are some rough edges but it should be in shape for 7.8 I
> hope. It should be especially welcome for Mac users. (I'm also hoping
> modern Macs could even go all-clang-all-the-time if my fix for #7602
> can go in soon...)
>
> PS. If you use ASSERT, I just fixed a lot of instances of using that
> macro, involving whitespace between the name and arguments (commit
> d8ee2b.) Clang does not forgive you for this. Should I note this
> anywhere for the future in the wiki or something?
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130619/7937a281/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Gabor Greif-2
Please make sure that all bugs are reported back to the Clang devs.
They are usually very fast in fixing them.

I assume that the ${CPP} is in traditional mode?

Cheers,

    Gabor


On 6/19/13, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> Awesome!
>
> I'm actually hitting another CPP bug right now in building ghc head with
> clang head, also I'll reach out to an apple dude i know to find out if we
> can get any help from them on this or the related TLS issue.
>
>
> On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp <aseipp at pobox.com> wrote:
>
>> Hi all,
>>
>> As of commit 5dc74f it should now be possible to build a working
>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>> caveats.
>>
>> You can just do:
>>
>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>> $ make
>>
>> I have done this work on Linux. I don't expect much difficulty on Mac
>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>> is considered experimental.
>>
>> The current caveats are:
>>
>>  * The testsuite will probably fail everywhere, because of some
>> warnings that happen during the linking phase when you invoke the
>> built compiler. So the testsuite runner will probably be unhappy.
>> Clang is very noisy about unused options, unlike GCC. That needs to be
>> fixed somewhere in DriverPipeline I'd guess, but with some
>> refactoring.
>>  * Some of the stage2 libraries don't build due to a Clang bug. These
>> are vector/primitive/dph so far.
>>  * There is no buildbot or anything to cover it.
>>
>> You will need a very recent Clang. Due to this bug (preventing
>> primitive etc from building,) you'll preferably want to use an SVN
>> checkout from about 6 hours ago at latest:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>
>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>> module due to some CPP weirdness. But even with a proper bugfix and no
>> segfault, it still fails to correctly parse this same module with the
>> same CPP declarations. I'm fairly certain this is another bug in
>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>> it will *probably* work if we just get rid of the CPP tomfoolery in
>> primitive. I'll be testing it in the next few days to see if we can
>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>> doing this a week or two ago...)
>>
>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>> hope. It should be especially welcome for Mac users. (I'm also hoping
>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>> can go in soon...)
>>
>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>> macro, involving whitespace between the name and arguments (commit
>> d8ee2b.) Clang does not forgive you for this. Should I note this
>> anywhere for the future in the wiki or something?
>>
>> --
>> Regards,
>> Austin - PGP: 4096R/0x91384671
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>


Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Austin Seipp-4
Yes, we're using -undef -traditional. We're also suppressing some
extra warnings from Clang concerning other things; you can see my
recent commits.

I have filed a related LLVM bug, regarding the preprocessor behavior
that affects primitive: http://llvm.org/bugs/show_bug.cgi?id=16371

I have worked around this bug manually inside primitive, and with it,
I have been able to do a complete stage2 build with all libraries up
to DPH, so we're extremely close! I'll keep hacking away in the mean
time.

On Wed, Jun 19, 2013 at 2:38 AM, Gabor Greif <ggreif at gmail.com> wrote:

> Please make sure that all bugs are reported back to the Clang devs.
> They are usually very fast in fixing them.
>
> I assume that the ${CPP} is in traditional mode?
>
> Cheers,
>
>     Gabor
>
>
> On 6/19/13, Carter Schonwald <carter.schonwald at gmail.com> wrote:
>> Awesome!
>>
>> I'm actually hitting another CPP bug right now in building ghc head with
>> clang head, also I'll reach out to an apple dude i know to find out if we
>> can get any help from them on this or the related TLS issue.
>>
>>
>> On Wed, Jun 19, 2013 at 12:44 AM, Austin Seipp <aseipp at pobox.com> wrote:
>>
>>> Hi all,
>>>
>>> As of commit 5dc74f it should now be possible to build a working
>>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>>> caveats.
>>>
>>> You can just do:
>>>
>>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>>> $ make
>>>
>>> I have done this work on Linux. I don't expect much difficulty on Mac
>>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>>> is considered experimental.
>>>
>>> The current caveats are:
>>>
>>>  * The testsuite will probably fail everywhere, because of some
>>> warnings that happen during the linking phase when you invoke the
>>> built compiler. So the testsuite runner will probably be unhappy.
>>> Clang is very noisy about unused options, unlike GCC. That needs to be
>>> fixed somewhere in DriverPipeline I'd guess, but with some
>>> refactoring.
>>>  * Some of the stage2 libraries don't build due to a Clang bug. These
>>> are vector/primitive/dph so far.
>>>  * There is no buildbot or anything to cover it.
>>>
>>> You will need a very recent Clang. Due to this bug (preventing
>>> primitive etc from building,) you'll preferably want to use an SVN
>>> checkout from about 6 hours ago at latest:
>>>
>>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>>
>>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>>> module due to some CPP weirdness. But even with a proper bugfix and no
>>> segfault, it still fails to correctly parse this same module with the
>>> same CPP declarations. I'm fairly certain this is another bug in
>>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>>> it will *probably* work if we just get rid of the CPP tomfoolery in
>>> primitive. I'll be testing it in the next few days to see if we can
>>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>>> doing this a week or two ago...)
>>>
>>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>>> hope. It should be especially welcome for Mac users. (I'm also hoping
>>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>>> can go in soon...)
>>>
>>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>>> macro, involving whitespace between the name and arguments (commit
>>> d8ee2b.) Clang does not forgive you for this. Should I note this
>>> anywhere for the future in the wiki or something?
>>>
>>> --
>>> Regards,
>>> Austin - PGP: 4096R/0x91384671
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>



--
Regards,
Austin - PGP: 4096R/0x91384671


Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Manuel M T Chakravarty
In reply to this post by Austin Seipp-4
Austin,

Thank you very much for taking care of all these clang issues ? that is very helpful!

Cheers,
Manuel

Austin Seipp <aseipp at pobox.com>:

> Hi all,
>
> As of commit 5dc74f it should now be possible to build a working
> stage1 and stage2 compiler with (an extremely recent) Clang. With some
> caveats.
>
> You can just do:
>
> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
> $ make
>
> I have done this work on Linux. I don't expect much difficulty on Mac
> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
> is considered experimental.
>
> The current caveats are:
>
> * The testsuite will probably fail everywhere, because of some
> warnings that happen during the linking phase when you invoke the
> built compiler. So the testsuite runner will probably be unhappy.
> Clang is very noisy about unused options, unlike GCC. That needs to be
> fixed somewhere in DriverPipeline I'd guess, but with some
> refactoring.
> * Some of the stage2 libraries don't build due to a Clang bug. These
> are vector/primitive/dph so far.
> * There is no buildbot or anything to cover it.
>
> You will need a very recent Clang. Due to this bug (preventing
> primitive etc from building,) you'll preferably want to use an SVN
> checkout from about 6 hours ago at latest:
>
> http://llvm.org/bugs/show_bug.cgi?id=16363
>
> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
> module due to some CPP weirdness. But even with a proper bugfix and no
> segfault, it still fails to correctly parse this same module with the
> same CPP declarations. I'm fairly certain this is another bug in
> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
> it will *probably* work if we just get rid of the CPP tomfoolery in
> primitive. I'll be testing it in the next few days to see if we can
> get 3.3 supported. (I'm sort of kicking myself in the head for not
> doing this a week or two ago...)
>
> Anyway, there are some rough edges but it should be in shape for 7.8 I
> hope. It should be especially welcome for Mac users. (I'm also hoping
> modern Macs could even go all-clang-all-the-time if my fix for #7602
> can go in soon...)
>
> PS. If you use ASSERT, I just fixed a lot of instances of using that
> macro, involving whitespace between the name and arguments (commit
> d8ee2b.) Clang does not forgive you for this. Should I note this
> anywhere for the future in the wiki or something?
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Austin Seipp-4
Thanks Manuel!

I have an update on this work (I am also CC'ing glasgow-haskell-users,
as I forgot last time.) The TL;DR is this:

 * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
 * I have a small, 6-line patch to Clang to fix the build failure in
primitive (Clang was too eager to stringify something.) Once this fix
is integrated into Clang (hopefully very soon,) it will be possible to
build GHC entirely including all stage2 libraries without any patches.
The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am
hoping this will also make it into XCode 5.
 * I still have to eliminate some warnings throughout the build, which
will require fiddling and a bit of refactoring. The testsuite still
probably won't run cleanly on Linux, at least, until this is done I'm
afraid (but then again I haven't tried...)

As for the infamous ticket #7602, the large performance regression on
Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS
approach.

./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  395.57s user
173.18s system 138% cpu 6:50.71 total

vs

./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  322.98s user
132.37s system 132% cpu 5:44.65 total

Now, this probably looks totally awful from a scalability POV. And,
well, yeah, it is. But I am almost 100% certain there is something
extremely screwy going on with my machine here. I base this on the
fact that during gc_bench, kernel_task was eating up about ~600% of my
CPU consistently, giving user threads no time to run. I've noticed
this with other applications that were totally unrelated too (close
tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or
turn it on and off again or something. Ugh.

Anyway, if you look at the user times, you get a nice 30% speedup
which is about what we expect!

On a related note, due to the source code structure at the moment,
Linux/Clang hilariously suffers from this same bug. That's because
while Clang on Linux supports extremely fast TLS via __thread (like
GCC,) it falls back to pthread_getspecific/setspecific. I haven't
fixed this yet. It'll happen after I fix #7602 and get it merged in.
On my Linux machine, gc_bench also sees a consistent 30% speedup
between these two approaches, so I think this is a relatively accurate
measurement. Well, as accurate as I can be without running nofib just
yet. So if you're just dying to have GHC HEAD built with Clang HEAD on
Linux because you've got reasons, you should probably hold on.

I also may have a similar, better approach to fixing #7602 that is not
entirely as evil and sneaky as crashing the WebKit party. I'll follow
up on this soon when I have more info in a separate thread to confer
with Simon. With nofib results. I hope.

But anyway, 7.8 will be shaping up quite nicely - in particular in the
Mac OS X department, I hope. Please feel free to pester me with
questions or if you attempt something and it doesn't work.

On Tue, Jun 25, 2013 at 7:34 PM, Manuel M T Chakravarty
<chak at cse.unsw.edu.au> wrote:

> Austin,
>
> Thank you very much for taking care of all these clang issues ? that is very helpful!
>
> Cheers,
> Manuel
>
> Austin Seipp <aseipp at pobox.com>:
>> Hi all,
>>
>> As of commit 5dc74f it should now be possible to build a working
>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>> caveats.
>>
>> You can just do:
>>
>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>> $ make
>>
>> I have done this work on Linux. I don't expect much difficulty on Mac
>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>> is considered experimental.
>>
>> The current caveats are:
>>
>> * The testsuite will probably fail everywhere, because of some
>> warnings that happen during the linking phase when you invoke the
>> built compiler. So the testsuite runner will probably be unhappy.
>> Clang is very noisy about unused options, unlike GCC. That needs to be
>> fixed somewhere in DriverPipeline I'd guess, but with some
>> refactoring.
>> * Some of the stage2 libraries don't build due to a Clang bug. These
>> are vector/primitive/dph so far.
>> * There is no buildbot or anything to cover it.
>>
>> You will need a very recent Clang. Due to this bug (preventing
>> primitive etc from building,) you'll preferably want to use an SVN
>> checkout from about 6 hours ago at latest:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>
>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>> module due to some CPP weirdness. But even with a proper bugfix and no
>> segfault, it still fails to correctly parse this same module with the
>> same CPP declarations. I'm fairly certain this is another bug in
>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>> it will *probably* work if we just get rid of the CPP tomfoolery in
>> primitive. I'll be testing it in the next few days to see if we can
>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>> doing this a week or two ago...)
>>
>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>> hope. It should be especially welcome for Mac users. (I'm also hoping
>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>> can go in soon...)
>>
>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>> macro, involving whitespace between the name and arguments (commit
>> d8ee2b.) Clang does not forgive you for this. Should I note this
>> anywhere for the future in the wiki or something?
>>
>> --
>> Regards,
>> Austin - PGP: 4096R/0x91384671
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,
Austin - PGP: 4096R/0x91384671


Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Isaac Dupree-3
Tom Stellard is leading an effort to make dot releases for LLVM 3.3 [*];
perhaps LLVM folks could be convinced to fix the issues in a 3.3.1 release.

-Isaac (just happens to be on both email lists and doesn't know anything
more than this)

[*] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063189.html


Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Carter Schonwald
Isaac, Austin and I have actually just been email introduced to Tom, so
excellent timing :)

Happily, we've got a direct contact with the apple folks working on llvm /
clang via  a friend of mine, and thus in turn Tom and some others. The most
important piece is making sure the Clang patches land in Xcode 5's version
of Clang (which is apple's variant that isn't strictly tied to a point
release), because thats going to be the only C compiler for OS X by default
very soon.

So in some respects, because BSD/Linux distros provide system package
managers by default, its easy for a user on those platforms to have a
suitable GCC installed, less so with vanilla OS X, so the most important
part is making sure that these patches land in the Clang that lives in
Xcode 5. If it lands in mainline clang point release too,  great!  (ghc not
being able to useable on macs without the end user needing to build their
own ghc or figure out installing and switching to an older xcode would be a
HUGE headache for the haskell community)

point being: exciting things! (and many many hearty thanks to Austin for
the work to make this move along)
-Carter




On Wed, Jun 26, 2013 at 12:47 AM, Isaac Dupree <
ml at isaac.cedarswampstudios.org> wrote:

> Tom Stellard is leading an effort to make dot releases for LLVM 3.3 [*];
> perhaps LLVM folks could be convinced to fix the issues in a 3.3.1 release.
>
> -Isaac (just happens to be on both email lists and doesn't know anything
> more than this)
>
> [*] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063189.html
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130626/75a604cb/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Manuel M T Chakravarty
In reply to this post by Austin Seipp-4
Austin Seipp <aseipp at pobox.com>:
> * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
> * I have a small, 6-line patch to Clang to fix the build failure in
> primitive (Clang was too eager to stringify something.) Once this fix
> is integrated into Clang (hopefully very soon,) it will be possible to
> build GHC entirely including all stage2 libraries without any patches.
> The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am
> hoping this will also make it into XCode 5.

Xcode 5 DP2's tools are still based on 3.3svn.

> As for the infamous ticket #7602, the large performance regression on
> Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS
> approach.
>
> ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  395.57s user
> 173.18s system 138% cpu 6:50.71 total
>
> vs
>
> ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  322.98s user
> 132.37s system 132% cpu 5:44.65 total
>
> Now, this probably looks totally awful from a scalability POV. And,
> well, yeah, it is. But I am almost 100% certain there is something
> extremely screwy going on with my machine here. I base this on the
> fact that during gc_bench, kernel_task was eating up about ~600% of my
> CPU consistently, giving user threads no time to run. I've noticed
> this with other applications that were totally unrelated too (close
> tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or
> turn it on and off again or something. Ugh.
>
> Anyway, if you look at the user times, you get a nice 30% speedup
> which is about what we expect!

I'm very glad to hear that!

Manuel



Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Carter Schonwald
Yes.  We have some direct contacts with the llvm apple dev team.  Austin
and or I will be following up with them soon.

On Wednesday, June 26, 2013, Manuel M T Chakravarty wrote:

> Austin Seipp <aseipp at pobox.com <javascript:;>>:
> > * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
> > * I have a small, 6-line patch to Clang to fix the build failure in
> > primitive (Clang was too eager to stringify something.) Once this fix
> > is integrated into Clang (hopefully very soon,) it will be possible to
> > build GHC entirely including all stage2 libraries without any patches.
> > The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am
> > hoping this will also make it into XCode 5.
>
> Xcode 5 DP2's tools are still based on 3.3svn.
>
> > As for the infamous ticket #7602, the large performance regression on
> > Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS
> > approach.
> >
> > ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  395.57s user
> > 173.18s system 138% cpu 6:50.71 total
> >
> > vs
> >
> > ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  322.98s user
> > 132.37s system 132% cpu 5:44.65 total
> >
> > Now, this probably looks totally awful from a scalability POV. And,
> > well, yeah, it is. But I am almost 100% certain there is something
> > extremely screwy going on with my machine here. I base this on the
> > fact that during gc_bench, kernel_task was eating up about ~600% of my
> > CPU consistently, giving user threads no time to run. I've noticed
> > this with other applications that were totally unrelated too (close
> > tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or
> > turn it on and off again or something. Ugh.
> >
> > Anyway, if you look at the user times, you get a nice 30% speedup
> > which is about what we expect!
>
> I'm very glad to hear that!
>
> Manuel
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130627/42d762bb/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Simon Marlow-7
In reply to this post by Austin Seipp-4
On 26/06/13 04:13, Austin Seipp wrote:

> Thanks Manuel!
>
> I have an update on this work (I am also CC'ing glasgow-haskell-users,
> as I forgot last time.) The TL;DR is this:
>
>   * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
>   * I have a small, 6-line patch to Clang to fix the build failure in
> primitive (Clang was too eager to stringify something.) Once this fix
> is integrated into Clang (hopefully very soon,) it will be possible to
> build GHC entirely including all stage2 libraries without any patches.
> The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am
> hoping this will also make it into XCode 5.
>   * I still have to eliminate some warnings throughout the build, which
> will require fiddling and a bit of refactoring. The testsuite still
> probably won't run cleanly on Linux, at least, until this is done I'm
> afraid (but then again I haven't tried...)
>
> As for the infamous ticket #7602, the large performance regression on
> Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS
> approach.
>
> ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  395.57s user
> 173.18s system 138% cpu 6:50.71 total
>
> vs
>
> ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  322.98s user
> 132.37s system 132% cpu 5:44.65 total
>
> Now, this probably looks totally awful from a scalability POV. And,
> well, yeah, it is. But I am almost 100% certain there is something
> extremely screwy going on with my machine here. I base this on the
> fact that during gc_bench, kernel_task was eating up about ~600% of my
> CPU consistently, giving user threads no time to run. I've noticed
> this with other applications that were totally unrelated too (close
> tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or
> turn it on and off again or something. Ugh.
>
> Anyway, if you look at the user times, you get a nice 30% speedup
> which is about what we expect!

30% better than before is good, but we need some absolute figures. Can
you validate that against the performance on Linux, or against the
performance you get when the RTS is compiled with gcc?  If it's hard to
get a direct comparison on equivalent hardware. you could compare the
slowdown with -threaded on Linux and OS X.

Cheers,
        Simon


> On a related note, due to the source code structure at the moment,
> Linux/Clang hilariously suffers from this same bug. That's because
> while Clang on Linux supports extremely fast TLS via __thread (like
> GCC,) it falls back to pthread_getspecific/setspecific. I haven't
> fixed this yet. It'll happen after I fix #7602 and get it merged in.
> On my Linux machine, gc_bench also sees a consistent 30% speedup
> between these two approaches, so I think this is a relatively accurate
> measurement. Well, as accurate as I can be without running nofib just
> yet. So if you're just dying to have GHC HEAD built with Clang HEAD on
> Linux because you've got reasons, you should probably hold on.
>
> I also may have a similar, better approach to fixing #7602 that is not
> entirely as evil and sneaky as crashing the WebKit party. I'll follow
> up on this soon when I have more info in a separate thread to confer
> with Simon. With nofib results. I hope.
>
> But anyway, 7.8 will be shaping up quite nicely - in particular in the
> Mac OS X department, I hope. Please feel free to pester me with
> questions or if you attempt something and it doesn't work.
>
> On Tue, Jun 25, 2013 at 7:34 PM, Manuel M T Chakravarty
> <chak at cse.unsw.edu.au> wrote:
>> Austin,
>>
>> Thank you very much for taking care of all these clang issues ? that is very helpful!
>>
>> Cheers,
>> Manuel
>>
>> Austin Seipp <aseipp at pobox.com>:
>>> Hi all,
>>>
>>> As of commit 5dc74f it should now be possible to build a working
>>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>>> caveats.
>>>
>>> You can just do:
>>>
>>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>>> $ make
>>>
>>> I have done this work on Linux. I don't expect much difficulty on Mac
>>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>>> is considered experimental.
>>>
>>> The current caveats are:
>>>
>>> * The testsuite will probably fail everywhere, because of some
>>> warnings that happen during the linking phase when you invoke the
>>> built compiler. So the testsuite runner will probably be unhappy.
>>> Clang is very noisy about unused options, unlike GCC. That needs to be
>>> fixed somewhere in DriverPipeline I'd guess, but with some
>>> refactoring.
>>> * Some of the stage2 libraries don't build due to a Clang bug. These
>>> are vector/primitive/dph so far.
>>> * There is no buildbot or anything to cover it.
>>>
>>> You will need a very recent Clang. Due to this bug (preventing
>>> primitive etc from building,) you'll preferably want to use an SVN
>>> checkout from about 6 hours ago at latest:
>>>
>>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>>
>>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>>> module due to some CPP weirdness. But even with a proper bugfix and no
>>> segfault, it still fails to correctly parse this same module with the
>>> same CPP declarations. I'm fairly certain this is another bug in
>>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>>> it will *probably* work if we just get rid of the CPP tomfoolery in
>>> primitive. I'll be testing it in the next few days to see if we can
>>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>>> doing this a week or two ago...)
>>>
>>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>>> hope. It should be especially welcome for Mac users. (I'm also hoping
>>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>>> can go in soon...)
>>>
>>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>>> macro, involving whitespace between the name and arguments (commit
>>> d8ee2b.) Clang does not forgive you for this. Should I note this
>>> anywhere for the future in the wiki or something?
>>>
>>> --
>>> Regards,
>>> Austin - PGP: 4096R/0x91384671
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Austin Seipp-4
Unfortunately the two machines are fairly wildly different in their
hardware characteristics. The OS X machine has 4GB of RAM; 8 Core i7.
The Linux machine has 16GB, but only a 4-core i5. And they have
different clock speeds.

I'll get GCC 4.8 on my OS X machine so I can force a build with it and
compare, but that'll take a while.

Also, as I said, the Linux/Clang build technically has this very same
bug too (GCTDecl.h needs to be modified slightly to fix this, because
it *always* falls back to pthread_getspecific/setspecific currently
with an LLVM based compiler. On Linux, we can just use __thread
instead.) There, compared to a Linux/GCC build the change is
approximately a ~30% difference on -threaded applications like
gc_bench. So the slowdown ratios *seem* relatively consistent.

Anyway, I'll get around to some full nofib runs today if possible, but
the OS X machine will be a little sluggish. I have to do some other
stuff today for this, anyway (like actually getting my second patch to
Clang accepted today, hopefully.)

Interested parties who'd like to see this change, as it stands, can
look at my diff here (it's the 'clang-fast-tls' branch on my GHC
fork): https://github.com/thoughtpolice/ghc/commit/88f0a0b047ff67b40eeb4de940aca16271661564.patch

On Fri, Jun 28, 2013 at 4:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 26/06/13 04:13, Austin Seipp wrote:
>>
>> Thanks Manuel!
>>
>> I have an update on this work (I am also CC'ing glasgow-haskell-users,
>> as I forgot last time.) The TL;DR is this:
>>
>>   * HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
>>   * I have a small, 6-line patch to Clang to fix the build failure in
>> primitive (Clang was too eager to stringify something.) Once this fix
>> is integrated into Clang (hopefully very soon,) it will be possible to
>> build GHC entirely including all stage2 libraries without any patches.
>> The patch is here: http://llvm.org/bugs/show_bug.cgi?id=16371 - I am
>> hoping this will also make it into XCode 5.
>>   * I still have to eliminate some warnings throughout the build, which
>> will require fiddling and a bit of refactoring. The testsuite still
>> probably won't run cleanly on Linux, at least, until this is done I'm
>> afraid (but then again I haven't tried...)
>>
>> As for the infamous ticket #7602, the large performance regression on
>> Mac OS X, I have some numbers finally between my fast-TLS and slow-TLS
>> approach.
>>
>> ./gc_bench.slow-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  395.57s user
>> 173.18s system 138% cpu 6:50.71 total
>>
>> vs
>>
>> ./gc_bench.fast-tls 19 500000 5 22 +RTS -H180m -N7 -RTS  322.98s user
>> 132.37s system 132% cpu 5:44.65 total
>>
>> Now, this probably looks totally awful from a scalability POV. And,
>> well, yeah, it is. But I am almost 100% certain there is something
>> extremely screwy going on with my machine here. I base this on the
>> fact that during gc_bench, kernel_task was eating up about ~600% of my
>> CPU consistently, giving user threads no time to run. I've noticed
>> this with other applications that were totally unrelated too (close
>> tweetbot -> 800% CPU usage,) so I guess it's time to learn DTrace. Or
>> turn it on and off again or something. Ugh.
>>
>> Anyway, if you look at the user times, you get a nice 30% speedup
>> which is about what we expect!
>
>
> 30% better than before is good, but we need some absolute figures. Can you
> validate that against the performance on Linux, or against the performance
> you get when the RTS is compiled with gcc?  If it's hard to get a direct
> comparison on equivalent hardware. you could compare the slowdown with
> -threaded on Linux and OS X.
>
> Cheers,
>         Simon
>
>
>
>> On a related note, due to the source code structure at the moment,
>> Linux/Clang hilariously suffers from this same bug. That's because
>> while Clang on Linux supports extremely fast TLS via __thread (like
>> GCC,) it falls back to pthread_getspecific/setspecific. I haven't
>> fixed this yet. It'll happen after I fix #7602 and get it merged in.
>> On my Linux machine, gc_bench also sees a consistent 30% speedup
>> between these two approaches, so I think this is a relatively accurate
>> measurement. Well, as accurate as I can be without running nofib just
>> yet. So if you're just dying to have GHC HEAD built with Clang HEAD on
>> Linux because you've got reasons, you should probably hold on.
>>
>> I also may have a similar, better approach to fixing #7602 that is not
>> entirely as evil and sneaky as crashing the WebKit party. I'll follow
>> up on this soon when I have more info in a separate thread to confer
>> with Simon. With nofib results. I hope.
>>
>> But anyway, 7.8 will be shaping up quite nicely - in particular in the
>> Mac OS X department, I hope. Please feel free to pester me with
>> questions or if you attempt something and it doesn't work.
>>
>> On Tue, Jun 25, 2013 at 7:34 PM, Manuel M T Chakravarty
>> <chak at cse.unsw.edu.au> wrote:
>>>
>>> Austin,
>>>
>>> Thank you very much for taking care of all these clang issues ? that is
>>> very helpful!
>>>
>>> Cheers,
>>> Manuel
>>>
>>> Austin Seipp <aseipp at pobox.com>:
>>>>
>>>> Hi all,
>>>>
>>>> As of commit 5dc74f it should now be possible to build a working
>>>> stage1 and stage2 compiler with (an extremely recent) Clang. With some
>>>> caveats.
>>>>
>>>> You can just do:
>>>>
>>>> $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang
>>>> $ make
>>>>
>>>> I have done this work on Linux. I don't expect much difficulty on Mac
>>>> OS X, but it needs testing. Ditto with Windows, although Clang/mingw
>>>> is considered experimental.
>>>>
>>>> The current caveats are:
>>>>
>>>> * The testsuite will probably fail everywhere, because of some
>>>> warnings that happen during the linking phase when you invoke the
>>>> built compiler. So the testsuite runner will probably be unhappy.
>>>> Clang is very noisy about unused options, unlike GCC. That needs to be
>>>> fixed somewhere in DriverPipeline I'd guess, but with some
>>>> refactoring.
>>>> * Some of the stage2 libraries don't build due to a Clang bug. These
>>>> are vector/primitive/dph so far.
>>>> * There is no buildbot or anything to cover it.
>>>>
>>>> You will need a very recent Clang. Due to this bug (preventing
>>>> primitive etc from building,) you'll preferably want to use an SVN
>>>> checkout from about 6 hours ago at latest:
>>>>
>>>> http://llvm.org/bugs/show_bug.cgi?id=16363
>>>>
>>>> Hilariously, this bug was tripped on primitive's Data.Primitive.Types
>>>> module due to some CPP weirdness. But even with a proper bugfix and no
>>>> segfault, it still fails to correctly parse this same module with the
>>>> same CPP declarations. I'm fairly certain this is another bug in
>>>> Clang, but I might be wrong. I'm trying to isolate it. Unfortunately
>>>> Clang/LLVM 3.3 was just released and it won't see bugfix releases. But
>>>> it will *probably* work if we just get rid of the CPP tomfoolery in
>>>> primitive. I'll be testing it in the next few days to see if we can
>>>> get 3.3 supported. (I'm sort of kicking myself in the head for not
>>>> doing this a week or two ago...)
>>>>
>>>> Anyway, there are some rough edges but it should be in shape for 7.8 I
>>>> hope. It should be especially welcome for Mac users. (I'm also hoping
>>>> modern Macs could even go all-clang-all-the-time if my fix for #7602
>>>> can go in soon...)
>>>>
>>>> PS. If you use ASSERT, I just fixed a lot of instances of using that
>>>> macro, involving whitespace between the name and arguments (commit
>>>> d8ee2b.) Clang does not forgive you for this. Should I note this
>>>> anywhere for the future in the wiki or something?
>>>>
>>>> --
>>>> Regards,
>>>> Austin - PGP: 4096R/0x91384671
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>>
>>
>



--
Regards,
Austin - PGP: 4096R/0x91384671


Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Ryan Newton
By the way, on the topic of these preformance comparisons -- has anyone
tried building the RTS with the Intel C compiler?  (They try very hard at
being a drop-in GHC replacement.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130701/b4fe06e5/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Ryan Newton
Err, GCC replacement.  But, ironically, GHC [backend] replacement as well,
as of the recent ICFP paper.



On Mon, Jul 1, 2013 at 12:03 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> By the way, on the topic of these preformance comparisons -- has anyone
> tried building the RTS with the Intel C compiler?  (They try very hard at
> being a drop-in GHC replacement.)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130701/6331102b/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Nicolas Trangez
On Mon, 2013-07-01 at 12:05 -0400, Ryan Newton wrote:
> Err, GCC replacement.  But, ironically, GHC [backend] replacement as well,
> as of the recent ICFP paper.

Got a link or reference?

Nicolas



Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Ryan Newton
Gosh, sorry, yes it's not obvious from the list of accepted papers:

"Automatic SIMD Vectorization for Haskell" Leaf Petersen, Dominic Orchard
and Neal Glew
One of the authors has a link for it but it appears there's no preprint up
yet:
    http://www.leafpetersen.com/leaf/publications.htm






On Tue, Jul 2, 2013 at 5:36 AM, Nicolas Trangez <nicolas at incubaid.com>wrote:

> On Mon, 2013-07-01 at 12:05 -0400, Ryan Newton wrote:
> > Err, GCC replacement.  But, ironically, GHC [backend] replacement as
> well,
> > as of the recent ICFP paper.
>
> Got a link or reference?
>
> Nicolas
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130702/51e20df7/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

PSA: GHC can now be built with Clang

Carter Schonwald
What branch is that work in? I've not seen mention of it in the commit
logs.  I'd really love to see how they're Doing it.

Likewise, it's worth remarking that a carefullywritten simd primop that
explicitly uses the instruction intrinsics can easily be 1.5-2x faster than
auto vectorized simd code.  I've some examples I tested for matrix
multiplication where the performance is robustly In that range.


On Tuesday, July 2, 2013, Ryan Newton wrote:

> Gosh, sorry, yes it's not obvious from the list of accepted papers:
>
> "Automatic SIMD Vectorization for Haskell" Leaf Petersen, Dominic Orchard
> and Neal Glew
> One of the authors has a link for it but it appears there's no preprint up
> yet:
>     http://www.leafpetersen.com/leaf/publications.htm
>
>
>
>
>
>
> On Tue, Jul 2, 2013 at 5:36 AM, Nicolas Trangez <nicolas at incubaid.com<javascript:_e({}, 'cvml', 'nicolas at incubaid.com');>
> > wrote:
>
>> On Mon, 2013-07-01 at 12:05 -0400, Ryan Newton wrote:
>> > Err, GCC replacement.  But, ironically, GHC [backend] replacement as
>> well,
>> > as of the recent ICFP paper.
>>
>> Got a link or reference?
>>
>> Nicolas
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org <javascript:_e({}, 'cvml', 'ghc-devs at haskell.org');>
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130702/fd9c6f0d/attachment.htm>