[gambit-list] Gambit Clang C/C++ status and compiler benchmarks?

Adam adam.mlmb at gmail.com
Sun May 6 10:08:10 EDT 2018


Hi Marc,

2018-05-06 19:49 GMT+08:00 Marc Feeley <feeley at iro.umontreal.ca>:

> As I said my efforts to “fix” clang have not been very fruitful.  The
> issue 10739380 is on the Apple internal issue system.
>

Aha. I can't find that anywhere. I guess the "llvm-dev" mailing list is the
right place.


> Please note also that Gambit was designed to allow mixing code compiled by
> different C compilers.  So you can compile the runtime system using clang
> and your application using gcc, or the other way around.


Right.

What causes this lower speed should likely boil down to that the way Gambit
implements trampolines and its whole single host / calling convention model
in C, that for some reason LLVM fails to make those exact logics fast.

I deduce that reasoning from the general observation that GCC and LLVM
these days generally are in about the same performance ballpark, if the
reports I read were correct - my thought then is that LLVM cannot possibly
compile all of Gambit's runtime slower than GCC, as those parts of Gambit
are fairly similar in nature to other C applications [and so what LLVM
would need to optimize should be Gambit's trampolines/single host/calling
conventions that LLVM].

Do you think that line of reasoning would make sense?

In this case the understanding would be that it's the application logic in
the user-compiled Scheme modules that need to be optimized. So just some
simple Scheme program, that maybe even doesn't invoke the runtime at all
but maybe is implemented as two modules as to trig the trampolines a lot,
should be representative as C code that LLVM is slow at now and would need
to speed up to make Clang attractive for Gambit.


> There may be issues on some systems, particularly if the FFI or C++ is
> used.


Right.


> I’ve used this on macOS, in fact the Gambit prebuilt installer is built
> with GNU gcc and gsc will work on the user’s machine even if only Xcode is
> installed there.
>

Ok!

Yes I understand as long as all is C only, they interoperate well. Clang
has had as implementation goal to be as compatible with GCC as possible on
all levels relevant to users.

Adam

