flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > HLL compilers generate better code than hand written asm?

Goto page 1, 2, 3, 4, 5, 6, 7  Next
Author
Thread Post new topic Reply to topic
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
HLL compilers generate better code than hand written asm?
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?

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 03 Feb 2013, 09:04
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
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?
Post 03 Feb 2013, 09:26
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
Thanks, revolution - the second link can be even considered "study", well at least the first page. Smile
Post 03 Feb 2013, 10:22
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1171
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 21:45; edited 2 times in total
Post 03 Feb 2013, 13:15
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria

HaHaAnonymous wrote:
The occurrence of bugs are higher in HLL than in assembly (at least for me). And bugs in HLL are also harder to "fix" (at least for me).



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.

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 03 Feb 2013, 13:20
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1386
Location: Toronto, Canada
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.
Post 03 Feb 2013, 13:27
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua
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.
Post 03 Feb 2013, 13:33
View user's profile Send private message Visit poster's website Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 790
Location: Jakarta, Indonesia

Quote:

Compilers generate code that is as good



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"


Quote:

and often better than could be written by hand.



Not sure about this. Probably this is the case of experienced compiler writers vs non-experienced assembly coders?
Post 03 Feb 2013, 13:39
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua

TmX wrote:
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 03 Feb 2013, 13:45
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1171
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 21:45; edited 1 time in total
Post 03 Feb 2013, 13:46
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 790
Location: Jakarta, Indonesia

revolution wrote:
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?



I said that because I assume professional compiler writers are also experienced assembly coders. Wink
Post 03 Feb 2013, 14:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15241
Location: 1I/ʻOumuamua

TmX wrote:
I said that because I assume professional compiler writers are also experienced assembly coders. Wink

I think this is not a safe assumption. A good chess engine programmer is not necessarily a good chess player.
Post 03 Feb 2013, 14:07
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3172
Location: Denmark
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" Smile. 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" Smile" - ("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 Smile. 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 Smile (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... Smile - 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 Smile

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 Smile (that would sometimes be things people think are compiler bugs, but really are caused by depending on undefined behavior).
Post 03 Feb 2013, 14:29
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
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.
Post 03 Feb 2013, 15:11
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3172
Location: Denmark

JohnFound wrote:
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.


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? Smile
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 Smile (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.

_________________
Image - carpe noctem
Post 03 Feb 2013, 15:32
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
BTW, Intel Fortran behaves really good on these tests. I have to check it - maybe it's my HLL after all. Wink
Post 03 Feb 2013, 16:03
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 790
Location: Jakarta, Indonesia

JohnFound wrote:
Intel Fortran behaves really good on these tests. I have to check it - maybe it's my HLL after all. Wink



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.

Smile
Post 03 Feb 2013, 16:42
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
Well, for $1899, it is definitely not my HLL. Very Happy
I used to write fortran for mainframe in my high school days. It was so long ago...
Post 03 Feb 2013, 17:07
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3172
Location: Denmark

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


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 Smile

_________________
Image - carpe noctem
Post 03 Feb 2013, 17:19
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1171
Location: Unknown
Stupid post removed.


Last edited by HaHaAnonymous on 28 Feb 2015, 21:45; edited 1 time in total
Post 03 Feb 2013, 18:49
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3, 4, 5, 6, 7  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.