The same facts of the invalidity of benchmarks continue to surface, and it's well understood that they can be misleading - but for me the very simple truth is straightforward. I have tried many different languages and in every case so far it has not turned out "unclear", C has always won.
So yes, it's possible to draw the wrong conclusions and yes benchmarks will always have flaws in them, and yes it's more important to optimize the algorithm and yes certain optimizations work better on some CPU's than others and ... so on and so on. This is all true. But I have found so far that the performance advantage of C is so overwhelming that my first unoptimized attempt in C produces a faster program than in other languages. Stefan has said that C is a lousy performance language and that it's only fast if you go to great lengths to make it so. That is completely contrary to my own experience. One of the reasons I do performance coding in C is that I can produce faster code on my first try than I can with any other language. Again, contrary to what Stefan thinks, I have found that if you want fast code in any language you have to work at it and that usually means you have to "ugly it up" a little. I haven't seen that any language is immune to that. One thing is really clear to me. I will spend less time writing C code (without worrying too much about optimizations) that I will spending an enormous time trying to make one of these "ideal" languages run almost as fast. Yes, in theory there may be a couple of languages that have potential to beat C. But that is no good to me now. When theory becomes reality I will be the first to change over. As has been mentioned before, the amount of effort gone into C compiler technology is probably responsible for this. I seriously doubt any other language has had so much effort devoted to squeezing so much from them. If that had been the case then C probably would be a close second or third in speed. There is also something else to keep in mind. There is not even a discussion when it comes to the vast majority of languages because we are talking 5-100 X slower than C in most cases. A language starts to get interesting when it is within 2X factor of C. In which case it is usually almost as fast as C if you turn all optimizations off for C and all optimization on for the other language. I'm not a C enthusiast, I wish it were different. I don't like C. I continue to look for it's replacement. - Don Stefan Nobis wrote: > Isaac Gouy <[EMAIL PROTECTED]> writes: > > >> Again, you seem happy to say they are overrated and dismiss them >> without actually having looked - that is not "scientific"! >> > > Yes, my critique is not up to the standards I measure the shootout > with. But my main point is: Performance has so many (sometimes hard to > recognize) parameters that's really easy to draw false conclusions > From some benchmark data. > > If you are interested for the best performance for you task > at hand, you have to do benchmarks within your execution environment > and you have to construct benachmarks that really resemble your > task. Different OS, different CPU, even different cache sizes, > different alogrithms and so on. All these things really matter and if > you change any of these parameters the whole picture may change (on OS > A, CPU B compiler S for language X may be produce code that executes > faster for a benchmark than the code that is produced by compiler T > for language Y on the same system, but on CPU C the combination T/Y > may be better). > > One extra problem: As far as I can see you only compare freely > available language implementations (and this point is overssen by many > people -- I'm a big open source fan, but more often than not there is > one or more commercial language implementation that produce better > results than any of the freely available implementations). > > These games are funny and sometimes it's even possible to come to > helpful conclusions given the data. But many people I talked with > understand these shootouts as hard facts, they assume language X is > always better than language Y and don't take into account for example > that they are developing for a Sparc cluster while using benchmarks > for Intel/AMD. > > OK, so I would say I don't really have any problems with the shootout > but with the perception of these shootouts by many people. And that's > why I dislike these shootouts in general. > > > ------------------------------------------------------------------------ > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
