Hello. I'm a compiler

You still beat them with inline assembly, but you probably won't accelerate the code vectorwidth times anymore.

Yes, you can take a subroutine and apply local optimizations on it. Building complex software in assembly that on the whole is better optimized than what a compiler can do is next to impossible.

Speaking of SIMD and stuff like it, there are already optimizations that LLVM is doing, but such optimizations are hard to apply ahead of time because (1) if you want to distribute those binaries easily, then you need to compile for the common denominator (which is less of an issue with LLVM) and (2) your programming language sucks. It's not the compiler's fault, but rather your own fault that you're using a programming language so confusing that inferring intent from your code is next to impossible. How can the compiler know that you're sorting freaking numbers if you're specifying exactly how bits move around in memory while doing so?

If you're speaking about virtual machines though, there are projects out there for .NET or Scala for instance that can recompile/retarget code at runtime to run with SIMD instructions or on your GPUs if you have any. All you need is a virtual machine that runs bytecode and a programming language (slash compiler) that lets you access at runtime the syntax trees of the routines that you want to optimize and that lets you generate new bytecode. So you can easily shove this kind of optimizations in libraries for special-purpose and descriptive DSLs (e.g. LINQ).

Of course, it gets tricky and doing stuff like this at runtime has overhead, but it's better than what 99.99% of developers can do, not to mention that good developers first and foremost ship.

I have picked up your clever optimized SIMD and decided it was better to change the execution order, because another unit was bored without nothing to do.

Unfortunately the L2 cache seems to have some issues getting all required data for your instructions due to the way all your threads are manipulating the required addresses from multiple cores.

ITYM "It will probably take another 30 years before I use a language that tells you what the required semantics of the code are, meanwhile I'll use my requirements interpretation privileges to relax the semantics in a few places"

So you go ahead and write clever SIMD code but please use the SIMD intrinsics I can understand, not inline assembler which I cannot do anything with. You are very good in expressing algorithms in a SIMD friendly way and do a decent job in instruction selection.

You, however, are not very good in doing instruction scheduling and register allocation, so let me handle that and we can achieve a result that can keep the CPU pipelines busy. When you make the tiniest change to the program, I can re-do instruction scheduling and register allocation in an instant, when that would take you hours to rewrite the whole algorithm to use different registers.

my point: SIMD intrinsics + a smart C compiler produces a lot better code than a programmer writing assembly. Clang + vector extensions in particular is very good at it.

I noticed that it takes forever to understand inline assembly. I don't foresee myself ever thinking like a computer and reading assembly as well as a high-level language.

Isn't that awesome? I can use the thing without ever understanding what it does :) I'm so glad my car works without me ever having to know anything about how it works. I know it requires some form of money (gas) to work. That's it. Money in -> Transport out. Perfect.

The linked post never proclaimed no one "will ever understand" compilers. That's just what you're reading into it. You try to get upset at it, so you do. It merely proclaims that compilers are incredibly complex, which is the nice thing about them. If compilers were stupid they'd be a lot less useful.

Can you e.g. explain how a transistor works, from basic quantum mechanical principles? If not, then there's something in the stack you may never understand, because you're simply not interested in spending the time necessary to understand that at the level a physicist does.

Computer Science majors should be familiar with how compilers work and the theory behind them. But the answer to the question is that for 99% of cases, using a higher-level language and leaving the optimization to a compiler written by subject matter experts makes sense. (ie. Don't re-invent the wheel.)

He isn't saying compilers are based on a "millions of hours of intense academic research that you won't understand". He's saying the specific optimizations implemented by these compilers are based on "millions of hours of intense academic research that you won't understand".

While the general theory behind compilers isn't particularly complex (and is totally worth learning! Your message about people learning about compilers is spot on), production compilers do employ a significant number of complex optimizations. You won't be able to match these unless you spend a very significant amount of effort learning about these specific optimization techniques.

While learning the theories behind compilers is quite useful, I'd argue that learning N tricks to more efficiently translate C into ASM isn't practical unless you want to turn your compiler into a production one.

My point is, there's understanding how compilers work, and then there's understanding all of GCC. I wouldn't like it if someone made the former sound too intimidating for me, but I don't mind feeling intimidated by the latter.

I can think of 2 reasons: study and fun.

First of all, it throws a wrench in high level optimizer's analysis. Plus, compilers and processors are getting smarter day by day while inline assembly in shipping code becomes more and more untouchable everyday.

Another reason is that compilers simply must* work for software development to continue, so people have spend the necessary amount of energy to get implementation and tests "right".

(*) There are always exceptions, like when a compiler auto-parallelizes code and introduces a race condition that is rarely triggered. But those cases are blessedly rare.

I've found that in the general case Compilers Know Better. It might not be true for very simple and limiter architecture such as small microcontrolers, but modern CPUs are so much complex and "quirky" that most of the time the compiler will beat you.

These days I only use assembly for very low level stuff where I need complete control of the execution flow (dealing with cache invalidation, MMU etc...) or some very specific and aggressive optimisation (like implementing <string.h> in ASM).

But hey, if you want to ditch C and write everything in ASM, be my guest (as long as we don't work together).

This is unfortunately too often true. Some compilers are tuned too much for looking good on artificial benchmarks, in which turning 3-line loops into thousands of instructions sometimes helps, even if it hurts on most real-world code.

> And if I don't want the compiler to do this, I have no idea how to stop this behavior, nor do I want to invest in the specific knowledge of the nuances any particular compiler.

The -O0 option, or its equivalent, is pretty easy to find in many compilers. If you're happy with the performance of your code without all those fancy techniques being applied, feel free to use it. Most people aren't ;-).

> P.S. Oh, and by the way if I really wasn't using half of the code I wrote, I would throw the source code away.

Only if you were aware of it ;-). I wish that compilers would focus a little more on helping me make my code better, rather than so much on magically making things better under the covers.

Whoah, that's what __sync_synchronize() and volatile are for. If you're trying to write order-dependent multithreaded code without those, the bug's in your code, not in compiler flag juju.

And even though the tone of that answer is humourous it still is a good answer, explaining why we don't all write Assembly instead of HLLs.

You can easily go creative on this

EDIT: Looks like it's locked at 1788!

You know why it's worth recreating the world inside a JVM? Because its behaviour is so much more thoroughly specified and predictable. Prior to Java, C++ didn't even have a memory model; every new release of GCC breaks a whole raft of C programs that didn't realise they were invoking undefined behaviour by having integer overflow. By the C standard, even a single instance of undefined behaviour invalidates your whole program, making it virtually impossible to predict the behaviour of any nontrivial-sized codebase.