How many asm-instructions per C-instruction?

I realize that this question is impossible to answer absolutely, but I'm only after ballpark figures:

Given a reasonably sized C-program (thousands of lines of code), on average, how many ASM-instructions would be generated. In other words, what's a realistic C-to-ASM instruction ratio? Feel free to make assumptions, such as 'with current x86 architectures'.

I tried to Google about this, but I couldn't find anything.

__Addendum__: noticing how much confusion this question brought, I feel some need for an explanation: What I wanted to know by this answer, is to know, in practical terms, what "3GHz" means. I am fully aware of that the throughput per Herz varies tremendously depending on the architecture, your hardware, caches, bus speeds, and the position of the moon.

I am not after a precise and scientific answer, but rather an empirical answer that could be put into fathomable scales.

This isn't a trivial answer to place (as I became to notice), and this was my best effort at it. I know that the amount of resulting lines of ASM per lines of C varies depending on what you are doing. `i++` is not in the same neighborhood as `sqrt(23.1)` - I know this. Additionally, no matter what ASM I get out of the C, the ASM is interpreted into various sets of microcode within the processor, which, again, depends on whether you are running AMD, Intel or something else, and their respective generations. I'm aware of this aswell.

The ballpark answers I've got so far are what I have been after: A project large enough averages at about 2 lines of x86 ASM per 1 line of ANSI-C. Today's processors probably would average at about one ASM command per clock cycle, once the pipelines are filled, and given a sample big enough.

That varies tremendously! I woudn't believe anyone if they tried to offer a rough conversion.

Statements like `i++;` can translate to a single `INC AX`.

Statements for function calls containing many parameters can be dozens of instructions as the stack is setup for the call.

Then add in there the compiler optimization that will assemble your code in a manner different than you wrote it thus eliminating instructions.

Also some instructions run better on machine word boundaries so `NOP`s will be peppered throughout your code.

I am not sure there is really a useful answer to this. For sure you will have to pick the architecture (as you suggested).

What I would do: Take a reasonable sized C program. Give gcc the "-S" option and check yourself. It will generate the assembler source code and you can calculate the ratio for that program yourself.

There is no answer possible. statements like `int a;` might require zero asm lines. while statements like `a = call_is_inlined();` might require 20+ asm lines.

You can see yourself by compiling a c program, and then starting `objdump -Sd ./a.out` . It will display asm and C code intermixed, so you can see how many asm lines are generated for one C line. Example:

*test.c*

int get_int(int c);
int main(void) {
int a = 1, b = 2;
return getCode(a) + b;
}

$ `gcc -c -g test.c`

$ `objdump -Sd ./test.o`

00000000 <main>:
int get_int(int c);
int main(void) { /* here, the prologue creates the frame for main */
0: 8d 4c 24 04 lea 0x4(%esp),%ecx
4: 83 e4 f0 and $0xfffffff0,%esp
7: ff 71 fc pushl -0x4(%ecx)
a: 55 push %ebp
b: 89 e5 mov %esp,%ebp
d: 51 push %ecx
e: 83 ec 14 sub $0x14,%esp
int a = 1, b = 2; /* setting up space for locals */
11: c7 45 f4 01 00 00 00 movl $0x1,-0xc(%ebp)
18: c7 45 f8 02 00 00 00 movl $0x2,-0x8(%ebp)
return getCode(a) + b;
1f: 8b 45 f4 mov -0xc(%ebp),%eax
22: 89 04 24 mov %eax,(%esp)
25: e8 fc ff ff ff call 26 <main+0x26>
2a: 03 45 f8 add -0x8(%ebp),%eax
} /* the epilogue runs, returning to the previous frame */
2d: 83 c4 14 add $0x14,%esp
30: 59 pop %ecx
31: 5d pop %ebp
32: 8d 61 fc lea -0x4(%ecx),%esp
35: c3 ret

I'm not sure what you mean by "C-instruction", maybe statement or line? Of course this will vary greatly due to a number of factors but after looking at a few sample programs of my own, many of them are close to the 2-1 mark (2 assembly instructions per LOC), I don't know what this means or how it might be useful.

You can figure this out yourself for any particular program and implementation combination by asking the compiler to generate only the assembly (`gcc -S` for example) or by using a disassembler on an already compiled executable (but you would need the source code to compare it to anyway).

**Edit**

Just to expand on this based on your clarification of what you are trying to accomplish (understanding how many lines of code a modern processor can execute in a second):

While a modern processor may run at 3 billion cycles per second that doesn't mean that it can execute 3 billion instructions per second. Here are some things to consider:

- Many instructions take multiple cycles to execute (division or floating point operations can take dozens of cycles to execute).
- Most programs spend the vast majority of their time waiting for things like memory accesses, disk accesses, etc.
- Many other factors including OS overhead (scheduling, system calls, etc.) are also limiting factors.

But in general yes, processors are incredibly fast and can accomplish amazing things in a short period of time.

Depending on your environment you could use the visual studio option : /FAs

more [here][1]


[1]:

[To see links please register here]