5 ms·

If you are new to programming languages, please don't listen to those non sense articles "X language faster than c" that comes from people that are religious ab

If you are new to programming languages, please don't listen to those non sense articles "X language faster than c" that comes from people that are religious about high level languages. If you have only a hammer, everything is a nail. It is a very dangerous meme that will make you incompetent in the real world when real life high level languages are >100 times slower that programs written in c(from people that know what the computer is doing as they knew assembler first). Microsoft geniuses fell on this meme and as a result created Windows Vista, and a 50KB file transfer could take you 20 minutes. In Android garbage collector will start collecting memory once it wished and will visually break the continuity of the screen, making it irresponsible at times. This is unacceptable for Apple that used c for this reason(yes c, not Obj c). Samsumg and HTC started using c too for this. C has this place, high level languages have their place. you trade abstraction for control and (if you know what you are doing) performance. Go and learn low level and high level and decide for yourself witch one is appropriate for what circumstance. E.g the fast python in python, things like numeric python, are written in c for this reason(once they discover how slow high level programming was in real life). If you are going to spend the same time optimizing language X on c, you can make c super fast as well, not 10% faster, with using c you should get 100%, 1000% or 10000%. Sorry, I feel super dumb by having to say the obvious, but good programmers are busy coding and the void is filled with non sense.

derleth 15y ago
You can say all the same things if you replace 'C' with 'assembly' and 'high-level languages' with 'C'.
- forgottenpaswrd 15y ago
  C is "portable assembler". If I do something like if (foo = bar) { } I know that the computer is comparing one value to another(witch means an op, eg.substraction ), then doing a jump. I don't need to code the assembler, but I could estimate how much it takes everything really well(orders of magnitude). This is invaluable with coding. If you do: [object foo] in objective c or object.foo() You lost all you control, sometimes classes will use iterative methods or alloc and free memory every time you call a method, from nested methods, making it super slow. Sometimes I want abstraction, sometimes I want to know what is happening.
  - Xurinos 15y ago
    This just isn't true. C is not portable assembler. It was never intended to be. I hear it claimed, and it is wrong every time somebody calls C a low-level language close to assembler. You can make some roughly reasonable assumptions about what comes out of the compiler, but often it is not what you think it is. Let's challenge this specific claim, that when you do "if (foo == bar)" -- I corrected the syntax error, which is a symptom of C's high-level syntax and not of the underlying assembly code -- you compare one value to another and then jump. For this challenge,I will write some trivial code that we should be able to make easy assumptions about, and I will compile it with debugging enabled so that I can dump the results with gdb. $ gcc -g example.c 1 #include <stdio.h> 2 3 int main() { 4 int foo = 10; 5 int bar = 20; 6 if (foo == bar) { 7 printf("Fun\n"); 8 } 9 return 0; 10 } Dump of assembler code for function main: 0x0000000100000ef8 <main+0>: push rbp 0x0000000100000ef9 <main+1>: mov rbp,rsp 0x0000000100000efc <main+4>: sub rsp,0x10 0x0000000100000f00 <main+8>: mov DWORD PTR [rbp-0x4],0xa 0x0000000100000f07 <main+15>: mov DWORD PTR [rbp-0x8],0x14 0x0000000100000f0e <main+22>: mov eax,DWORD PTR [rbp-0x4] 0x0000000100000f11 <main+25>: cmp eax,DWORD PTR [rbp-0x8] 0x0000000100000f14 <main+28>: jne 0x100000f22 <main+42> 0x0000000100000f16 <main+30>: lea rdi,[rip+0x19] # 0x100000f36 0x0000000100000f1d <main+37>: call 0x100000f30 <dyld_stub_puts> 0x0000000100000f22 <main+42>: mov eax,0x0 0x0000000100000f27 <main+47>: leave 0x0000000100000f28 <main+48>: ret We see that in the very basic version of this code with absolutely no optimizations and doing the silliest things that we can, we store our two values into some memory locations, perform a comparison (cmp), and jump if not equal. We can see that the jump leads us to the puts() call. Now, let's get smarter. The variables foo and bar do not change value, and we only work with two variables in the routine. Therefore, we could optimize by storing those values in temporary registers instead of using expensive memory transfers. Further,since our two constants are being compared and will always return a false, we actually have a section of code -- the printf -- that is dead code, that can be completely removed from final compilation. Well, that's simple, and everyone who uses C in production at least turns on some minor optimization: $ gcc -g -O1 example.c # the only difference is the -O1 Dump of assembler code for function main: 0x0000000100000f34 <main+0>: push rbp 0x0000000100000f35 <main+1>: mov rbp,rsp 0x0000000100000f38 <main+4>: mov eax,0x0 0x0000000100000f3d <main+9>: leave 0x0000000100000f3e <main+10>: ret This does not look like our C code at all! And thankfully so! What a waste of space and CPU time it would have been had we treated C like an interpreted language! C is a high-level language with numerous compiler implementations that can intelligently convert the human-readable code into the binary code that represents the real situation behind the code. The point here is that you are not properly guessing the assembler code that will be produced. The compiler is doing a better job of that; that is the compiler's job. As a programmer, you can just focus on the algorithm. C is not an assembler macro language. For that, you would use things like "gas".
