Comparing G++ and Intel Compilers and Vectorized Code

Nerval's Lobster writes "A compiler can take your C++ loops and create vectorized assembly code for you. It's obviously important that you RTFM and fully understand compiler options (especially since the defaults may not be what you want or think you're getting), but even then, do you trust that the compiler is generating the best code for you? Developer and editor Jeff Cogswell compares the g++ and Intel compilers when it comes to generating vectorized code, building off a previous test that examined the g++ compiler's vectorization abilities, and comes to some definite conclusions. 'The g++ compiler did well up against the Intel compiler,' he wrote. 'I was troubled by how different the generated assembly code was between the 4.7 and 4.8.1 compilers—not just with the vectorization but throughout the code.' Do you agree?"

Comments

Documentation is King

[jpschaaf]

For better or worse, I've always given the intel compiler the benefit of the doubt. They have access to documents that the GCC folks don't.

Re:Documentation is King

[Kookus]

The place I work has lots of documents generated about decisions made, why those decisions were made, etc...
They are really helpful documents that save a bunch of time... if only people would read them 6 months later when they should.

Nah, people seem to ask for documentation third. Google first, co-workers second. Only until they run into a co-worker that says RTFM do they get to the third option of reading it :)

Re:Documentation is King

[Curupira]

Yeah, on Intel processors. What about AMD and other x86 processors? Don't ever forget that ICC was once caught red-handed disabling important features when the CPUID did not return GenuineIntel...

Re:Documentation is King

[jmac_the_man]

Intel isn't providing the optimizations for free to their competitors.* Intel provides the compiler, along with all its optimizations, to its customers in exchange for payment.

*Except the academic, evaluation and Linux-only non-commercial use versions, which could theoretically be downloaded by AMD employees, I guess.

Re:Documentation is King

[Runaway1956]

Yep, they have access to some cool documents. It took a lot of work to document the fact that the intel compiler was actually crippling code if it was run on AMD processors. I mean, some suspicious, somewhat paranoid people suspected that intel was crippling code on AMD processors, but it took a good deal of work to actually demonstrate it.

That is just one of the many reasons I don't use Intel.

Re:Documentation is King

[Darinbob]

GCC also works with many CPUs that Intel compiler does not. That includes x86 compatible chips from other vendors, as well as the advanced features in Intel chips that were originally introduced by competiting clones. So maybe Intel is nice, but that's irrelevant if you don't even use Intel hardware in your products.

If Intel really is basing their compiler off of secret architecture documents, then people should be able to deduce what's going on from looking at the generated assembler. Ie, find some goofy generated code that does not seem to make sense given public documents, get a benchmark to compare it, figure out there's a hidden feature, and then make use of it.

Re:Documentation is King

[Anonymous Coward]

If the CPU reports it supports SSE2, and the compiler supports it, I expect it to bloody well use those instructions when told to, not silently produce fucking x87 garbage. Really rocket science apparently.

Re:Documentation is King

[Cammi]

I worked in a place where my whole position was documented over a span of 5 years, PRIOR to me started. It was literally a small binder with the steps to do, with simple If, Then type sequences. Then, beside that binder, was a HUGE fricken binder with all of the "edge cases". That documentation saved my arse plenty of times. Documentation IS King

Not sure why it's troubling.

[serviscope_minor]

I don't think it's troubling.

Firstly they beat on the optimizer a *lot* between major versions.

Secondly, the compiler does a lot of micro optimizations (e.g. the peephole optimizer) to choose between essentially equivalent snippets. If they change the information about the scheduling and other resources you'd expect that to change a lot.

Plus I think that quite a few intresting problems such as block ordering are NP-hard. If they change the parameters of their heuristic NP-hard solver, that will give very different outputs too.

So no, not that bothered, myself.

Re:Not sure why it's troubling.

[david.emery]

Mod parent up +1 insightful.