> On May 5, 2018, at 10:31 PM, Adam <adam.mlmb at gmail.com> wrote:
> >
> > Hi Marc,
> >
> > First thanks for responding.
> >
> > Yes GCC gives good performance however (my best understanding to date)
> is that GCC- and Clang-compiled C++ shared libraries and other object code,
> will not cooperate - libstdc++ (=GCC) and libc++ + libc++abi (=
> >
> > This means that if you're on a Clang-compiled operating system, C++
> packaged shared libraries will/may need to be recompiled to work with
> Gambit.
> >
> >
> > I agree that GCC overall is fast, generally adequate, and has excellent
> architecture support, and also Gambit compiles well on many other C/C++
> compilers such as MSVC, right, so I agree that this sorts as a rather
> peripheral issue.
> >
> > It should be in LLVM's self-interest to compile Gambit code fast though.
> >
> >
> > I can't find 10739380 on https://bugs.llvm.org/ , do you remember the
> URL where you submitted it?
> >
> > Maybe the C preprocessor output of a Gambit program that illustrates the
> problem would be instructive for the LLVM devs.
> >
> >
> > Thanks!
> > Adam
> >
> >
> >
> > 2018-05-06 10:16 GMT+08:00 Marc Feeley <feeley at iro.umontreal.ca>:
> > I haven't experimented with clang very much.  The performance gap with
> gcc is so wide that it seems like a very long shot to get it to perform at
> least as well as gcc on Gambit.  gcc gives adequate performance so why look
> for better?  As Voltaire said, “better is the enemy of good”.
> >
> > I brought this performance issue up with the Apple LLVM team 3 years
> ago.  At the time it was logged as rdar://problem/10739380 on their
> internal bug tracking system.  I have poked them from time to time to see
> if there is any progress, and at this point I’ve lost interest in seeing a
> resolution.  It is not on any critical path of mine.
> >
> > If someone has the interest and time to followup with the developpers,
> be my guest.
> >
> > Marc
> >
> >
> >
> > > On May 5, 2018, at 1:06 PM, Adam <adam.mlmb at gmail.com> wrote:
> > >
> > > Hi Marc,
> > >
> > > Wow, Clang is immensely slow indeed.
> > >
> > > Do you have any idea if Clang's low performance could be circumvented
> using Clang optimizer configuration, or, do you have any idea about
> qualities in Clang's design that destine it to produce slow code for Gambit?
> > >
> > > Maybe there could be a conversation with Clang to ask them to have a
> look at why their compiler is performing so bad, maybe they would be
> interested in speeding up things, I think overall they do have an ambition
> for high performance.
> > >
> > > Clang has become the bundled system-default C/C++/Objective C compiler
> for a handful OS:es now, so there is a growing incentive to use it. All the
> OS-bundled and packaged libraries on those platforms are Clang-compiled,
> and mixing Clang- and GCC-compiled code (e.g. shared libraries) in one
> executable, is not a very smooth experience today at least in my very
> limited experience.
> > >
> > > Would you be interested in crossposting an email to Clang's developer
> mailing list (llvm-dev and maybe cfe-dev, http://lists.llvm.org/mailman/
> listinfo) where you address Clang's performance problem and suggest any
> reasons you see as plausible for why they are so much after?
> > >
> > > Adam
> > >
> > >
> > > 2018-05-05 20:17 GMT+08:00 Marc Feeley <feeley at iro.umontreal.ca>:
> > > GCC is still the best choice when compiling Gambit.
> > >
> > > When configured with the usual
> > >
> > >   ./configure --enable-single-host
> > >
> > > the build time of a “make -j8” on my 4 core laptop is over 10x slower
> when using CLANG.  As for speed of the generated code, CLANG produces code
> that is about 3x slower than GCC.
> > >
> > > Here are the raw results, in seconds:
> > >
> > >                     make -j8     test4
> > >  GCC 8.1.0           39.566      1.167
> > >  CLANG 802.0.38     426.371      4.229
> > >
> > > When configured with
> > >
> > >   ./configure --enable-single-host --enable-c-opt
> > >
> > > which uses -O2 rather than the default -O1, the results are also
> favourable for GCC.  However the build times are closer and, interestingly,
> both compilers generate slightly slower code with -O2:
> > >
> > >                     make -j8     test4
> > >  GCC 8.1.0          193.560      1.218
> > >  CLANG 802.0.38     229.945      4.410
> > >
> > > Marc
> > >
> > >
> > >
> > > > On May 5, 2018, at 5:54 AM, Adam <adam.mlmb at gmail.com> wrote:
> > > >
> > > > Hi list,
> > > >
> > > > So I think I figured out the answer myself.
> > > >
> > > > First, the previous benchmark that I recalled having read, is the
> "8) Performance of GCC and CLANG when compiling Gambit" section in Gambit's
> install.txt file (https://github.com/gambit/gambit/blob/
> edac3c75f0d93f4f56a39c2b90621511f096dd72/INSTALL.txt#L577).
> > > >
> > > > The essence here is that Clang 2.6, 2.7 and 2.8 wouldn't even
> compile Gambit, and 2.9-3.1 would compile Gambit but be fairly slow.
> > > >
> > > > A lot has happened since Clang 3.1, which is the last Clang version
> covered by install.txt today. The latest version today is 6.0. Ref.
> https://en.wikipedia.org/wiki/Clang#Status_history . Clang is now the
> default C/C++/Objective-C compiler choice in a handful operating systems,
> for AMD64 and some more architectures.
> > > >
> > > > Clang's language feature set is good, ref.
> https://en.cppreference.com/w/cpp/compiler_support ,
> https://clang.llvm.org/cxx_status.html .
> > > >
> > > > And Clang's speed is decent, recent benchmarks tend to find that
> Clang and GCC have a speed difference that's in the ballpark +-30%, up or
> down depending on benchmark, e.g. ref. https://stackoverflow.com/
> questions/3187414/clang-vs-gcc-which-produces-better-binaries#15043814 .
> > > >
> > > > The term "LLVM" only denotes that Clang has an internal intermediary
> language form, and the term LLVM has no other meaning in the direction of
> executable bytecode like Java JIT VM:s. I.e. Clang is only a native
> C/C++/Obj-C compiler. A list of the Clang/LLVM projects is on the main page
> at http://www.llvm.org/ .
> > > >
> > > > I have not tested yet but I do expect Clang to run Gambit stably and
> at a totally-okay speed.
> > > >
> > > > Adam
> > > >
> > > > 2018-05-05 16:13 GMT+08:00 Adam <adam.mlmb at gmail.com>:
> > > > Hi!
> > > >
> > > > Does Gambit work perfectly with the Clang C/C++ compiler (compiling
> to assembly which is compiled to native code, nothing LLVM), if so is it
> for all Gambit versions, or since when?
> > > >
> > > > I remember a benchmark of the time taken to, was it to compile
> Gambit-generated C code, or was it execution time of Gambit-C code as
> compiled by different GCC and Clang versions. What is the URL to that post
> in the mailing list archive?
> > > >
> > > > Thanks!
> > > > Adam
> > > >
> > > > _______________________________________________
> > > > Gambit-list mailing list
> > > > Gambit-list at iro.umontreal.ca
> > > > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20180506/764b5e88/attachment.htm>


More information about the Gambit-list mailing list