I will prove that anything written in a higher-level language will not be as fast as my implementation of it in C. I leave this challenge out to anyone to take.
Your point being? My implementation in x86 assembly will be faster than your C code. So what are you trying to say here? That the processor only accepts a certain instruction set and that it doesn't understand Python or LISP or C? Isn't that glaringly obvious? All your code is finally converted back to assembly, and speed of execution depends upon how much the compiler can assume. If the compiler knows how big a certain variable is, it'll allocate exactly that much memory for it. If it doesn't, it'll have to take some extra precautions, which'll ultimately make the equivalent assembly slower. The more information you provide to the compiler about how the processor will execute the program, the more optimized your code will be. It's as simple as that.
C is approximately the equivalent of "portable assembly code", so nobody is surprised. Assembly allows you to control individual registers on the CPU, C has slightly higher data types which ultimately map to registers and HLLs have abstract data types. The objective of a HLL is to minimize programmer time, while making sure that the computer execution time doesn't suffer too much.
A smart programmer wouldn't write everything in assembly and C. That is too painful. Instead, he'd write everything in a HLL, profile it and find the bottlenecks. Then he would make the code that's causing the program to bottleneck more explicit (closer to the processor). Ofcourse, there are some projects that are so CPU-intensive that every line of code is practically a bottleneck, and they have to be written in C and assembly. FFmpeg for example.
Slashdot Mirror
I will prove that anything written in a higher-level language will not be as fast as my implementation of it in C. I leave this challenge out to anyone to take.
Your point being? My implementation in x86 assembly will be faster than your C code. So what are you trying to say here? That the processor only accepts a certain instruction set and that it doesn't understand Python or LISP or C? Isn't that glaringly obvious? All your code is finally converted back to assembly, and speed of execution depends upon how much the compiler can assume. If the compiler knows how big a certain variable is, it'll allocate exactly that much memory for it. If it doesn't, it'll have to take some extra precautions, which'll ultimately make the equivalent assembly slower. The more information you provide to the compiler about how the processor will execute the program, the more optimized your code will be. It's as simple as that.
C is approximately the equivalent of "portable assembly code", so nobody is surprised. Assembly allows you to control individual registers on the CPU, C has slightly higher data types which ultimately map to registers and HLLs have abstract data types. The objective of a HLL is to minimize programmer time, while making sure that the computer execution time doesn't suffer too much.
A smart programmer wouldn't write everything in assembly and C. That is too painful. Instead, he'd write everything in a HLL, profile it and find the bottlenecks. Then he would make the code that's causing the program to bottleneck more explicit (closer to the processor). Ofcourse, there are some projects that are so CPU-intensive that every line of code is practically a bottleneck, and they have to be written in C and assembly. FFmpeg for example.