(1) Languages do not have speeds. I was under the impression that a given language feature could prevent optimizing compilers from being as aggressive as it could be. Then again, I don't know much on this subject, so I don't know, for example, what such a feature might be, and why it would be difficult to optimize.
>>5
You're not at a point where you should care about performance. Start by understanding how C translates to assembly, then you can start checking out compilers, interpreters, run-time systems, etc.
Protip: Optimization doesn't matter as much as you think. C code with only the most basic optimizations can still vastly outperform optimized Python (eg.: TCC).
>>14
If you have decided from the outset to use C instead of a higher level language, then you have decided to reject a lot of various resource management techniques and "safety features" that you get in those languages. Even in so called "unoptimised C" you have removed a lot of additional bookkeeping and I think it is absolutely fair to call this an optimisation, and in many cases a premature one.
C is always faster. If any other compiler was shown to be faster, people would switch to it in droves, for writing faster code.
This didn't happen, because all those "Faster than C" claims are bullshit.
>>13
While I too am skeptical about claims of 20x speed improvements, Siskind does make claims about being faster than C/Fortran in his research statement, so you could email him and ask for his benchmarks.
Name:
Anonymous2010-07-04 15:55
Extraordinary claims demand extraordinary evidence.
Stalin code claim is like claiming that in 30 years(~1980 modern C compilers), all programs have used a code path which is twenty times slower and optimizations never helped at all.
I would have believed if Stalin was writing optimized SSE4 assembly blocks, but its just plain old C code. My best guess is they use a shitty C program written in a hurry as straw-man for "hand-tuned C" and really optimized Scheme code for Stalin.
>>23
Christ sake, calm down it's not like the guy fucked your mother. Why is it that fucking C weenies lose all their shit when it comes to questions of performance. No, it's not likely that the program was 20x faster. Yes, it is likely that they guys C was not infact "hand tuned". Any reasonable man would have thought that.
Proposal
It has come to my attention that /prog/ is incapable of having any form of a serious conversation regarding questions of performance. I suggest that we no longer entertain these threads and suggest that henceforth we defer all such retarded nonsense to /pr/. Who is with me?
Name:
FrozenVoid2010-07-04 16:22
>>24
Its because without performance, there isn't any other reason to use C. Generic C code is just too buggy and high-maintenance.
If only the ability to optimize and tune code was proven inferior to some other language, C would be done.
__________________
Orbis terrarum delenda est
Name:
Anonymous2010-07-04 17:48
>>27 C code is just too buggy and high-maintenance.
You are just as wrong as most people that use it.
C does exactly what its supposed to do and does it good. The fault why C is "buggy" is actualy the cstdlib.
C is a systems language, it represents memory manipulation in a generic, abstract and portable way. C is like a portable assembler. And the only people who should use assembler are people who work on a very low level.