This assertion is very widely popular amongst the HLL programmers. Even assembly programmers repeat it sometimes.

But is it true?

Recently, I posted a question on StackOverflow asking for references to some objective proofs - articles, studies, experiments.
The result, was simply nothing. They was not able to point me even single reliable source of information.

On the other hand, my experience with disassembled code shows pretty mean or even bad quality of the generated code. But I didn't made some research - it is just impression.


What is your opinion?

There have been a few previous discussions on here about this. Here are some links to read:

http://board.flatassembler.net/topic.php?t=10158
http://board.flatassembler.net/topic.php?t=6386

Do we really need to go through it all again?

Thanks, revolution - the second link can be even considered "study", well at least the first page.

[ Post removed by author. ]

Yes, the same is my opinion and observations. Contrary to the public opinion. But maybe we are some exception from the rule. IMO, some objective research is needed.

That depends on the code.
I examined the VS 2008 optimized code and it is excellent code.
Hard to code it better in ASM.

The only complain I have is that sometimes (not always) the API calls
are routed through some kind of stub table of JMPs instead of a direct
call to an address within the import table -- like FASM does it.

Otherwise, very good code.
All registers are planned to be busy at all times.

I've seen many a HLL forum discussion about how -O switch (or whatever the optimise switch is) produces bad code. Occasionally people have had to rewrite the source to get around the bug, or simply disable optimisations to get it to work.

Well there is another mantra: "compilers are able to generate code that are on par with hand-written assembly codes, given the codes are well written and using optimized algorithm, and the necessary optimizations are turned on"



Not sure about this. Probably this is the case of experienced compiler writers vs non-experienced assembly coders?

Perhaps that is the point. A good HLL programmer looks at the AT&T output and thinks "Wow, I could never write that" and naturally assumes that no one else could ever write that either, and thus concludes that compilers are assembly code gods far exceeding what humans could ever achieve?

[ Post removed by author. ]

I said that because I assume professional compiler writers are also experienced assembly coders.

I think this is not a safe assumption. A good chess engine programmer is not necessarily a good chess player.

Would be nice if you actually got some valid answers, but I kinda doubt it - especially since the wording makes it seem like you want "asm vs C++ studies"... I doubt there's any serious studies on that topic, IMHO not something you can really compare (at least without defining some detailed comparison parameters).

I pretty much agree with what Alexey Frunze (isn't he an old osdev guy?) wrote, but it's not backed up with facts, only "common sense" . I also fully agree with Frank Kotler - "The best the compiler can do is break even!".

I'll also quote myself from that 2006 thread revolution linked: "Nobodys saying that humans can't be compilers anyway, at least not anybody with a clue. What's more reasonable to say is: "for most code, it's not worth the bloody effort" " - ("can't be" -> "can't beat", of course) and I do believe that's what most people mean if they say "you can't beat the compiler". If they honestly don't believe you can beat a compiler at all, they shouldn't be allowed to do software development.

Anyway, that was more opinion, without the references you're asking for, sorry - but wrote that because I think you might be asking the wrong question? I'm not certain what the right question is, though . But I reckon you might be interested in just some scientific study of compiler code generation quality (algorithms, advances in later years, ...) without necessarily setting it up as an "assembly vs C++" thing?

I don't have any references around - but if you were to embark on a google-mission, looking for "link-time code generation" (aka "whole program optimization) is one kind of compiler optimization that would be tedious to do manually. Same goes for profile-guided optimization (branches ordering to minimize mispredictions, better idea of which functions it makes sense to inline, group code based on temporal locality for better caching & paging, etc). Semi-automatic vectorization/parallelization.

Those were just some keywords that might turn up something semi-useful - I'm in no way claiming that any of the above result in unbeatably-optimized machine code (if I were to claim anything, it would be "gives decent speedups more or less for free, while keeping code understandable and maintainable").

Would also be interesting if anybody could find an example of a .NET or JVM based language beating native code at something, where the native code doesn't suck and the VM-language code actually looks like a style you'd normally use in that language... - potentially, a JIT'er could do "a lot of fancy stuff", I just haven't seen anything real-world'ish where one of those platforms win on code execution speed...

PS: sorry for semi-derailing your thread

EDIT: wrt. bugs, static program analysis is a really valuable tool (and would probably be very hard to do for assembly, given you don't have as much semantic information to go by). For C++, some of the bugs such a tool picks up are caused by C++ sometimes being a bit too complex for it's own good (that would sometimes be things people think are compiler bugs, but really are caused by depending on undefined behavior).

f0dder, I mentioned C/C++ because they are recognized as the languages with best code generation. If you know some other language that is able to generate better code, I will be glad to include it in my research.

I posted this topic here, because here we can discuss the subject, while on stackoverflow I searched for information - they have policy against discussions.

Of the languages that I've come by (which are relatively mainstream), the C/C++ compilers do tend to get the best runtime characteristics (keep in mind that there can be quite some difference from compiler to compiler - and if you look at runtime as a whole, not just the instructions it spits out for your code, the quality of the runtime library has to be taken into account as well).

Debian hosts a "benchmark game" with a decent number of languages represented, including Java7 and C# (running on Mono - would be nice if one could get some stats for MS's VM). It also only does GCC, whereas at least Clang and Intel C++ should be considered, and a couple of Microsoft compilers as well (though that'd require a bit of trickery, or retooling the entire benchmark to run on Windows...)

Those are just numbers, though - it would be more interesting with some information on the various optimization each compiler is able to do, from high-level transformations down to heuristics for code generation. Also, given that the same algorithm is used in each language (to try and get something that's mostly apples-apples comparisons), the chosen implementation might be suboptimal for the language...

So, what do you wish to discuss in this thread?
It's always possible to find a snippet that performs either pathologically bad or exceedingly well in one compiler or the other, and IMHO "another of those 5-page optimizefest threads" isn't so interesting (well, they can be, but IMHO it's somewhat of a different topic).

I guess there might be some interesting information floating around at the LLVM site - it's probably the most interesting open-source compiler infrastructure project these days; it seems to generate fairly decent code (Apple have been throwing money at Clang/LLVM to escape the GPL clutches of GCC), and the codebase is probably in a lot better state than crufty old GCC. But it's a massive project, and they have quite a lot of publications.

BTW, Intel Fortran behaves really good on these tests. I have to check it - maybe it's my HLL after all.

http://software.intel.com/en-us/intel-parallel-studio-xe-purchase/

$1,899 is very expensive.
Suddenly I remember Fortran from my numerical analysis class.

Well, for $1899, it is definitely not my HLL.
I used to write fortran for mainframe in my high school days. It was so long ago...

I wonder if that's due to code generation, code style, or super-optimized standard libraries? (Too lazy to look right now) - also, it seems that even in spite of "use the same algorithm", some are implemented single-threaded and other multi-threaded... that gives Fortran a ~5x speed boost in one of the tests. So I'd say the benchmark has a few flaws here and there

[ Post removed by author. ]