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.

The actual confession is at 01:19:37: "The compiler would not find this." 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 (), 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.

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.

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.

@revolution: 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).

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.

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

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: (Looks fun, perhaps this is the way to go to make fasm/fasmg more portable.)

But what I find especially amusing is the piece of the discussion that follows:

Oh no, HLL style macros in fasm/fasmg source! 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.

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.

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]

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

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.