×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comparing G++ and Intel Compilers and Vectorized Code

timothy posted about 3 months ago | from the different-lenses dept.

Intel 225

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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

225 comments

I Agree! (-1, Redundant)

Anonymous Coward | about 3 months ago | (#45736677)

I agree, as he said, he was troubled by it.

Me, I wasn't troubled by it.

Re:I Agree! (-1)

Anonymous Coward | about 3 months ago | (#45736879)

Meh, these are just tools used by people who are too lazy to write their own optimized assembly code. If you're going to be that lazy, you just don't have any standing to complain about the results. Just watch this [youtube.com]

Re:I Agree! (0)

Anonymous Coward | about 3 months ago | (#45736915)

that is a weird-ass troll (the link is a video of chiptune synthesized pop stars)

Documentation is King (3, Interesting)

jpschaaf (313847) | about 3 months ago | (#45736695)

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 (2)

Kookus (653170) | about 3 months ago | (#45736863)

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 (0)

Anonymous Coward | about 3 months ago | (#45738861)

That is interesting observation. I used to read documentation but in modern day practice nobody is writing any or they update some in such a way or at the time I do not need it anymore and I am not talking about some small two weeks 3 developers projects where that is not an issue.

Re:Documentation is King (5, Informative)

Curupira (1899458) | about 3 months ago | (#45737089)

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 [arstechnica.com] when the CPUID did not return GenuineIntel...

Re:Documentation is King (1)

Anonymous Coward | about 3 months ago | (#45737301)

Yeah, because Intel should be forced to provide free optimizations for their competitors. Wait, whuh?

Re:Documentation is King (2, Informative)

jmac_the_man (1612215) | about 3 months ago | (#45737463)

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 (1)

gl4ss (559668) | about 3 months ago | (#45738047)

well they sort of should be forced to not provide intentionally shitty product to their customers, no?

I got no qualms about them doing that if they put it in big red letters on the packaging and installer and on the page where you buy/get the compiler ....

Re:Documentation is King (1)

Darinbob (1142669) | about 3 months ago | (#45738993)

And certainly customers are allowed to scream about it all they like if they feel cheated. That behavior is also very clearly an anti-competitive act.

Re:Documentation is King (1, Flamebait)

CajunArson (465943) | about 3 months ago | (#45737397)

I'm sorry, you lost the right to put on the whole "Oh poor little AMD is being abused by the big bad monopolist!" the day that AMD came out with Mantle and started leveraging it's 100% monopoly in the console market in a much much worse way than Intel ever did with its 70 - 80% "monopoly" in the desktop market.

Nope (0)

Anonymous Coward | about 3 months ago | (#45737645)

While I really want to believe that AMD is taking a huge leap with the ubiquitous console chipping, it's still a little too early to declare it a success.

Re:Documentation is King (1)

Immerman (2627577) | about 3 months ago | (#45738189)

Who is talking about AMD? We're talking about Intel's surreptitiously anti-competitive behavior as it applies to trusting the efficacy of their compiler - the target of that behavior is irrelevant to the conversation.

Mantle? (2, Insightful)

Anonymous Coward | about 3 months ago | (#45738263)

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:Documentation is King (4, Interesting)

Runaway1956 (1322357) | about 3 months ago | (#45737941)

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 (3, Insightful)

Darinbob (1142669) | about 3 months ago | (#45738735)

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.

Assembler? (-1)

Anonymous Coward | about 3 months ago | (#45738877)

Are you some kind of faggot? Does the intel compiler generate an assembler?

No, I think you were referring to "assembly code." Asshole.

Not sure why it's troubling. (5, Insightful)

serviscope_minor (664417) | about 3 months ago | (#45736743)

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. (-1)

Anonymous Coward | about 3 months ago | (#45736819)

The U.S. Department of Energy (DOE) is holding a national Summit to catalyze investment in energy efficiency across the public, private, commercial, industrial, and multifamily sectors. We look forward to recognizing leaders and highlighting innovative market solutions and best practices.
Save the Date!
What: DOE Better Buildings Summit
When: May 7–9, 2014
Where: Washington, D.C.
Who: Industry, government, and energy efficiency leaders and stakeholders
Registration will be opening in February 2014.

Re:Not sure why it's troubling. (5, Informative)

david.emery (127135) | about 3 months ago | (#45736909)

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.

Perhaps (-1)

Anonymous Coward | about 3 months ago | (#45739023)

Perhaps your code is shit if you are relying on or invoking compiler bugs for your code to work. I've never had a code generation bug in my life.

Re:Perhaps (0)

Anonymous Coward | about 3 months ago | (#45739127)

I've had code generator bugs in a c++ compiler from SGI in 1995. I was trying to do what is now called RAII. The compiler didn't really like objects on the stack, in fact it called the destructor twice, even after the stack frame was reused by another function call. I gave up on c++ for the next 30 years.

Re:Not sure why it's troubling. (4, Informative)

zubab13 (3445193) | about 3 months ago | (#45736985)

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 [github.com]

Very different code (4, Interesting)

Anonymous Coward | about 3 months ago | (#45736779)

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 (5, Insightful)

david.emery (127135) | about 3 months ago | (#45736953)

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 (2)

Gothmolly (148874) | about 3 months ago | (#45737081)

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

Re:Very different code (4, Insightful)

david.emery (127135) | about 3 months ago | (#45737151)

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 (-1, Troll)

Gothmolly (148874) | about 3 months ago | (#45738139)

Your situation is unique because you have a monopoly contract and an undemanding customer.

Re:Very different code (1)

david.emery (127135) | about 3 months ago | (#45738239)

Mark parent -1 troll.

That comment just demonstrates you don't know much about these kinds of markets.

Re:Very different code (2)

DickBreath (207180) | about 3 months ago | (#45738743)

> 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 (-1)

Anonymous Coward | about 3 months ago | (#45737267)

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.

Why are you limiting that to commercial products? And if it took over a year for you and others to figure out what was going on, I doubt having the source code would have helped.

Any poorly-designed application is subject to such issues.

Just a guess, but it's likely you were seeing the impact of different expected alignments of classes/structures. If so, your optimized code produced structures/classes with different internal alignments than what the unoptimized commercial library code was expecting.

If that's the case, having the source code wouldn't have changed anything.

Someone who really knew what they were doing would have written the library (including all header files) so that the optimization level and alignment constraints used to compile the calling code were irrelevant.

Re:Very different code (1)

mark-t (151149) | about 3 months ago | (#45737641)

Even better, a compiler writer ought not to make a compiler that cannot reliably link separately compiled unoptimized and optimized code such that they will work as they are written to. That is, if a optimization switch is being used that cannot reliably work with separately compiled unoptimized code, then they should not be able to link together in the first place. The compiler/linker should bitch about it even before the program is first run.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45737821)

Even better, a compiler writer ought not to make a compiler that cannot reliably link separately compiled unoptimized and optimized code such that they will work as they are written to. That is, if a optimization switch is being used that cannot reliably work with separately compiled unoptimized code, then they should not be able to link together in the first place. The compiler/linker should bitch about it even before the program is first run.

How would a compiler know if your code is subject to such restrictions?

If you don't know what you're doing, don't wander over into the deep side of the pool where programming languages don't hold your pee-pee for you.

Re:Very different code (1)

mark-t (151149) | about 3 months ago | (#45738451)

Optimization flags could be embedded into the metadata of the output object file from the compilation phase. The linker could then easily determine if optimization flags of two separately compiled units were compatible and refuse to link them if they were not.

Re:Very different code (1)

Immerman (2627577) | about 3 months ago | (#45738509)

Doesn't seem that hard to me. The compiler is making certain assumptions when compiling code with a given set of optimizations. It shouldn't be difficult to determine when those assumptions may affect, for example, memory alignment of data being passed between modules (I'm just guessing that's one of the common culprits). It may not be easy to eliminate those assumptions entirely, but it should be trivial to make a notation in the object file indicating the potentially incompatible assumptions made and list any functions directly impacted by each of those assumptions. Basically any time something is exposed anything through a function interface or externally accessible data you have two choices: make sure all exposed aspects are either deterministically consistent with the standard, or make a note of the inconsistency/non-determinism.

Once you have that the linker can then check for incompatibilities - any time module A and B are compiled with inconsistent assumptions *and* A accesses affected components of B or vice-versa then you throw a warning, otherwise (like if A only uses simple functions interfaces unaffected by the inconsistencies) you can be reasonably certain there are no optimization-based incompatibilities.

Even if 99% of the incompatibilities are actually false-positives where the inconsistencies aren't actually relevant that would still be a phenomenal asset in debugging - it makes highlighting potential problem code trivial, and probably rules out at least 90+ percent of the codebase as the source of the problem. And given even fairly unsophisticated code analysis it probably wouldn't be that hard to bring the false-positive rate way down.

Re:Very different code (1)

david.emery (127135) | about 3 months ago | (#45738971)

"having source code wouldn't have changed anything" Disagree. Particularly at interfaces (e.g. cross-language/cross-compiler calls, APIs to COTS products, etc), sometimes you need to see inside the product to figure out what's failing at the interface. It's nice to talk about omniscient knowledge on the part of product developers, API specifiers (who might not be the same as the API implementers), and customers/users of that API for that product. Our specification techniques are by no means rigorous enough to prevent these kinds of problems.

"Risk" means just that. It's not a guarantee of failure. Rather it's the possibility of failure, coupled with (multiplied by :-) the consequences of the failure occurring.

Here's a real-world example, not related to compiler problems per-se, but relevant to your comment:

We had developed Unix RPC code that worked just fine on several systems, including the commercial product the hardware vendor was proposing. When we got to the installation for test, the code didn't work. After going up to the General Officer/SES level, and across to the vendor senior VP, I was given a copy of the vendor's source code for their RPC library. I was able to step through their code to the actual kernel syscall, and most importantly was able to see the failure value returned by the syscall. (The RPC library took that value, converted it into an ERRNO value of "EACCES", -which didn't tell us -why- the error actually happened.)

When I saw the value of the syscall, which indicated a non-privileged (not root) process was trying to do something that required 'root' privilege, I was able to go back to the vendor and ask, "Did you implement extra security features for RPC?" After some hemming and hawing, they came back and said, "Yes, you have to be root to install an RPC service." More importantly, that security feature WAS NOT DOCUMENTED. (And I can understand the rationale for saying that only privileged/root accounts can install public RPC services, so this was not an unreasonable restriction, but it was a change from standard practice in Unix systems of the time.)

This is an example of (a) a situation where the interface failed, even though all of the -code- was correct; (b) the only way I found this was to step through the vendor library to figure out the problem was -missing documentation-.

Re:Very different code (1)

phantomfive (622387) | about 3 months ago | (#45738353)

Any commercial product for which you don't have access to source code is an integration and performance risk.

So true, I've run into the same problem. It doesn't mean you need to only use GPL, but you should try to get the source code when you sign the contract to use the product (you're probably paying enough, anyway).

Re:Very different code (1)

Darinbob (1142669) | about 3 months ago | (#45739111)

Yup, and the commercial product with paid support does not actually get you a fix; in fact they may often tell you that you can upgrade to a later version if you purchase it.

Re:Very different code (1)

bzipitidoo (647217) | about 3 months ago | (#45736961)

it may be that a very well hidden bug is lurking in the code and the latest GCC is exposing that in some way

I have run into this situation. The code actually depended upon a bug in the older gcc versions. When that bug was fixed, the code stopped working. In some cases, the compile failed, in others, it crashed at runtime.

Specifically, this was around gcc version 2.7, and the bug was this: for (int i=0; i < SIZE; i++) { ... } for (i=0; .... The variable "i" should be out of scope for the 2nd loop and cause an error during compilation, but gcc didn't catch it. gcc version 2.95 caught it. I forget if that bug was fixed in 2.7 or 2.95.

Re:Very different code (4, Informative)

Mr Z (6791) | about 3 months ago | (#45737129)

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 (4, Informative)

drawfour (791912) | about 3 months ago | (#45737389)

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 (1)

ebno-10db (1459097) | about 3 months ago | (#45737587)

I used to try to do that, but there are several problems. First, it's non-portable as hell. Second, have you ever tried turning on all the warning options in gcc (and some other compilers)? I'm not sure it's possible to write 10 lines of code that won't generate at least one warning.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45737789)

I used to try to do that, but there are several problems. First, it's non-portable as hell. Second, have you ever tried turning on all the warning options in gcc (and some other compilers)? I'm not sure it's possible to write 10 lines of code that won't generate at least one warning.

All my code is compiled with

    -Wall -Werror -pedantic

What is the problem writing correct code?

Re:Very different code (1)

Anonymous Coward | about 3 months ago | (#45737981)

You can also use -Wextra to get even more warnings not enabled by -Wall.

Re: Very different code (1)

Anonymous Coward | about 3 months ago | (#45738527)

And that is lightyears from displaying _all_ warnings.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45738053)

That is your problem right there.
If you have warnings you are doing something wrong, period. If it won't bite you now, it will bite you on another compiler.

These days I compile everything with both clang and gcc, and I fix all the warnings. clang also has a static analyser and I also fix all the warnings from that.

Re:Very different code (3, Insightful)

drawfour (791912) | about 3 months ago | (#45738229)

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 (3, Informative)

0123456 (636235) | about 3 months ago | (#45738609)

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 (0)

Anonymous Coward | about 3 months ago | (#45738999)

Speaking about different experiences. I work in a team developing server software which is expected to use up to 80% of CPU capacity at times. I'd say it still makes a little difference.

Re:Very different code (1)

Anonymous Coward | about 3 months ago | (#45738159)

But please, don't release with that configuration. There's more than enough software out there where you try to compile it on a recent system and it fails because in newer GCC version something is now a warning that previously wasn't and then you have to read the documentation of the compiler and the build system to find out how to disable this one warning when the only thing you wanted was to compile this damn software.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45738069)

No sh*t. That's what he's saying.

Re:Very different code (1)

Immerman (2627577) | about 3 months ago | (#45738931)

Not at all. There's a very big difference between "There was a bug in the compiler which let X slip through until update Y" and "Update Y adheres to new language specifications that make X illegal", even if they look quite similar to a programmer who doesn't follow developments in the language. Can't remember for sure which camp this fell in, but I do remember dealing with the issues for years when moving between compilers that adhered to the old and new standard.

IIRC under the old standard doing it the new way, redeclaring "i" in each for loop, was actually illegal as it caused multiple declarations of the same variable name. As such your options for portable for loops were pretty much
1) use distinct iterator names - tedious and potentially confusing, especially in code that lends itself to descriptive single-letter variable names.
2) pre-declare your iterators so they can be reused by multiple loops
3) Enclose your entire {for (...) { } } statement within extra { }'s to force iterator new-style scope-limiting under the old standard.

I used all of them over the years, and they were all sub-optimal.

Incidentally - did anyone else get into the habit of using "naked" { }'s to scope limit temporary variables for clarity? Sometimes I'll even scope-limit whole blocks of code that could conceptually be spun off into a separate function, at the expense of clarity or significant labor. My rule of thumb - if a "sub-function" would take more parameters than it has lines of code, it's probably not worth spinning off unless it does something tricky and will be called from multiple places. That doesn't mean it's not worth putting some low walls around it though. Madness?

Re:Very different code (1)

jbcksfrt (1167293) | about 3 months ago | (#45737299)

That was informative, but I would expect that to be caught at compile time. The OP mentioned that he was having runtime errors, I believe.

Re:Very different code (1)

fulldecent (598482) | about 3 months ago | (#45737399)

Stop. You are making me feel old, I remember writing code like that. (Which compiled)

Re:Very different code (1)

bzipitidoo (647217) | about 3 months ago | (#45738011)

The samples of assembler made me feel old! I'm familiar with x86 assembler, and the variations on MOV that go back to the 8086 (things like MOVSB, MOVSW), but this VMOVUPD was totally new to me. But then I have never looked at SSE, or even MMX.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45736967)

That's the most frustrating thing in CS.

Re:Very different code (2)

Immerman (2627577) | about 3 months ago | (#45738977)

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 (0)

Anonymous Coward | about 3 months ago | (#45736979)

You may want to check out this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=71116 [freedesktop.org]

Basically, GCC changed instruction ordering a bit to boost performance with out of order executing processors... If your code had undefined behavior similar to the code in that bug report, it may well be the cause.

Re:Very different code (1)

angel'o'sphere (80593) | about 3 months ago | (#45737059)

It can as well be that you have a subtile memory bug which never really triggered when compile with the old compiler.

E.g. the latest bug like this, which I encountered.
something like:
char[10] data;
read a file with 10 bites into "data". Assume it is a 0 terminated string.
Surprisingly that always worked as malloc() handed out chunks devidable by 4, zero initialized. So behind the 10 bytes where 2 more zero bytes.
Switching to another compiler (more correctly clibrary) made that code crash, but it worked for years before.

Re: Very different code (0)

Anonymous Coward | about 3 months ago | (#45737883)

Well that's just bad code fromtwo bad assumptins. And malloc definitel does not zero initialize by design!

Re: Very different code (1)

0123456 (636235) | about 3 months ago | (#45738639)

And malloc definitel does not zero initialize by design!

But, at least early in the program's execution before you start reallocating freed memory, there's a good chance the memory malloc() returns will be zero-filled.

I seem to remember that debug builds on Windows fill allocated memory with a known pattern for just this reason? Or maybe that was a special hacked version of malloc() that we were using.

Re: Very different code (0)

Anonymous Coward | about 3 months ago | (#45739029)

Windows zeros unallocated pages of memory when the system idle thread is running, so there if your system has a long uptime there is a good chance your program will malloc zeroed memory.

Re:Very different code (3, Insightful)

PhrostyMcByte (589271) | about 3 months ago | (#45737481)

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

That might well be a bug (1)

Anonymous Coward | about 3 months ago | (#45737577)

I just had one of those "WTF was I thinking then". An old C program of mine started dumping code. Long story short: I did one of those things in the "don't do that" category: a function scans a text buffer, stuffs a null byte here and there and returns pointers into the buffer: think tokenizing.

Point is... the buffer was stack allocated in this function! Don't try this at home, I say :-)

A newer gcc saw the buffer wasn't being accessed within the function and thought "meh, after return this buffer is toast anyway. No need to write those pesky NULLs. No one will see that!".

The compile with the old compiler "just worked" because nobody touched the stack in the meantime: the caller copied away the bits needed. Sheer luck, I'd say.

So it may well be that there are some undefined behaviours in there which fall prey to a more aggressive optimizer. Try compiling with -O0 and see whether there's any difference in behaviour. If there is... happy bug hunting :-)

Re:Very different code (1)

fatphil (181876) | about 3 months ago | (#45737937)

Probably your code contains undefinted behaviour. The optimiser has detected a situation which it is completely sure must be true (otherwise there would be undefined behaviour), and optimised something away. When the must-be-true assumption turns out to be false in reality, the code was under no obligation to work, so who cares what happens. Personally I think it's bad QOI to remove significant bits of code as an optimisation based on assumptions about the lack of undefined behaviour without some kind of warning, at least at the higher instrumentation levels. You can't catch everything, but examples like this should be flagged when warning levels are high (but aren't):

int foo(struct bar_t *baz){
                quux *quuux = &baz->pquux;
                if(!baz) { /* can't be true, otherwise the above would be UB */
                                return -EINVAL; /* so no point even including this whole block */
                }
                return make_use_of(quuux); /* may dereference invalid pointer */
}

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45738795)

You must understand the problem is that to the optimizer it is insignificant code; the optimizer cannot tell if such code was intentional by the programmer, placed there via macros (and not intended by the programmer in question), or placed there by the compiler in earlier passes of the optimizer/code generator.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45737999)

This is not necessarily indicative of a gcc bug. It could very well be (and almost certainly is in fact) that you are relying on undefined behaviour, and the compiler happens to be optimising that undefined behaviour in a different way (that is, it's your bug).

Of course, this is far from a certainty, so your correct course of action is to reduce the size of your code until you know what it is that causes the crash, and then read the specs until you understand whether it should be compiled the way you think it should be.

Re:Very different code (0)

Anonymous Coward | about 3 months ago | (#45738131)

Try this: -fno-aggressive-loop-optimizations

Re:Very different code (1)

Megane (129182) | about 3 months ago | (#45738841)

If only there was some way you could find out where it crashed, what the generated code looked like, etc. This could be a great way to find bugs in a program. You could call it a Great Detector of Bugs.

News for nerds or not (5, Informative)

symbolset (646467) | about 3 months ago | (#45736847)

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 (-1)

Anonymous Coward | about 3 months ago | (#45737041)

What is this programming crap doing on slashdot?!?! I thought we were only supposed to comment about new pink fones & which monkey soulskill evolved from. /sarcasm

Re:News for nerds or not (0)

Anonymous Coward | about 3 months ago | (#45737157)

You are absolutely spot on. Back in "the day" when I was learning about computers, we did build kit 8080a machines and hand built add on memory expansion for them (on breadboards), etc. We had to create programs for them to do things like control model train switches, etc. - in assembler of course - and these things only had the most basic of interfaces (an LED display and a 24 key keyboard with hex input, a store, recall, and run key). Even then I wouldn't have been any good at "optimizing". We just wrote some assembler that worked and called it done. After that I hacked a bit of assembly on a Commodore VIC-20 - it was just a simple text editor. Since then it has been high level languages with no in-line assembler. I wouldn't have the first clue what to look at in checking the output of my compiler. I write high level code and the compiler does its job and creates something that can run on the OS / hardware. End of story.

Re:News for nerds or not (2)

Mr Z (6791) | about 3 months ago | (#45737201)

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 (2)

jbcksfrt (1167293) | about 3 months ago | (#45737333)

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

Re:News for nerds or not (0)

Anonymous Coward | about 3 months ago | (#45737815)

and I thought this was the NSA/Snowden site.

Vectorized factorials! (4, Interesting)

Mr Z (6791) | about 3 months ago | (#45737049)

One amusing thing I discovered is that GCC 4.8.0 will actually unroll and vectorize this simple factorial function: [spatula-city.org] Just look at that output! [spatula-city.org]

Re:Vectorized factorials! (4, Funny)

DickBreath (207180) | about 3 months ago | (#45738909)


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! (3, Informative)

Mr Z (6791) | about 3 months ago | (#45739071)

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? (3, Interesting)

excelsior_gr (969383) | about 3 months ago | (#45737177)

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...

Re:Why is this still a topic? (1)

mjwalshe (1680392) | about 3 months ago | (#45737423)

Its not C++ and OO and for some reason C++ devs seem not to want to learn fortran for technical programming which is still fortrans main use

Re:Why is this still a topic? (0)

Anonymous Coward | about 3 months ago | (#45737731)

Modern Fortran can handle OO

Re:Why is this still a topic? (-1)

Anonymous Coward | about 3 months ago | (#45737869)

That's because FORTRAN is a piece of shit. Never under any circumstance should anyone ever use it.

Re:Why is this still a topic? (0)

Anonymous Coward | about 3 months ago | (#45739141)

That's because Any language you dislike is a piece of shit. Never under any circumstance should anyone ever use it.

FTFY. What a fucking ignorant you are.

Re:Why is this still a topic? (0)

Anonymous Coward | about 3 months ago | (#45737817)

Pfft!

Matlab just recently (2010?) started making use of SSE. Or, at least just started requiring computers WITH SSE2 to run.

Trust but verify (2)

QuietLagoon (813062) | about 3 months ago | (#45737591)

...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.

Machine code you fucking witless poser! (0)

Anonymous Coward | about 3 months ago | (#45737643)

To be kind.

Re:Machine code you fucking witless poser! (0)

Anonymous Coward | about 3 months ago | (#45738103)

No, the compiler spits out assembly. The assembler is what turns that into machine code.

Re:Machine code you fucking witless poser! (-1)

Anonymous Coward | about 3 months ago | (#45738227)

Compilers in the 21st century and even long before do not start assemblers you witless fuck.

Cruel to be kind and you will thank me later.

Re:Machine code you fucking witless poser! (1)

Anonymous Coward | about 3 months ago | (#45738427)

Educate yourself. [washington.edu] Is it not embarrassing to fling all this poo only to find out you are wrong?

Re:Machine code you fucking witless poser! (2)

bws111 (1216812) | about 3 months ago | (#45738511)

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

Re:Machine code you fucking witless poser! (0)

Anonymous Coward | about 3 months ago | (#45738813)

There is no way to optimize post-compile. Compiling to asm form made sense when machines came in MB sizes but back then this asm was used as a starting point and then taken up by hand to be refined by an expert (in those days, if you coded you were an expert, by def.). A compiler going to an assembler today is LAME.

Re:Machine code you fucking witless poser! (2, Informative)

VortexCortex (1117377) | about 3 months ago | (#45738475)

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 [vortexcortex.com]", 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.

Clang/LLVM. (1)

Anonymous Coward | about 3 months ago | (#45738531)

'Nuff said.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...