Assemblers are obviously the most efficient, but compilers are good
enough these days (and processors complicated enough) that it's pretty
difficult to realize dramatic performance improvements writing
assembler by hand. The last time I did a serious major optimization in
assembler, I gained about 10% on the compiled code. However, there are
rare cases where SIMD instructions (which current-generation compilers
don't really use well) may yield two or 3x speed improvements.
C,C++, Fortran are all blindingly fast. Careful coding can usually
realize performance that is within 5 to 10% of hand-coded assembler.
Compile-on-demand languages like Java and C# are probably next on the
list. It's pretty common for code generated by these languages to run
2 or 3x slower. However, there are circumstances where these languages
run 10x or 20x slower (heavy array manipulation in C#, for example).
Interpreted languages like Python and Javascript run anywhere from 10x
to 300x slower depending on the problem at hand.
Functional languages: I'm not sure. I've never worked with a
functional languages that doesn't use an interpreter (and therefore
run 10x to 300x slower). In theory, functional languages can acheive
performance comparable to C, or C++ under limited circumstances. And,
in practice, if you were to try to write C or C++ programs that tried
to used functional programming approaches to problem solving,
functional languages would probably win. But don't expect to do real
time audio or graphics with a functional language.
In all cases, it really depends what kind of programming task you are
trying to solve. Assembler programming is pretty much a dead art. C or
C++ will handle almost anything. And Fortran is good for
high-performance scientific programming. But for most problems,
performance really isn't an issue. Computers are fast enough these
days that it's pretty difficult to max out a CPU.
Comparing different processors is like comparing apples and oranges.
Some have great memory systems, some have great floating point, some
have great super-scalar execution.
Interestingly, most performance problems on modern processors are
caused by memory subsystems, not CPUs. A good intel processor spends
most of its time waiting for memory accesses to complete. That's the
major reason why it's hard to improve on C or C++ code. If you write
the code to access memory in sensible patterns, you can usually
acheive equivalent performance whether the program is written in C++
or assembler. |
