How is Assembly faster than HLL's?

Question

How is Assembly faster than higher level languages if they are both compiled to machine code? I can understand inline assembly being faster than the surrounding HLL but as for an entire assembly program vs C for example, both are compiled to machine code and should run at the same speed.

Answer 1

It depends. Modern RISC processors are extremely hard to optimize by hand, which delayed branch, speculative execution, heavy pipelining, etc. It depends on what you are trying to do, which HLL you are using, how good the compiler is, etc.

Up until sometime about the turn of this century, the X86 architecture was closer to a CISC (think Vax) than RISC (think Sparc), and thus experts could beat good optimizing compilers. But AMD was kicking Intel's performance numbers seriously, because their chips were really far more RISC under the covers. The result is that hand written assembly for the X86 world split in performance.

For most specialized processors, such as DSP chips, the performance gains are still in hand written assembly, but even advanced users of DSP code typically rely on pre-written libraries to do the hard stuff.

Answer 2

Programs written in assembly language used to be faster, when the PC was slow and simple and the compilers not to bright.

I used to write lots of assembly in the 1980's, because you had to in order to use the PCs we had then. It was MHz instead of GHz.

Nowadays I just sometimes look at the code the compiler generates and see that it is at least as good as the one I could have written, but much easier to produce. Often it is a lot better than I could do.

One effect of this is that Microsoft has removed inline assembly for their x64 compilers, partly because most attempts to optimize using assembly just disturbed the optimizer and made it produce less optimal results for the surrounding code. A net loss!

Answer 3

Like many people here are saying, compilers do a pretty good job nowadays. However it is specifically not the case that they have become better than humans - maybe someday (better than some humans yes, clearly, but not "don't even try, you will never beat them"). Optimizing compilers are very good are knowing The Rules for optimization, but very bad finding opportunities to apply them. The programmer knows a lot about what values a particular variable can have at any program-point, but then the compiler has to try and figure it out again from context. Abstract interpretation goes a long way, but it isn't perfect and it cannot be. Compilers also aren't yet very good at optimizing cache use. They're slowly getting there, but currently you often have to make the high level code ugly to get a proper result. Compilers are also notoriously bad at using instructions that aren't "basic math" unless specifically instructed to do so with intrinsic functions (which are essentially cheating - you're almost writing assembly again) and when you do use intrinsic functions the resulting code is often not particularly good and besides it isn't any easier than writing in assembly directly (just more clutter from "underscores, underscores everywhere").

So, how is assembly faster? You know everything. The compiler blindly follows rules.

Of course that is all assuming that you really really know how to optimize for your target platform. If you're going to write assembly "the obvious way", you're probably not going to beat a proper compiler. Whether you can beat them also depends a lot on the compiler of course - ICC and LLVM are rather hard to beat, but on the other end of the spectrum, you could beat the .NET JIT compiler in your sleep (yes it's a JIT compiler, but so is LLVM, if you want it to be).

---

In case you want to know how to beat compilers..

Read everything here, several times. Then practice a lot, keep benchmarking everything, and go up against your favourite compiler for everything relevant (that will be the "inner loop" type of thing - there's no point optimizing code that doesn't take a significant portion of the runtime anyway). Eventually you will consistently beat it. It's not as hard as people make it out to be, it just takes a lot of practice and you should know how your target platform works by heart (you should never have to look up the latency or throughput of an instruction, its execution port and definitely not how many µops it creates).

Answer 4

The days that processor cores actually execute a machine code instruction directly are long gone. They are translated into micro-ops, risc-like instructions that were designed to keep a modern super-scalar, out-of-order execution capable core with multiple execution units going. The actual implementation of which is a manufacturing secret and changes for every new generation of cpu architecture. One of the first hallmark processor with this behavior was the Intel 486, available in 1989.

The efficiency of a machine code instruction is heavily affected by the instructions before it and the instructions after it. The details of which can no longer be overseen by a human. It requires a machine. The one that's next to you, executing the code generator stage of your compiler. Or on your customer's machine if you use a VM language with a just-in-time compiler. An execution model that can deal with subtle architectural differences between cores.

Answer 5

High level languages are not any faster than assembly languages. Good compilers translate HLL programs into fast sequences of machine instructions. Good assembly programmers do the same thing. The results are indistinguishable from a performance perspective.

High Level Languages are intended to make programming easier and faster, not to make programs faster.

Answer 6

The premise of your question is not necessarily true. Modern desktop CPUs are very complex and highly pipelined. Therefore, a CPU's performance characteristics may not be intuitive. The people who write compilers send a lot of time researching and implementing optimizations in the compiler back end specifically for the processor architecture.

Unless you know exactly what you're doing (which is almost never the case), a good, modern compiler will create highly optimized code without human intervention. The reason why one would write assembly directly is when the compiler fails to create the most optimal code, or as part of the kernel of an operating system.