Author: Komputer Korner
Date: 11:05:36 09/30/98
Go up one level in this thread
On September 30, 1998 at 09:52:05, Robert Hyatt wrote: >On September 30, 1998 at 03:32:45, Dave Gomboc wrote: > >>On September 29, 1998 at 11:13:24, Don Dailey wrote: >> >>>On September 29, 1998 at 00:57:32, Dave Gomboc wrote: >>> >>>>On September 28, 1998 at 14:12:25, Robert Hyatt wrote: >>>> >>>>>On September 28, 1998 at 10:06:42, Jon Dart wrote: >>>>> >>>>>> >>>>>>On September 28, 1998 at 09:17:09, Robert Hyatt wrote: >>>>>> >>>>>>>On September 28, 1998 at 03:01:19, Danniel Corbit wrote: >>>>>>> >>>>>>>>On September 27, 1998 at 18:18:25, Robert Hyatt wrote: >>>>>>>>[snip] >>>>>>>>>not exactly. IE I can't imagine that a C compiler + optimizer can beat >>>>>>>>>hand-tuned asm code, even if I write both the C and the asm code. The >>>>>>>>>guys that write the optimizers are good, but they aren't as good as >>>>>>>>>someone that has been programming asm code for 30 years... >>>>>>>>> >>>>>>>>>The main reason everyone doesn't use ASM code is portability, *not* >>>>>>>>>speed. >>>>>>>>Risc C compilers can almost always outdo hand written code except for very small >>>>>>>>snippets. For CISC I agree with you, especially Intel x86, since there are so >>>>>>>>many good Intel assembly programmers. For thousands or millions of lines of C, >>>>>>>>an equivalent ASM is very hard to produce for Risc machines. >>>>>>> >>>>>> >>>>>>The Intel processors now do many of the tricks that RISC processors have >>>>>>traditionally done. It used to be that you could just get the processor manual, >>>>>>add up the instruction times, and figure out how fast your code would run. >>>>>>Now that's not true anymore. So writing optimal assembly language is >>>>>>non-trivial, even for the Intel machines. (However, I would add that few >>>>>>compilers do a really great job of register allocation - which is quite a bit >>>>>>harder on Intel than other architectures - so that is one area where a human can >>>>>>improve on the compiler). >>>>>> >>>>>>--Jon >>>>> >>>>> >>>>>There are other things too. IE how many chess programmers do an x=x*2.5 in >>>>>their evaluation function? None? Better check out cray blitz. And the reason >>>>>is buried in the Cray architecture and how floating point stuff is done in >>>>>parallel with integer stuff, so that I can do x=x*2 and y=y*2.0 in the same >>>>>time it would take to do just x=x*2... but the compilers don't know whether >>>>>you can take a float and use it as an int, or vice-versa, while *I* do because >>>>>I know how the number will be used later, and where the important part of the >>>>>number is (whole or fraction or both). The compiler *always* has to be >>>>>conservative and once it has a float, it has to stick with a float to avoid >>>>>losing those fractional bits, even when they will be zero (but it can't know >>>>>that of course.) >>>>> >>>>>That's the point. I *know* *all* about the program and the values it is >>>>>computing. The compiler doesn't... >>>> >>>>I think that if somebody had enough time to write it all in assembly, they might >>>>do a better job than a top-notch compiler. That's a pretty big if though, it >>>>might take a lot longer than a human lifespan. Anyway, I think more often the >>>>compiler will be better. If I may make an analogy :), let's use computer chess. >>> >>>Actually, you are wrong here. Fritz is just one example of a carefully >>>coded machine program. I have talked to Franz and he understands all >>>the instruction scheduling issues for each processor he writes for. >>>And he specifically targets an individual platform, something that is >>>commonly available but near the cutting edge. That is why he rewrites >>>relatively frequently. >>> >>>I have written programs entirely in assembly too (but not the interface) >>>It is more tedious, but not more difficult (if that makes any sense.) >>>My impressions are that it really doesn't take much longer at all to >>>write code but debugging gets harder. This assumes you have already >>>developed some proficiency in assembler and have good tools. One other >>>issue is that c has libraries of routines already available but so can >>>assembly. Most of these libraries will not affect a chess program very >>>much but will affect the interface, which will be written in some high >>>level language if you are wise! >>> >>>The other issue of course is understanding instruction scheduling, >>>timing issues and caching issues. >>>With modern processors it gets harder to match a compilers ability >>>to do these things. But if you understand the issues well you can do >>>much better and it will not take even close to a lifetime. >>> >>>You would be surprised that something that seems so complicated is >>>not really once you break it down and learn to understand the issues. >>> >>>- Don >>> >>> >>>---- I snipped the rest ----- >> >>I didn't convey my thoughts clearly enough, I was not suggesting that >>implementing a chess program in assembly would take a lifetime. When I wrote >>the first statements I was thinking about the 5 million lines of C++ >>megaprojects out there. >> >>If the human assembler has so much more expertise than the machine assembler, >>instead of hand-coding the end software, perhaps the human assembler should be >>"educating" the machine assembler. >> >>Dave Gomboc > > > >The problem is that the 1/2 million lines of code in a good code >optimizer would become 500 million lines of code, with more bugs, more >mistakes, and would be unusable. It would be *very* difficult to make >an optimizer do what a good human can do. Yes, they can be more >thorough, once they do peephole optimizing, because they can shine that >"peephole" over millions of lines of code which would be tedious for a >human... but the human wouldn't do it for the entire code, only the 10% >that the human knew needs it. Hence we now have "profiling optimizers" >that run a program then figure out which parts are "hot spots" just like >humans do. But making an algorithm optimize like a human is quite a task. >I doubt I'll be "replaced" in my life-time. :) What about a chess compiler? Obviously you would need one for each platform.
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.