jberryman 15y ago
To be honest, your comment strikes me as far more "religious" than the article, which (since you obviously didn't RTFA) documents optimizing a particular bit of haskell code to be on par with an equivalent implementation in C. The article is not saying that haskell (the language) is faster than C. If all you have is a hammer...
stcredzero 15y ago
when real life high level languages are >100 times slower that programs written in c(from people that know what the computer is doing as they knew assembler first) There is an important truth here, in the article, and in other comments here: Speed doesn't come free. You don't get the very best speed and efficiency by just using a certain language, a certain library, or a certain algorithm. It's essential that the programmer has some specialized knowledge. (How a particular GC works, how a particular library is put together, or exactly what your compiler is doing under the covers.) In the end, it's all a trade-off between hardware resources, human capital, and time. Have an excess of hardware resource? Then why not spring for GC? Have very tight and fixed hardware resource, well you're going to have to pay in another way!

derleth 15y ago

You can say all the same things if you replace 'C' with 'assembly' and 'high-level languages' with 'C'.

forgottenpaswrd 15y ago
C is "portable assembler". If I do something like if (foo = bar) { } I know that the computer is comparing one value to another(witch means an op, eg.substraction ), then doing a jump. I don't need to code the assembler, but I could estimate how much it takes everything really well(orders of magnitude). This is invaluable with coding. If you do: [object foo] in objective c or object.foo() You lost all you control, sometimes classes will use iterative methods or alloc and free memory every time you call a method, from nested methods, making it super slow. Sometimes I want abstraction, sometimes I want to know what is happening.
- Xurinos 15y ago
  This just isn't true. C is not portable assembler. It was never intended to be. I hear it claimed, and it is wrong every time somebody calls C a low-level language close to assembler. You can make some roughly reasonable assumptions about what comes out of the compiler, but often it is not what you think it is. Let's challenge this specific claim, that when you do "if (foo == bar)" -- I corrected the syntax error, which is a symptom of C's high-level syntax and not of the underlying assembly code -- you compare one value to another and then jump. For this challenge,I will write some trivial code that we should be able to make easy assumptions about, and I will compile it with debugging enabled so that I can dump the results with gdb. $ gcc -g example.c 1 #include <stdio.h> 2 3 int main() { 4 int foo = 10; 5 int bar = 20; 6 if (foo == bar) { 7 printf("Fun\n"); 8 } 9 return 0; 10 } Dump of assembler code for function main: 0x0000000100000ef8 <main+0>: push rbp 0x0000000100000ef9 <main+1>: mov rbp,rsp 0x0000000100000efc <main+4>: sub rsp,0x10 0x0000000100000f00 <main+8>: mov DWORD PTR [rbp-0x4],0xa 0x0000000100000f07 <main+15>: mov DWORD PTR [rbp-0x8],0x14 0x0000000100000f0e <main+22>: mov eax,DWORD PTR [rbp-0x4] 0x0000000100000f11 <main+25>: cmp eax,DWORD PTR [rbp-0x8] 0x0000000100000f14 <main+28>: jne 0x100000f22 <main+42> 0x0000000100000f16 <main+30>: lea rdi,[rip+0x19] # 0x100000f36 0x0000000100000f1d <main+37>: call 0x100000f30 <dyld_stub_puts> 0x0000000100000f22 <main+42>: mov eax,0x0 0x0000000100000f27 <main+47>: leave 0x0000000100000f28 <main+48>: ret We see that in the very basic version of this code with absolutely no optimizations and doing the silliest things that we can, we store our two values into some memory locations, perform a comparison (cmp), and jump if not equal. We can see that the jump leads us to the puts() call. Now, let's get smarter. The variables foo and bar do not change value, and we only work with two variables in the routine. Therefore, we could optimize by storing those values in temporary registers instead of using expensive memory transfers. Further,since our two constants are being compared and will always return a false, we actually have a section of code -- the printf -- that is dead code, that can be completely removed from final compilation. Well, that's simple, and everyone who uses C in production at least turns on some minor optimization: $ gcc -g -O1 example.c # the only difference is the -O1 Dump of assembler code for function main: 0x0000000100000f34 <main+0>: push rbp 0x0000000100000f35 <main+1>: mov rbp,rsp 0x0000000100000f38 <main+4>: mov eax,0x0 0x0000000100000f3d <main+9>: leave 0x0000000100000f3e <main+10>: ret This does not look like our C code at all! And thankfully so! What a waste of space and CPU time it would have been had we treated C like an interpreted language! C is a high-level language with numerous compiler implementations that can intelligently convert the human-readable code into the binary code that represents the real situation behind the code. The point here is that you are not properly guessing the assembler code that will be produced. The compiler is doing a better job of that; that is the compiler's job. As a programmer, you can just focus on the algorithm. C is not an assembler macro language. For that, you would use things like "gas".

jberryman 15y ago

To be honest, your comment strikes me as far more "religious" than the article, which (since you obviously didn't RTFA) documents optimizing a particular bit of haskell code to be on par with an equivalent implementation in C. The article is not saying that haskell (the language) is faster than C. If all you have is a hammer...

stcredzero 15y ago

when real life high level languages are >100 times slower that programs written in c(from people that know what the computer is doing as they knew assembler first) There is an important truth here, in the article, and in other comments here: Speed doesn't come free. You don't get the very best speed and efficiency by just using a certain language, a certain library, or a certain algorithm. It's essential that the programmer has some specialized knowledge. (How a particular GC works, how a particular library is put together, or exactly what your compiler is doing under the covers.) In the end, it's all a trade-off between hardware resources, human capital, and time. Have an excess of hardware resource? Then why not spring for GC? Have very tight and fixed hardware resource, well you're going to have to pay in another way!