flat assembler
Message board for the users of flat assembler.

Index > Main > HLL compilers generate better code than hand written asm?

Goto page Previous  1, 2, 3, 4, 5, 6, 7
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Hehe.

I just watched the switches presentation from OOTB: https://millcomputing.com/docs/switches/

If you have the time skip to 01:19:08 in the video (the postscript) where Ivan makes a confession about the compilers. Laughing

The actual confession is at 01:19:37: "The compiler would not find this." Laughing Laughing when referring to a piece of hand optimised code that is only two-thirds of the length of the compiler generated code.
Post 23 Oct 2017, 15:52
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Very Happy
Post 23 Oct 2017, 17:41
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1469
Furs
revolution wrote:
If you have the time skip to 01:19:08 in the video (the postscript) where Ivan makes a confession about the compilers. Laughing

The actual confession is at 01:19:37: "The compiler would not find this." Laughing Laughing when referring to a piece of hand optimised code that is only two-thirds of the length of the compiler generated code.
Compilers will never be "the best" at code generation unless AI takes over and ditches some stupid maintainers. And it doesn't have to do with humans having special powers (though we are indeed great at abstract thinking to see problems outside the box). It has to do with compiler developers' attitudes.

I don't know how it is with other projects, but with GCC if someone sends a patch with a "super optimization" mode that provides smallish gains but increases compile-time significantly, it gets rejected (and it's pointless to try to defend the guy as I did). Which is pathetic, this way it will never improve, because some problems are difficult by definition.

Who the fuck prioritizes compile-time speed for FINAL SUPER OPTIMIZATION compilation? Compiler maintainers. That's why compilers will always be behind human-coded assembly (of course, assuming you even hand-code in asm). If you want compilers to move forward, make them work really hard for a 1% gain. Much of the easy optimizations are already mature but they won't see it.

I don't care how much they want to favor stupid compilation speed (Rolling Eyes), I want a switch even if it makes compilation take from 15minutes to 6 hours (I'll do it overnight), even if it's just 1% gain. Because then I know compilers won't be held back by moronic attitudes.


On a sidenote, that architecture looks really hard-coded, even more than Itanium, exposing way too much of itself to the software. Yeah, I get it, this keeps it simple to decode and makes it fast and stuff, but then it will be difficult to extend it properly (since no abstractions) without breaking all software written for it.

