Author: Bob Durrett
Date: 08:35:29 01/09/04
Go up one level in this thread
On January 09, 2004 at 10:58:29, Tord Romstad wrote: >On January 09, 2004 at 10:17:32, Ricardo Gibert wrote: > >>On January 09, 2004 at 08:34:05, Tord Romstad wrote: >> >>>On January 09, 2004 at 08:14:05, Ricardo Gibert wrote: >>> >>>>If the if-test is seldom executed or the if-test is predictable, why should you >>>>optimize it? Use a profiler to determine what "needs" optimizing. Even then, >>>>think twice before you mangle the readability of your code. >>> >>>I'm quite well aware of all of this. If you browse the archives, you will >>>probably find that there are few programmers here who warn about premature >>>opitimization more often than I. :-) >>> >>>Have a look at this message for the most recent example: >>> >>>http://www.talkchess.com/forums/1/message.html?340567 >>> >>>However, in the present case readability is not a major concern for me. >>>One of my plans for the not very distant future is to throw away my >>>current evaluation function entirely, and design some sort of high-level >>>language for defining the evaluation function. I will then write a Lisp >>>program to transform this evaluation function to C code. If this works >>>as well as I hope, I will never again have to read or write a single line >>>of C code in my evaluation function, and I am free to choose the low-level >>>constructs which give the fastest code, without worrying about readability. >> >>This won't work as you hope. As CPU's evolve, which tricks are effective and >>which tricks are not will change. This means you will have to revisit your >>difficult to read C code again. > >No, it doesn't. It means that I must modify my transformation rules, >which is a less time-consuming and much more interesting task than >rewriting big chunks of C code. > >>Forced to read what you wrote before, you will >>wonder why you thought you could get away with it. >> >>It would be better to write the Lisp-to-C translations in a straightforward and >>easy to read way and depend on the C compiler writers to do their job well. > >Yes, this could perhaps be natural as a first step. When I have >finished this step, I can try out various modifications in my code >generator and see if they improve the performance. > >>Writing C code in a straightforward way will give the C compiler a better chance >>at recognizing an opportunity to optimize. > >To a certain sense, this is correct. But there is no reason to have >readability of the code as a main goal. Have you ever tried the >Scheme-to-C translator called Stalin? It produces the most bizarre, >unreadable and alien-looking C code I have ever seen. When looking at >the C translation of a moderately complicated Scheme program, it is hard >to see any resemblance at all with the original program. However, when >compiled, the C code is extremely efficient. I haven't experimented >much with Stalin myself, but reportedly the performance is often better >than for manually written C code. This surprises many people, but it >shouldn't. It is no more strange than the fact that it is difficult >for human assembly language programmers to outperform modern C compilers. > >But you are still right, the idea is to let the C compiler take care of >most of the low-level optimization, while my hypothetical C code generator >performs higher-level optimizations which the C compiler cannot possibly do, >simply because it has no knowledge about what tasks the program is trying >to do on a higher level. > >Tord I hope you realize what you are doing! You are taking the first steps toward the replacement of human programmers with silicon programmers! Before long, there will be no need for humans at all and, as presented in a Science Fiction story I once read, silicon beings will eventually realize that the carbon-based units are a nuisance and will get rid of them. All this will be your fault! : ) Bob D.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.