By the way, I am no fan of C. I don't like C and have tried some of the languages on your list of languages that are supposedly faster than C.
I think you must be getting your information from the web pages for those languages. As a general rule any reasonably fast language is going to claim to be faster than C but shame on you if you believe it. "In theory" all languages are equal. They can all be transformed to optimized machine code. I am not talking about the theoretical, I'm talking about the reality. And the reality is that right now C is the choice, whether I like it or not I accept it and hope something better will come along. - Don Don Dailey wrote: > Stefan, > > Yes, in special cases you can outperform C. > > I don't claim that it might not be possible with better compiler > technology to outperform C. I'm keeping my eye on D because it > promises to be one of those languages. > > But the truth of the matter, despite the promises, C is the best > performing compiler right now. I would feel silly trying to sit here > and convince you of this if you don't already know it. Look at any > objective benchmark. > > Fortran does outperform C in some code and is no slouch in general - > but it's still going to be slower than C in most things such as Chess > and Go programs. > > - Don > > > Stefan Nobis wrote: > >> Don Dailey <[EMAIL PROTECTED]> writes: >> >> >> >>> I thinks it's very difficult to outperform C since C really is just >>> about at the level of assembly language. >>> >>> >> No, in special cases it's not that hard to outperform C, because the >> language spec dictates some not so efficient details. C has an ABI and >> it's specification is optimized for the general case. Nearly every >> design decision has advantages and disadvantages. So if you look at >> the spec it's clearly possible to construct cases that are >> exceptionally bad for this specific spec. If you have a language >> without these restriction it's quite possible to get better results in >> this constructed case. >> >> So yes, it may be difficult and maybe most or even all cases in which >> it's possible to outperform C with Lisp are unimportant for any >> practical purposes, but nevertheless it's possible. >> >> And by the way I don't think C is really the best language for maximum >> performance. Just think about Fortran. AFAIK in it's main domain it >> easily outperforms C. There are also languages like OCAML, Ada, Forth >> and quite some others with really capable compilers und language specs >> that leave more freedom to compiler writers and such leave more room >> for different kind of optimizations. >> >> So the claim that C is the single one high level language with which >> you can get the maximum performance is quite an urban legend and >> completly unjustified. >> >> >> >>> I think the right approach to a language faster than C is to simply >>> write a better C that is specifically designed to have more >>> opportunities for optimization. >>> >>> >> C is a really crappy language, especially from the performace point of >> view. It's so low level that you are able to get really good >> performance despite all the odds of the language. You have to program >> around all the performace pitfalls, you have to do all performance >> optimizations yourself. C is no help here. So why should C be a good >> starting point for a language striving to make high performance >> computing easy? >> >> BTW: No, Lisp is also not a very good starting point for this special >> goal, but I would say Lisp would make a much better start than C, >> because Lisp shows you how much a good language and compiler can easy >> the pain for the developer while in C he is all alone. >> >> >> >>> I really don't think a truly higher level language will ever beat C >>> or a performance improved C. >>> >>> >> Have you really any hints, done any scientific benchmarks with >> languages like OCAML, Oz, Forth, Fortran, Ada, Scheme, and many others >> to make your claim any more than pure guesswork? >> >> >> >>> There is some hope that a JIT can do some optimizations not possible >>> with a static compiler - but even if this is the case C could follow >>> this path too. >>> >>> >> It's not easy and maybe not even possible for C to follow this route >> because C code (source and object) don't have very much >> information. Higher level languages provide much more information >> about what's going on, what data is in the game and the like. Or they >> set much more restrictions (like restrictive type systems). All these >> additional informations and/or restrictions make some algorithms >> for inference tractrable or even fast. Without these you are lost. So >> no, there are no hints that C would ever get such optimizations. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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/ > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
