Author: Tord Romstad
Date: 07:58:29 01/09/04
Go up one level in this thread
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
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.