3 ms·

"Debating this fact would be the same as debating whether assembly is the most performant and reliable low-level language or not." Discounting special CPU feat

"Debating this fact would be the same as debating whether assembly is the most performant and reliable low-level language or not." Discounting special CPU features that are hard for compilers to utilize (e.g. AESNI instructions in newer Intel CPUs), I think this is really a matter of scale. For small functions like MD5, hand-tuned assembly language is probably going to be faster than what a compiler generates. Likewise, for short, tight loops that are the bottleneck, hand-tuned assembly may be faster (you see that sort of thing in game engines). Beyond a certain point, though, compilers are going to outperform even the best humans; compilers are just better at keeping track of things across large areas of code. Compilers are also going to do a lot better when they have higher-level information available. You could conceivably write an x86 assembly optimizing tool (I suspect someone will point one out) if you wanted to, but even the best such tool will lose to a good C compiler. At the very least, your C compiler knows something about types, which can help a lot with optimizing; your C compiler also gets information about the purpose of certain sequences of instructions and how various control structures relate to various types, in ways that are hard to extract from assembly language. Of course, this argument can be taken a step further: a good compiler for a high level language should be able to do even better than a good C compiler at a large enough scale. While it is conceivable that you could do anything in C that a high-level language compiler does automatically, that just brings us back to the issue of whether or not compilers can outperform humans -- and again, at a large enough scale, that is going to be the case (of course, comparisons are difficult; higher-level languages are used for things that C is rarely used for, and we could debate endlessly about why that is the case).

spc476 14y ago
SynthesisOS (http://valerieaurora.org/synthesis/SynthesisOS/ http://valerieaurora.org/synthesis/SynthesisOS/) used an optimizing assembler to recompile the operating system on the fly (think of it as the OS being JITed). The reason it had to use an optimizing assembler is because the operating system itself was written in assembler (MC68030). It could run SunOS binaries faster than SunOS on the same hardware. And this was done back in 1992, when the major debate was Assembler vs. C (back when C was considered "high level").

spc476 14y ago

SynthesisOS (http://valerieaurora.org/synthesis/SynthesisOS/ http://valerieaurora.org/synthesis/SynthesisOS/) used an optimizing assembler to recompile the operating system on the fly (think of it as the OS being JITed). The reason it had to use an optimizing assembler is because the operating system itself was written in assembler (MC68030). It could run SunOS binaries faster than SunOS on the same hardware. And this was done back in 1992, when the major debate was Assembler vs. C (back when C was considered "high level").