0

I learned not long ago that most of the asm compilers were written in C or other languages, and we say assembler is the fastest language. But if it's coded in C, how can it be faster than the C itself? What does the compiler do then? Are there compilers of ASM in ASM? I do not really understand how it all works ... I searched on the internet, but I did not find clearly what I was looking for ... Would you have explained or given me any links that could help me better understand the concept of assemblies compilers?

  • 5
    Why does that matter? An an other analogy, if a person builds a car than that car is probably able to drive faster than the person can walk – harold Oct 21 '17 at 22:25
  • Assembly is the fastest language is not that true. Yes for simple things it is but optimizers are now really good and it's now almost impossible to do better by hand (and assembly is very difficult to write for complex things ...) – fievel Oct 21 '17 at 22:26
  • 1
    In other words, the speed of the assembler has exactly nothing to do with the speed of the program you write in assembler. You could assemble the code by hand given enough time, and the result would be just as fast as a machine assembled version. To expand on harold's analogy, if the exact same car is manufactured by robots or by humans only determines the time it takes to make the car, not the speed of the car. – Jester Oct 21 '17 at 22:27
  • So in other words, the language is not important, it's just the implementation that counts? –  Oct 21 '17 at 22:29
  • Both C and assembler programming languages produce native machine code for target CPU. So if you write in assembly the same code, as C compiler generates from C source (for particular problem, like sort), then you have the same machine code = same performance of sort function. But in assembly the programmer writes instructions almost 1:1 to native machine code, so you need smart programmer to produce good machine code, while in C you need both smart programmer and compiler to produce good code. Then there are interpreted/JIT languages, those can rarely match speed of native machine code. – Ped7g Oct 21 '17 at 22:40
  • You're confusing running the assembler with running the executable code that it produces. The assembler itself may be written in C, but that has nothing to do with how fast the code it produces runs. – Tom Karzes Oct 21 '17 at 22:41
  • And the speed of compilation (speed of compiler and assembler) doesn't matter that much (although slow compiler written in BASIC requiring minutes to compile single C file would probably drive the programmer crazy, even if it would produce high quality optimized machine code), compilation process doesn't affect runtime performance of resulting binary. Either way if you produce native machine code, you have machine code, whatever means you used to produce it. – Ped7g Oct 21 '17 at 22:46
  • The "speed" of language usually refers to the quality of compiler, i.e. how optimal the resulting machine code is, not to the performance of compilation itself. So for example a well written application in PHP will never have the same performance as well written C app, because PHP doesn't support native data types and the source is much more abstract and universal, so correct implementation of that requires more native machine code with all kind of generic data type handling/etc, while the C source can be lot more targetted to the platform, in favour of native strengths of platform. – Ped7g Oct 21 '17 at 22:51

1 Answers1

1

There are three concepts getting tossed around here:

  • Speed of a compiler
  • Speed of a processor
  • Speed of an executable

First, to get it out of the way, the time it takes to compile some executable has very little relationship to the time it takes for that executable to run. (The compiler can take longer to do some careful analysis and apply optimizations.)

The speed at which your processor can operate is another thing. Assembly language is the closest to machine language, which is what your processor understands. Any given instruction in machine language will operate at the speed that the machine processes that instruction.

Everything that executes on your processor must, by definition, be at some point converted to machine language so that your processor can understand and execute it.

That’s where things get tricky. An assembler will translate code you write directly to machine language, but there is more to a program than just knowing how to convert to machine language. Suppose you have a complex value, such as a collection of options. These options must be maintained as strings, integers, floats, etc. How are they stored? How are they accessed?

The way in which all this is done can vary. The way you organize your program can vary. These variations make a difference in executable time.

So you can write a very slow program using assembly language and a very fast program using an interpreted language. And, frankly, compilers are often better at organizing the final machine code than you are, even if you are using an assembler directly.


So to bring it to a point: the compiler’s job is to transform your textual source code (C, or assembly, or whatever) into machine code, which is what your processor understands. Once done, the compiler is no longer necessary.

There is significantly more to it than that, but that is the general idea.

Dúthomhas
  • 8,200
  • 2
  • 17
  • 39
  • Ok, thank you for your answers :) I guess it must be very complicated to create a good compiler ... –  Oct 21 '17 at 22:58
  • *Any given instruction in machine language will operate at the speed that the machine processes that instruction.* Even that's a simplification. Modern CPUs are context-sensitive, with caches and branch prediction affecting the throughput and latency of single instructions. Even non-memory and non-branch instructions can be affected by surrounding code, for example uop-cache or other front-end bottlenecks, etc. etc. And of course performance isn't one-dimensional. Every instruction has latency, front-end bandwidth requirement (in uops on x86), and which execution ports it needs. – Peter Cordes Oct 22 '17 at 03:36
  • 1
    @MinoTaure: You might be interested in [Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture?](https://stackoverflow.com/questions/40354978/why-is-this-c-code-faster-than-my-hand-written-assembly-for-testing-the-collat) for an in-depth look at poorly hand-written asm being slower than compiler-generated asm, vs. how to beat the compiler in that case with hand-written asm. Yes, modern compilers are extremely complex pieces of machinery, and they still don't make truly optimal code most of the time. – Peter Cordes Oct 22 '17 at 03:38
  • indeed, this post are interesting! Thanks again for your answer :) –  Oct 22 '17 at 08:54