Author: Dave Gomboc
Date: 00:32:45 09/30/98
Go up one level in this thread
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
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.