I'm not even talking about extending the instruction set btw. I mean extending the actual micro-architecture (pipeline length, execution units, and so on) that's mostly hidden in x86 for example.
Post 23 Oct 2017, 20:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Furs wrote:
On a sidenote, that architecture looks really hard-coded, even more than Itanium, exposing way too much of itself to the software. Yeah, I get it, this keeps it simple to decode and makes it fast and stuff, but then it will be difficult to extend it properly (since no abstractions) without breaking all software written for it.
You have to watch the other videos to learn about the "specialiser" which does exactly that job of dealing with different resource sets and how that is handled.
Post 24 Oct 2017, 00:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Furs wrote:
I want a switch even if it makes compilation take from 15minutes to 6 hours (I'll do it overnight), even if it's just 1% gain.
Code:
> gcc foo.c -Oinsanecrazywearoutyourfanburnyourcpustaketheweekendoff

GCC: Compilation completed in 71:36:54.934
GCC: Saved 0.0034% execution time.
GCC: This code needs to run 29,412 times longer than 71:36:54.934 to realise any overall gain in production.
GCC: Note, you need to compile this again if you change any part of the architecture in the future.    
Wink
Post 24 Oct 2017, 03:45
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
The super optimization compiler will never beat human, not because of the compiler itself. The source code is the problem. The super optimized HLL source code is very hard to be written.

Actually, HLL programmer solves the problem: "What source code to write in order to get the optimal assembly code". In result:

1. If he knows the optimal assembly code, he probably made some tests and have the assembly code already. Why to write HLL code then?

2. Such HLL code is often much less readable and hard for understanding/maintenance. Often, more than the assembly code.

3. Such HLL code is optimal only for particular architecture.

That is why the programmers does not write optimal HLL code, except for the very critical small parts of their programs and I can't see how this can be changed in the future.

In the years I took part in several C vs ASM battles, where the task was not a particular algorithm, but complex enough program. It was permitted to make several versions, incrementally improving the solution.

So, the first versions of the assembly code (my) were very far from optimal, but still from 10 to 80 times faster than the C++ solution. In the next versions, I incrementally accelerated my solution 2..4 times. The C++ programmer started to copy my code one-by-one and translate it to C++. This way he was able to end with code only 10..20% slower (which is great), but totally unreadable and not portable C++ code. In the same time, my code remained readable, well structured and later used it for other projects with minimal changes.
Post 24 Oct 2017, 04:21
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1469
Furs
@revolution: Laughing but of course I meant more realistic in the sense that a human could definitely "optimize" better. If it takes a human to manually optimize something in 6 hours I don't see why GCC wouldn't be able to do similar in 6 hours, provided the source code provides all the necessary information (for example, using "restrict" properly). Obviously it has to be coded to even attempt to do that... and you know what that means. (that's what I meant with AIs, not necessarily "more intelligent beings than humans" at all, but simply "willingness to make such a super optimization mode where all the slow algorithms that were discarded get used")

@JohnFound: yeah, I agree about the part where the source code matters. In particular, the source code must give sufficient information to the compiler about the intent.

Otherwise it is literally impossible for it to know/prove that, say, two memory operands don't alias. That's why things like "restrict" exist (there's more but those are GCC extensions...) to "hint" the compiler about the intent. Of course, if you're wrong about them, the generated code will not do what you expect. Not the compiler's fault though, since you told it they won't alias (if they do, it's your fault).
Post 24 Oct 2017, 17:34
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
So to summarise:

Compilers have to guess what is required. Humans already know what is required. And thus the divide can never be closed due to compilers dealing with insufficient input information.

Waah, we need AIs that can understand the requirements.

Compiler, do what I mean, not what I say.
Post 25 Oct 2017, 05:42
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1469
Furs
Well compilers have to guess what is required because most HLLs suck and don't provide enough information (rather, don't allow you to provide enough information). Sadly even C/C++ lack a lot of this, however it's more bearable with GNU extensions.

The simplest (without talking about aliasing) is something like an "assume" directive. Tell the compiler something is assumed to be a value or relative to another etc (even if it doesn't do anything currently, it should still be there in the language).

MSVC and GNU both provide a "means" of doing this, but they're obviously not taking full advantage of it. However, it does turn a theoretically impossible situation into a possible one so the ball's on the compiler developers' court now to actually implement it properly, not on the language's lack of ability to inform it. But most other HLLs than C/C++ don't have many extensions and there's plenty still missing that would help the compiler "understand" your code, sadly.

Of course during debugging builds you turn the assume into an assert to make sure it's not invalid and assumed wrong (else subtle bugs will creep Smile).
Post 25 Oct 2017, 12:21
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland
Tomasz Grysztar
In the latest Paged Out! on page 8 there is a nice article about automatically converting project written in 32-bit x86 assembly to C. The resulting text still very much resembles the original assembly code, article shows a few samples like:
Code:
(( CHARS *) edi )-> len -= ecx ;    
Code:
eax = InvalidateRect ((( EDIT *) ebx )-> hsta , NULL , TRUE ) ;    
(Looks fun, perhaps this is the way to go to make fasm/fasmg more portable.) Wink

But what I find especially amusing is the piece of the discussion that follows:
Michael Maltsev in 'C as a portable assembly' wrote:
It’s interesting to compare manually written assembly code with code generated by a compiler from the assembly-like C code. In most cases the original code is shorter and looks more optimized, at least for GCC. For example, the compiled code uses the stack for local variables much more often than the original assembly code. Perhaps compiler authors could use this porting project to improve the compiler.
Post 18 Nov 2019, 17:59
View user's profile Send private message Visit poster's website Reply with quote
Mike Gonta



Joined: 26 Dec 2010
Posts: 238
Location: the-ideom
Mike Gonta
Tomasz Grysztar wrote:
In the latest Paged Out! on page 8 there is a nice article about automatically converting project written in 32-bit x86
assembly to C. The resulting text still very much resembles the original assembly code, article shows a few samples like:
Code:
(( CHARS *) edi )-> len -= ecx ;    
Code:
eax = InvalidateRect ((( EDIT *) ebx )-> hsta , NULL , TRUE ) ;    
(Looks fun, perhaps this is the way to go to make fasm/fasmg more portable.) Wink
Oh no, HLL style macros in fasm/fasmg source!
Tomasz Grysztar wrote:
But what I find especially amusing is the piece of the discussion that follows:
Michael Maltsev in 'C as a portable assembly' wrote:
It’s interesting to compare manually written assembly code with code generated by a compiler from the
assembly-like C code. In most cases the original code is shorter and looks more optimized, at least for GCC.
For example, the compiled code uses the stack for local variables much more often than the original assembly
code. Perhaps compiler authors could use this porting project to improve the compiler.
Something is wrong here. Even in 32bit the optimizer should be able to allocate registers better than that, but this is
compiled to x64 with even move available registers.

_________________
Mike Gonta
the-ideom - now you know how to compile

https://mikegonta.com
Post 18 Nov 2019, 20:05
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 527
Location: Russian Federation, Sochi
ProMiNick
Good hand written HLL code (without exception handling, OOP, within task that represent interfaces only as records|structures, with unsafe typecasting including defenitions like "varname vartype absolute at another_varname") will lose to assembly just a little - overhead would be exactly that unremmovable garbage that HLL compiler forces for initialization of application (in that initializations are located automatics cleanups for less skilled programmers).


And I dont nderstand how such crutches as initializations and cleaners could conquest with programmers, good programmers, no matter assembly programmers or HLL programmers.
Post 18 Nov 2019, 21:23
View user's profile Send private message Send e-mail Reply with quote
moveax41h



Joined: 18 Feb 2018
Posts: 59
moveax41h
JohnFound & friends,

I still consider myself to be a novice asm programmer, but I've heard this completely baseless argument far too many times from HLL programmers. To the point where, even as somebody who mostly wrote in HLL, the lack of evidence, proof, or research of this claim repeatedly stated over and over, actually made me want to learn assembly programming more to find out if there is any truth to this.

What I'm finding out is that there is not. Let me elaborate a bit:

Let's first think of what assembler itself is. It's a language made up of mneumonics which are given to specific CPU instructions or instruction groups. This, by nature, means that assembler brings the programmer closer to the CPU.

Now, most would probably agree that the further we optimize code, the closer we go to the CPU's instruction set. For example, if I just write a generic loop in x64 assembly and I ask for programmers to critique it - they may tell me something like:

If you change line 5 to use instruction X instead of instruction Y, you will accomplish this task in fewer clock cycles on CPUs A, B, and C.

The point I'm trying to make here is that assembler requires a programmer to inherently have a better understanding of the CPU and inherently see more of what's really going on in his/her program. This has the byproduct of a programmer having to reason about more fine-grained performance optimizations, because, well, assembler is a more fine-grained language in general.

For example, there are many different ways that a while loop can be written in assembler, or "while-loop-like-behavior" can be achieved. In a HLL program, the programmer will optimize the while loop itself to the best of his/her ability, but an assembly language programmer will optimize the CPU instructions used to achieve while loop-like behavior.

Another way to explain this is to think of a person who is obsessed with car care. This person has the absolute best car wash for their paint - it contains moisturizers, conditioners, and other high quality ingredients. It is also made specifically with detergent that is gentle on the paint job. This same person has a special carnauba OR synthetic wax which they have, over years of trial and error, determined works best on his/her paint for that specific car.

Compare this to the person who just goes to Walmart and purchases an "all-in-one wash and wax" product.

In the auto detailing industry, it is well-known that an all-in-one product will never achieve the same quality results as individual, specialized products. Let's analyze this further and look at some reasons:

Reason #1: The products themselves are engineered better - a product whose sole job is to be the top-of-the-market wax will have all of its engineering efforts placed on one thing - protecting the car's paint. Likewise, a top-of-the-line wash will be the same, but for cleaning contaminants off of the car.

Reason #2: People who tend to purchase separate wash, wax, and detail spray formulations, also tend to be the type of people who are willing and able to invest more time and money into their car's looks. This point shouldn't be understated - people who spend 6 hours a week working with their cars paint will see and understand things about the paint that those who use the drivethrough car wash down the street once every 2 weeks never will.

I want you to pay close attention to reason #2 because it is the most relevant to the overall point of my message - assembler forces the programmer to have a deeper understanding of his/her program at ALL levels, including optimization. This is something that a compiler cannot and will not ever do. What I mean by this is that while the compiler can "learn" optimization techniques, it is not and never will be the programmer. In learning these things, the programmer may even restructure the program itself, or rewrite it based off of the knowledge that he or she gained from writing in assembler, which would never have been gained writing in an HLL.

In fact, I would say that the statement "Modern C and C++ compilers generate more highly optimized machine code than humans can" is not only inaccurate, but it's essentially an oxymoron. It is similar to saying "A programmer who knows less about his own program can always optimize it better," or "A person who has just read a few books on brain surgery, can generally perform Minimally invasive endonasal endoscopic surgery better than a surgeon who has been performing this exact surgery on thousands of patients over the course of 20 years."

It just doesn't make sense.

Couple the above with the fact that, as your stackoverflow question and you yourself indicated, not one person has been able to show a specific, measurable example of how a professional assembly programmer came across compile-generated code and unable to "defeat" said code using hand-written assembly for a given machine.

I've not seen even one example of this.

Furthermore, most of the programmers who claim that the compilers are better than hand-written assembly programmers at writing code, are not assembly programmers and either have never programmed in assembly, or only did so in a 3 month class at school.

So these people are making a claim about how much better apples are than oranges, and they don't even know what an orange is.

My opinion on this is that most of these people have absolutely no idea what they're talking about and the sad reality is - they don't care about assembly, they don't want to learn it, they don't care or have the capacity to understand how the CPU actually works, or are just lazy, and so they jump on this cop-out bandwagon answer, that has never been proven or even substantiated, that compilers "write better code than most people could."

Actually, that's probably a true statement because most people don't know assembly well enough, not because compilers are all that great.[/i]

_________________
-moveax41h
Post 30 Nov 2019, 02:49
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 706
Location: Belarus
DimonSoft
moveax41h wrote:
people who spend 6 hours a week working with their cars paint will see and understand things about the paint that those who use the drivethrough car wash down the street once every 2 weeks never will.

I find it exciting how this explanation is close to what we call the Dunning–Kruger effect. As for the whole idea of your post, I guess, such arguments usually come from playing with word meanings, like, say, “HLL compiler produces better code than hand-written assembly [I wrote]” or “this specific piece of HLL code that is very friendly to SSE-optimizing compiler works faster than equivalent assembly code [using only general-purpose instructions]”.
Post 30 Nov 2019, 16:53
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 527
Location: Russian Federation, Sochi
ProMiNick
We can look at this from other side: it is nowhere said that asm coder should create whole code. Whole code could be created with HLL with closed source, but asm coder could improve any peace, recalculate relocs (for now only by hand) and get file with better logic than HLL produce.
I dosn`t know any HLL language that could patch code better (It couldn`t patch at all) than asm coder.
Post 30 Nov 2019, 17:42
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

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

< 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 cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.