Unless you suspect and are trying to debug a code generator error (one of the least pleasant/most difficult debugging experiences I've had), the base assertion that you should understand your compiler's code generation is at best unrealistic, and probably just dumb. Code generation is extremely complex, requiring deep knowledge of both this specific compiler's design and this specific computer's instruction set architecture, how the caches work, pre-fetching approaches, timing dependencies in instruction pipelines, etc, etc. If you do suspect a code generator error, you're best off hiring a compiler expert at least as a consultant, and be prepared for a long hard slog.

Maybe 30 years ago, for a PDP-8, you could assert that the C code you wrote had some semblance to the generated machine code. That hasn't been true for a very long time, and C++ is most definitely not C in this regard.

Re:Not sure why it's troubling.

[zubab13]

Just use something like libsimdpp[1] and you are sure that your code stays vectorized between compiler versions. As a bonus, this and similar wrapper libraries give you an option to produce assembly for multiple instruction sets (say SSE2, AVX and NEON) from the same code. [1]: https://github.com/p12tic/libsimdpp

Re:Not sure why it's troubling.

[loufoque]

Explicit vectorization is indeed much more reliable than automatic vectorization, and it will always deliver better performance.

Interestingly, there seems to be quite a few abstraction layer libraries for SIMD. There are also at least Boost.SIMD (part of NT2 [1]) and Vc [2].
Several array-handling libraries (NT2 [1], Eigen [3]) also a leverage SIMD explicitly.
Alternatively there are plenty of languages based on C with explicit SIMD programming, like the Intel SPMD Compiler [4].

If you're interested in SIMD, there is also apparently a workshop being held soon on this subject in Orlando [5].

[1] https://github.com/MetaScale/nt2
[2] http://code.compeng.uni-frankfurt.de/projects/vc/
[3] http://eigen.tuxfamily.org/index.php?title=Main_Page
[4] http://ispc.github.io/
[5] https://sites.google.com/site/wpmvp2014/

Very different code

[Anonymous Coward]

I have worked on a couple of projects that compiled and ran perfectly with GCC 4.6 and 4.7. They no longer run when compiled with the latest versions of GCC. No warnings, no errors during compilation, they simply crash when run. It's the same source code, so something has changed. The same code, when compiled with multiple versions of Clang, runs perfectly. The GCC developers are doing something different and it is causing problems. Now it may be that a very well hidden bug is lurking in the code and the latest GCC is exposing that in some way, but this code worked perfectly for years under older versions of the compiler so it's been a nasty surprise.

Re:Very different code

[david.emery]

Unfortunately, that's not unique to GCC. I've seen this happen with several different compliers for different programming languages over the years. Worse, I've seen it with the same compiler, but different Optimizer settings.

In one case, our system didn't work (segfaulted) with the optimizer engaged, and didn't meet timing requirements without the optimizer. And the problem wasn't in our code, it was in a commercial product we bought. The compiler vendor, the commercial product vendor (and the developer of that product, not the same company as we bought it from) and our own people spent a year pointing fingers at each other. No one wanted to (a) release source code and then (b) spend the time stepping through things at the instruction level to figure out what was going on.

And the lesson I learned from this: Any commercial product for which you don't have access to source code is an integration and performance risk.

Re:Very different code

[Gothmolly]

And trying to do it all yourself is a risk of never getting to market.

Re:Very different code

[Mr Z]

Actually, the scope of int i changed in C++. Previously, the scope would extend beyond the for. If you enable warnings, G++ will tell you all about it.

Re:Very different code

[david.emery]

Well, in part that depends on your market. Most of my work has been in military systems or air traffic systems, where the cost of failure >> lost opportunity cost. That's a point a lot of people forget; not all markets (and therefore the risk calculations for bugs, etc) are created equal.

Re:Very different code

[drawfour]

This is why all code should be compiled with highest warning level enabled, and all warnings should be treated as errors. The compiler can have a very hard time guessing at what you meant, so it's best to be as explicit as you can. If, for some reason, you're positive the code needs to be a certain way that is, and it is correct, you can always use a "pragma warning(disable)" (with appropriate push/pop semantics) to keep your code compiling clean.

Re:Very different code

[PhrostyMcByte]

Your projects were likely doing something which resulted in undefined behavior. It's been extremely rare to have GCC break working standards-compliant code.

Re:Very different code

[drawfour]

There is a reason for warnings -- it's because you're doing something wrong. Unfortunately, the compiler lets you do it anyway, probably because there is a ton of legacy code that would suddenly "break" if they were errors by default. But that doesn't mean that you should stop trying to fix these issues. Many of these issues only appear to be benign until you stumble upon the exact issue the warning was trying to warn you about. Static code analysis tools are also your friend. That doesn't mean you can blindly trust them -- static analysis tools do have false warnings. But they're way better than inspecting the code yourself. You'll miss something way more times than the analysis tools will give you a false positive.

Re:Very different code

[0123456]

There is a reason for warnings -- it's because you're doing something wrong.

Uh, no. It's because you're doing something that may be wrong. If it was wrong, the compiler would given an error, not a warning.

'if ( a = b )' for example. The compiler warns because you probably meant 'if ( a == b )'. But maybe you didn't.

There's little reason to write such C code on a modern quad-core 3GHz CPU which spends 90% of its time idle and where the compiler will probably generate the same machine code anyway, but that doesn't make it wrong.

Re:Very different code

[DickBreath]

> And trying to do it all yourself is a risk of never getting to market.

You don't have to maintain the compiler yourself. You just need to have source code to it, and a compiler that compiles it, for the life of your project. That way, if a newer version of the compiler breaks your project, as the original poster complained of, you always have a working compiler for the life of your project. Your compiler may not get any additional improvements. But having it work vs not work is much more important than incremental improvements.

Re:Very different code

[Immerman]

Easy 99% solution - treat all compiler warnings as errors. A warning means the compiler is having to guess at the proper interpretation of your code because you didn't make it completely unambiguous in the grammar of the language. A different compiler (or version) can thus be reasonably expected to guess differently, changing the behavior of your code.

Re:Very different code

[Mr Z]

Right, but would your server utilization go from 80% to 90% if you wrote it as two lines?

a = b;
if (a) {
// yadda
}

Unless you have an incredibly crappy compiler, the two will generate identical code, but this second version won't give a warning.

Re:Very different code

[Darinbob]

Sometimes warnings are false positives as well. Especially when turning warning levels up high they will warn about things that may be indicators of a bug or typo but which actually aren't problems, or in some cases are even intentional. Such as unused variables or parameters; is that a bug or a stylistic choice to not litter the code with extra #ifdef? An unused parameter in general seems an odd thing to complain about, usually the parameter list is fixed in an API or design document whether or not the actual implementation needs all the parameters.

Re:Very different code

[drawfour]

No. Just because something is legal according to the specification does not make it "right". The specification _should_ be restricted, but it cannot because there are a _lot_ of lines of code out there that would suddenly stop compiling. It _IS_ wrong to do 'if (a = b)' for a few reasons:

1. Someone else won't necessarily know that this was intended unless you have a comment telling them. That comment would take up just as much space as putting an 'a = b;' line before the 'if (a)' line.
2. If your compiler is not capable of optimizing and figuring out that 'if (a=b)' and 'a=b; if (a)' should generate the same machine code, then your compiler is a piece of crap and should be upgraded or replaced.
3. If you get in the habit of doing those kind of 'shortcuts', you are more likely to accidentally do the wrong thing. And since you're so used to that kind of programming, you're more likely to miss it when trying to track down the bug that you introduced. If 'if (a = b)' just looks wrong to you because you never use it, it is more likely to jump out at you when you're debugging, whether it's your own code or someone else's.

The same thing is true for casting ints to pointers, having fall-throughs in switch statements, signed/unsigned mismatches, and a myriad of other "legal" but "just-as-wrong" things.

Re:Very different code

[Immerman]

Quite true about C++. I've used it to good effect in conjunction with "active" objects whose creation and destruction can encapsulate much of their functionality - things like thread locks, at the simple end.

Re:Very different code

[loufoque]

Most likely, you were just invoking undefined behaviour.
GCC 4.8 has new optimizations tied to signed integer overflow, for example. a+b is the same in hardware regardless of whether the inputs are signed or not (assuming two's complement hardware), but to the compiler, that's not the case.

Once I just changed just one line

[deodiaus2]

And got completely different results!

News for nerds or not

[symbolset]

Asking any audience larger than about 20 to compare the qualitative differences of object code vectorization is statistically problematic as the survey group is larger than the qualified population.

Re:News for nerds or not

[Mr Z]

Also notably absent were any performance benchmarks. Two pieces of code might look very different but perform identically, while two others that look very similar could have very different performance. In any case, you should be able to work back to an achieved FLOPS number, for example, to understand quantitatively what the compiler achieved. You might have the most vectorific code in existence, but if it's a cache pig, it'll perform like a Ferrari stuck in mud.

Re:News for nerds or not

[jbcksfrt]

Boo this man!!! :-) I was happy to see something that only nerds would care about on Slashdot, rather than politics and BS about Bitcoin.

Vectorized factorials!

[Mr Z]

One amusing thing I discovered is that GCC 4.8.0 will actually unroll and vectorize this simple factorial function: Just look at that output!

Re:Vectorized factorials!

[DickBreath]

Here is how I do a factorial function. No recursion, no loops, no vectorization needed. It's in Java. Converting this basic idea to C is left as an exercise for advanced readers.

        static public long factorial( int n ) {
                switch( n ) {
                        case 0:
                        case 1: return 1L;
                        case 2: return 2L;
                        case 3: return 6L;
. . . cases 4 to 18 omitted to bypass slashdot filters . . .
                        case 19: return 121645100408832000L;
                        case 20: return 2432902008176640000L;
                }
                return 0L;
        }

Re:Vectorized factorials!

[Mr Z]

Why isn't that just a lookup table? My point in mentioning factorial is that there's no point in vectorizing that thing. Even a simple loop would be small compared to the cost of a single L2 cache miss.

Why is this still a topic?

[excelsior_gr]

This is 2013 (almost 2014!) why are we talking about vectorization? Why don't people write code in vector notation in the first place anyway? If Matlab and Fortran could implement this 25 years ago, I am sure we are ready to move on now...

Trust but verify

[QuietLagoon]

...do you trust that the compiler is generating the best code for you?,,,

Trust, but verify.

.
I come from the days when it was the programmer, not the compiler, that optimized the code. So nowadays, I let the compiler do its thing, but I do a lot of double-checking of the generated code.

Re:yuo Fai7 It

[LordByronStyrofoam]

OMG! What's this goatse doing here?? I thought all these images were taken down by a DMCA notice by the original asshole!

Mantle?

[Anonymous Coward]

Mantle is a good idea insofar as it should kick Microsoft and/or NVIDIA up the behind. We desperately need someone to cure us of the pain that is OpenGL and the lack of cross platform compatibility that is Direct 3D.

Obviously NVIDIA won't play ball with Mantle but I've got a feeling they might have to eventually given that some AAA games developers are going code a path for it. When it starts showing up how piss-poor our current high level layers are compared to what the metal can do, they'll have no choice.

Re:Machine code you fucking witless poser!

[VortexCortex]

I write code in Machine Code with a bootable hex editor (446 bytes, fits in a HDD boot sector). It's the easiest way to bootstrap an OS from scratch now that MoBos don't have boot from serial port anymore...
Here, run it in a VM: "qemu-system-i386 hexboot.img ", if you want.
Or, "dd if=hexboot.img of=/dev/sda bs=1 count=446 conv=notrunc", if you want to preserve the partition table on a bootable drive.
Arrows,PgUp,PgDn,Home,End = navigate; Tab = ASCII/Hex, Esc = jump to segment under cursor, F8 = Run code at the cursor. (this is a real-mode version)
When it boots you'll be looking at the code that booted, there's only two variables that didn't fit into the registers, you can see them changing at the bottom of the code as you stroll around.

That's all you need to create an OS, complier, etc. from scratch. You'll probably destroy your system though if you're not careful, so keep in in the VM if you're a noob; Lock-up is a mild danger, but corrupting the CMOS, etc. can leave your system bricked. You can replace the BIOS too if you know what you're doing. Maybe some day I'll publish a path to go from zero to OS while avoiding the Ken Thompson Compiler Hack... Folks are only just beginning to get interested in having actual system security, so maybe we'll lick the problem some other way. There's still chip microcode to worry about, but programmable hardware may allow us to route that exploit vector out too some day.

Screw your bullshit optimized compiler crap. It's stupid and far slower than you think, esp. since the binaries are bigger (1 cache miss and I've already beaten you in most cases). Besides, Next year or so the system will run twice as fast. My need for speed is tempered by my greater need for security and readable machine code. If I identify a patch of code that needs to be optimized or vectorized, I can do it myself.

Premature optimization is the root of all evil.
- Donald Knuth

I don't care about my lawn, it's just there to keep the dirt intact.

Re:Machine code you fucking witless poser!

[bws111]

Hey genius, try removing the 'as' command and then run gcc. Let us know how well the compiler works without an assembler.

When the manual is tl;dr

[tepples]

When documentation runs to hundreds or thousands of pages, it's hard to read it from cover to cover and reread it when each new version comes out.