I thought clang was slower than gcc because clang doesn't support thread local variables (in some form we need) and therefore GC performance suffered a lot on clang.


On Sat, Jul 12, 2014 at 9:27 PM, Mark Lentczner <mark.lentczner@gmail.com> wrote:
In building the OS X bindist for 7.8.3, I had to choose which of several ways to build it. In particular, I could build it with a newere Xcode, which uses clang, or an older Xcode which uses gcc. I decided to nofib benchmark the variations and see before I released. Here is what I found...

I compared two candidate builds:
  • x86_64 architecture
  • targeted at OS X 10.7 and later
  • one built with Xcode 5.1 on 10.9, which uses clang
  • one built with Xcode 4.5 on 10.8, which uses gcc
I installed both bindists, side-by-side on the same machine: a 10.9 machine, with Xcode 5.1, which uses clang. The machine is a MacMini, 2.5GHz Intel Core i5 (dual core, reports as 4 cpus).

Summary:
  • clang build was always faster
    • non-threaded was -3.2% run-time
    • threaded was -7.3% run-time
  • clang's improvement in GC run-time was better than -10%
  • clang builds were significantly bigger
You can find the details here:
The only concern is that the binary sizes were significantly bigger: +230% - I haven't investigated more, but I'm wondering if nofib doesn't strip the binaries before measuring, and perhaps clang's debugging info is much greater?

Next up... we are evaluating a bindist built with the HPC Mac OS X gcc compiler (based on gcc 4.9)... and preliminary results are looking even better! Stay tuned...

- Mark


_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs