If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

LLVM/Clang 3.3 Very Competitive To GCC 4.8

04-07-2013, 01:30 PM

Phoronix: LLVM/Clang 3.3 Very Competitive To GCC 4.8

Benchmarks for sharing this weekend are looking at the performance of GCC 4.7, GCC 4.8, LLVM/Clang 3.2, and the latest LLVM/Clang 3.3 development code. How does the performance of the newly released GCC 4.8.0 compare to the yet-to-be-released LLVM/Clang 3.3? It's interesting.

Comment

But as a future reference, Michael, there isn't much point in doing such tests on ffmpeg, since ffmpeg's critical code paths are mostly hand-tuned assembly. So it is no wonder that there is almost no difference there, and there never will be.

Comment

What's with the OpenMP tests thrown in? Wake me when both compiler suites are OpenMP ready.

It's vaguely relevant, especially if you use that software, and impacts your choice of compiler.

Show me some OpenCL tests.

Wouldn't be very interesting, since one compiler has OpenCL support when paired with another conpletely separate framework and the other has no OpenCL support at all. Might as well compare LibeeOffice with Notepad to see which makes the best wiki editor...

Comment

What's with the OpenMP tests thrown in? Wake me when both compiler suites are OpenMP ready.

Show me some OpenCL tests.

OpenMP tests are mostly there for comparison of "Gcc has the fast codepath and can do this. LLVM has the slow codepath...and can still put out THIS." Which is making me wonder if LLVM is gonna surpass GCC once OpenMP support is merged.

OpenCL is only usable with R600g (I think) on LLVM. GCC has no OpenCL support so you'd have LLVM giving you SOME results, and GCC sitting at 0.

Comment

For C-Ray GCC needed 20% less time, which is comparable tot he 28% increase of LLVM for Botan CAST-256.

Also GCC 4.8 delivered almost 19% more C/s for John the Ripper.

On the other hand, LLVM 3.3 really shines for Botan KASUMI (an increase of more than 60% is huge).

Wish: Tell me why.

What operations do the tests use? You have that for OpenMP, but not for the other tests.
Essentially the wish boils down to the question whether that improvement is relevant for my projects.

An example: Googling gave me this: KASUMI, the block cipher used in 3G telephony.
How are the chances, that LLVM is hand-optimized for that?

A second wish: Please mark the compilation time tests somehow. It?s really jarring to see a benchmark which looks like a huge difference, just to realize a few moments later that it is completely irrelevant for production code.