(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.
>>43
I just spent 2 hours finding why my script stopped with Wrapped Native exception and rewriting it several times.
apparently you can't alias functions at all. Here example of this 'sanity'
id=document.getElementById;<--this should work..in theory
function c(a){return id(a)};<-- this is a normal function call
alert(c('code')) <--fails. Firefox errors anytime you try this.
Name:
FrozenVoid2010-07-05 7:46
>>44
use this instead:
function id(x){return document.getElementById(x)}
>>48
Overall, a pretty crappy question on >>38's part.
Name:
Anonymous2010-07-05 10:47
It's always a tradeoff between safety, speed, flexibility/ease of use.
The higher level you go, you lose some control regarding low-level optimizations. The fastest ``language'' would be writing everything in your platform's assembler. It should only be done when you know something is a major bottleneck and rewriting it will give you a major performacne increase (examine the disassembly of the code your compiler generated). Going higher level than assembly, you have C, which is basically portably assembly - you still have to manage memory yourself, but the compiler performs register allocation for you, and it can be portable, if you don't abuse too many platform-specific features. Neither asm or C are very safe, they're as safe as you make them be - if you understand how to write secure code, they both can be safe. If you go higher than C, you get the usual high-level languages like: C#, Java, C++, Haskell, Common Lisp, Scheme, Erlang, Javascript, ML, O'Caml, Smalltalk, Python, Perl, PHP, Ruby and so on. Each of those high-level languages have certain properties which when implemented can give them certain performance and safety characteristics. Most real general-purpose languages let you link to native code which can be written in C or Asm or other languages for performance or interoperability reasons. They may even allow callbacks or they can embed or allow themselves to be emebedded in code written in other languages. When it comes to those performance/safety characteristics, languages which are statically typed (the types are known at compile-time) tend to be faster as the data is usually kept unboxed (in C, arrays are just buffers or data, integers are unboxed, and so on), while dynamically typed languages don't type their variables, instead the data itself is typed, which means that in a properly dynamicly typed language(like Common Lisp or Scheme), most data has some tag bits of sort from which you can determine the type, and not only that: you could completly walk the entire data structure (in a debugger for example) and be able to completly see all the referenced data (this is possible in statically typed languages as well, but you would require all the debug info and a damn good debugger). There's also another extreme of statically typed languages which infer the types for you, so you don't have to declare them(like in C), languages like Haskell, ML, O'Caml belong in this category. Such languages trade some flexibility for safety and in the case of a good compiler, they can give you extra speed as well. Type inference assures that your program is well-typed, so it catches typing errors at compile-time. Type inference is possible in dynamically typed languages as well (for example a Common Lisp compiler can infer types to some degree), but such languages tend to be designed to have functions which can take very wide variety of types as parameters, so such kinds of type inference as more limited than the ML ones (in ML, the language is constricted in ways that make full type inference possible, while in most Lisps, user flexibility is more important than the possibility to have full type inference). Keep in mind safety is not compromised in such languages, just that type-checks are performed at runtime (unless you decide to compile in an unsafe mode which omits typechecks at runtime(or the compiler infers the type and omits the checks itself, or the user specifies the type manually in a type declaration), at the risk of crashes if the code is not properly written). In another side of the spectrum, you have dynamically typed languages with autoconversion like PHP and Perl, which think that there's no such thing as true errors and will attempt to munge the input to make sense, even if it's erroneus - such languages are also hard to compile to native code and tend to be interpreted, they are not safe languages, but the usual outcode from the lack of safety is people being able to exploit the vulnerable code (see all those owned servers that run PHP applications).
My personal choice here is to pick the most flexible high-level language which I could find, with good speed characteristics, with good implementations and good metaprogramming support. For me it was Common Lisp, but if Lisp is not for you, and you want some imperative C-like language, you could try D or C#. My applications are usually reasonably fast, I can easily profile, debug and disassemble the generated code in my implementation, and when I locate the bottlenecks I first eliminate any algorithmical errors (reducing complexity) and if that is not enough, I can help the compiler generate better code with some declarations. In the case it's something very speed sensitive, I can just write that part in C in the first place or write it in ASM if the C compiler can't do a good job (think matrix multiplications, vector transforms and things which are handled well by SIMD instructions in modern CPUs). Most C and Common Lisp implementations that I know of allow you to embed asm inline or via the linker or FFI.
So OP, learn languages on all sides of the spectrum with difference performance and flexibility characteristics and use the ones the job require, switch tools when needed and mix code from different languages, maybe even make your own mini-compilers to generate code for you(this is a lot of fun to do in Lisps as you can skip all the syntax lexer/parser junk and get straight to code generation!).
the tl;dr being:
Use high-level languages for most of the code, preferably a high-level language which gives you lots of flexibility and has good (a) implementation(s). Profile it, examine compiler output (disassembly), write critical parts in C or Assembly (inline or just link it somehow) if just optimizing the algorithm or compiler hints (in the high level language) are not enough. This way you can get the best of both worlds.