"gold standard"? [LWN.net]

"gold standard"?

Posted Apr 26, 2012 21:40 UTC (Thu) by daglwn (guest, #65432)
In reply to: "gold standard"? by robert_s
Parent article: LFCS 2012: LLVM and Linux

> Believe me, there are plenty of much slower compilers.

Yes there are but I believe the statement is true if one considers "regularly used" compilers. gcc's generated code is notoriously slow. Still, it will always win on some codes simply because no one compiler can completely dominate every other.

gcc's great strength is in its portability and cross-compile capabilities, which no other compiler can touch and won't any time soon.

> As for hardware vendors' compilers, it would be pretty embarrassing for
> them (not to mention pointless) if they _couldn't_ outperform
> competitors on their own hardware.

They will not outperform competitors on every possible code. I know of compilers that handily beat icc for x86 on some codes but also get trounced by icc on other codes. And it is not terribly difficult to examine the generated code of a compiler and figure out a bit of what it's doing to get performance. Reproducing it is sometimes tricky but in most cases it isn't. The techniques are known. The devil's in the tuning.

The problem is mostly one of time and compiler developer resources. By focusing/specializing on a key set of codes or operating arenas (embedded, HPC, etc.) a compiler team can create something that will beat a vendor compiler on those codes or in that particular arena.

to post comments

"gold standard"?

Posted Apr 26, 2012 22:57 UTC (Thu) by stevenb (guest, #11536) [Link] (2 responses)

"gcc's generated code is notoriously slow."

There are plenty benchmarks and user stories that say otherwise. IMHO there is a perception problem that is being perpetuated because complaints about GCC (or any other compiler) are always shouted out louder than compliments. And saying anything positive about GCC seems to be salon unfaehig anyway in many Linux discussion forums (especially LKML)...

"gold standard"?

Posted Apr 27, 2012 1:07 UTC (Fri) by daglwn (guest, #65432) [Link] (1 responses)

As I said, one can show gcc generating faster executables than other compilers on some codes. This will always be so. But the gcc team does not focus on performance exclusively, nor should it.

For all-out performance over a wide range of codes, it's hard to beat compilers that focus on it, such as icc, pathscale and pgi.

"gold standard"?

Posted Apr 29, 2012 8:24 UTC (Sun) by ebiederm (subscriber, #35028) [Link]

A lot depends on what you mean by performance.

Compiling your kernel of numerical code fast is one thing, and there are certainly compilers that specialize in that and all kinds of cpu architecture extensions to take advantage of it.

Where I have seen gcc excel is in making the work-a-day integer code lean and tight and cache friendly.

Most codes are integer codes and we need good work-a-day compilers not the hotrod numerical code wonders that are fast when the compiler does not ICE or generate incorrect code.

With luck clang can catch up to gcc and be a good work-a-day compiler but it seems clear that clang is not there yet.