On Thu, May 2, 2013 at 7:25 AM, Sasha Pachev <[email protected]> wrote: > OK, the gauntlet has been thrown.
> Levi, beat this in Haskell. Barry, Dale, beat this in Java. Anybody > else, beat this in your language of choice including C - I do not > claim that my implementation is the best. Post your development time. > If you think the rules are not fair, feel free to protest. Way to completely miss my point and waste a bunch of time writing a pointless program. I have lots of more interesting things to do than to write a contrived benchmark program to satisfy whatever offense you took at my criticism of C. If you'd spent a fraction of the time trying to understand what I wrote instead of taking offense and running off to prove me wrong, maybe you'd realize you're only reinforcing my point with this silly reaction. Let me say it again, perhaps more clearly. Yes, C can be very fast for many programs, because it forces you to deal in the low-level details. Sometimes the low level details like data representation are important, sometimes they're not. But the high level details are not captured by the language, they must be manually encoded by the programmer into it. And the boundaries at which you can no longer specify higher-level abstractions and at which you can no longer specify lower-level details define the scope in which the compiler can further optimize your code. C++ moves one of those boundaries, the one at the top-end of the abstraction level, but refuses to move the other. It turns out that refusing to let the compiler take over low-level details means that the programmer must manually optimize some things the compiler might otherwise have done, and this can certainly be done and produce very fast code, but it takes effort and expertise on the part of the original programmer and maintenance programmers. As an example, Fortran is still widely used in the scientific computing realm. This is because Fortran has array data types that are higher-level than C's and don't allow for arbitrary aliasing like C's barely-there arrays do. As a result, Fortran compilers knew more about what programmers meant when they programmed with arrays than C compilers could know about what C programmers were doing with C arrays and pointers. Thus, they could perform more and better optimizations. This made Fortran the default choice for matrix programming, and so a lot of research was put into developing good compilers, and for a long time they soundly trounced C compilers. The C powers that be eventually got around to defining standard ways to declare that data would not be aliased, but that's a low-level detail that a C programmer has got to keep track of and take care not to accidentally violate if they want to have a program that is both fast and correct. C compilers have since pretty much caught up to Fortran, at least when you write programs with the correct annotations, but a scientist who is not a C language expert who writes the same matrix-based program in C and Fortran may very well find the Fortran one runs faster. When you're dealing with higher-level languages, the programmer is freed of a lot of the burden of writing and maintaining low-level code. This typically has a performance penalty associated with it, but for many classes of programs it is small and is well worth the decreased development and maintenance cost over the lifetime of the program. The compiler isn't going to beat hand-tuned C in the general case, but C doesn't beat hand-tuned assembly code in the general case either. What sophisticated high-level language compilers do allow is for development effort to be spent in optimizations where it matters, and in some cases for higher-level optimizations that would have to be manually applied to C programs to be described to the compiler and then automatically applied when they are applicable. This may not result in benchmark programs that are faster than hand-tuned C programs, but it can result in programs that are moved from a very high-level specification down to "fast as un-tuned C" execution speed automatically by the compiler. Don't worry; even though C is a terrible language, it's not going to go away anytime soon. In fact, a new C standard was recently published, and MISRA has released a new set of guidelines to help people avoid the innumerable pitfalls that C provides to unwary programmers. This will all keep the black-hat hacker underground and the computer security field well employed, too. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
