4 ms·

So GCC takes longer to compile but produces a better optimized binary? That makes the comparison pretty useless as you can probably just reduce the GCC optimiza

by rockdoe 13y ago

So GCC takes longer to compile but produces a better optimized binary? That makes the comparison pretty useless as you can probably just reduce the GCC optimization level.

matthewmacleod 13y ago
It produces a smaller binary, but that doesn't really give us any information on whether it's a better one. AFAIK Clang and GCC are now roughly neck-and-neck in terms of performance though (at least as of December) - http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers http://www.phoronix.com/scan.php?page=article&item=llvm34_gc...
- cottonseed 13y ago
  GCC produces a slightly smaller binary when debug information is stripped, but LLVM produces a massively smaller binary (half as big) when debug information is included. If you're building debug, why would you care how big the stripped binary is?
  - userbinator 13y ago
    This invites the question of whether GCC is outputting more detailed debugging information than LLVM (which is a good thing), or if it's just being inefficient at it.
    - cottonseed 13y ago
      The g++/gdb experience for C++ has always been pretty bad. Anyone know how lldb compares?
      - dmm 13y ago
        In what ways is it bad? It works pretty damn good here.
        celebril 13y ago
        It's bad because it's not as hip and cool as LLVM's offering.
        mitchty 13y ago
        No gdb is bad for c++ debugging because it doesn't include parsing support for c++. At least I'm not aware of being able to type in c/c++ in gdb on the fly like you can with lldb contexts. So what exactly is "hip and cool" about having your debugger actually use the same parsing engine as the compiler infrastructure? If you have a technical point make it, otherwise stop being the discussion equivalent of acid.
        cottonseed 13y ago
        Generally, failing to parse expressions at the level of abstraction of the source code being debugged: I find it fails on user defined operators, can't resolve overloaded functions, etc. Even being able to reliably evaluate C++ expressions is far from what I want: I want to be able to execute arbitrary C++ statements (including loops), use templated objects that weren't instantiated at compile time, etc. I feel like this might be close to possible using, say, the LLVM JIT, although I haven't seen anything that implies anyone is trying to build it. edit: for example (stock gcc/gdb on Ubuntu 12.04): #include <iostream> int main() { std::cout << "foo\n"; } in gdb, break at main: (gdb) p std::cout << "foo\n" Cannot resolve function operator<< to any overloaded instance edit edit: lldb doesn't fare much better (OSX 10.9): (lldb) p std::cout << "foo\n" error: no member named 'cout' in namespace 'std' error: 1 errors parsing expression
        emaste 13y ago
        LLDB does JIT your expression via Clang, and then either interprets it locally or executes it in the target, and you can execute arbitrary commands - for example: (lldb) expr for (int i=1; i<5; i++) { printf("%d\n", i * i); } 1 4 9 16 It does still fail if the appropriate constructors, templated object instantiations, etc. aren't in the target, as you point out.
x3ro 13y ago
In the comments there is a run with -O0 where GCC still takes almost 50% more time than clang. Is it okay to assume that unoptimizied binaries would be quite similar in terms of performance?

by rockdoe 13y ago

So GCC takes longer to compile but produces a better optimized binary? That makes the comparison pretty useless as you can probably just reduce the GCC optimization level.

matthewmacleod 13y ago

It produces a smaller binary, but that doesn't really give us any information on whether it's a better one. AFAIK Clang and GCC are now roughly neck-and-neck in terms of performance though (at least as of December) - http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers http://www.phoronix.com/scan.php?page=article&item=llvm34_gc...

cottonseed 13y ago
GCC produces a slightly smaller binary when debug information is stripped, but LLVM produces a massively smaller binary (half as big) when debug information is included. If you're building debug, why would you care how big the stripped binary is?
- userbinator 13y ago
  This invites the question of whether GCC is outputting more detailed debugging information than LLVM (which is a good thing), or if it's just being inefficient at it.
  - cottonseed 13y ago
    The g++/gdb experience for C++ has always been pretty bad. Anyone know how lldb compares?
    - dmm 13y ago
      In what ways is it bad? It works pretty damn good here.
      - celebril 13y ago
        It's bad because it's not as hip and cool as LLVM's offering.
        mitchty 13y ago
        No gdb is bad for c++ debugging because it doesn't include parsing support for c++. At least I'm not aware of being able to type in c/c++ in gdb on the fly like you can with lldb contexts. So what exactly is "hip and cool" about having your debugger actually use the same parsing engine as the compiler infrastructure? If you have a technical point make it, otherwise stop being the discussion equivalent of acid.
      - cottonseed 13y ago
        Generally, failing to parse expressions at the level of abstraction of the source code being debugged: I find it fails on user defined operators, can't resolve overloaded functions, etc. Even being able to reliably evaluate C++ expressions is far from what I want: I want to be able to execute arbitrary C++ statements (including loops), use templated objects that weren't instantiated at compile time, etc. I feel like this might be close to possible using, say, the LLVM JIT, although I haven't seen anything that implies anyone is trying to build it. edit: for example (stock gcc/gdb on Ubuntu 12.04): #include <iostream> int main() { std::cout << "foo\n"; } in gdb, break at main: (gdb) p std::cout << "foo\n" Cannot resolve function operator<< to any overloaded instance edit edit: lldb doesn't fare much better (OSX 10.9): (lldb) p std::cout << "foo\n" error: no member named 'cout' in namespace 'std' error: 1 errors parsing expression
        emaste 13y ago
        LLDB does JIT your expression via Clang, and then either interprets it locally or executes it in the target, and you can execute arbitrary commands - for example: (lldb) expr for (int i=1; i<5; i++) { printf("%d\n", i * i); } 1 4 9 16 It does still fail if the appropriate constructors, templated object instantiations, etc. aren't in the target, as you point out.

x3ro 13y ago

In the comments there is a run with -O0 where GCC still takes almost 50% more time than clang. Is it okay to assume that unoptimizied binaries would be quite similar in terms of performance?