Author: Robert Hyatt
Date: 06:52:05 09/30/98
Go up one level in this thread
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. :)
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.