Colin Kern wrote: > On Nov 21, 2007 3:36 PM, Petr Baudis <[EMAIL PROTECTED]> wrote: > >> On Wed, Nov 21, 2007 at 09:16:48PM +0100, Raymond Wold wrote: >> >>> On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote: >>> >>>> Experience in a language is a factor, but nobody refutes that properly >>>> coded C is fastest (next to properly code assembly) and if performance >>>> is your goal, then anything else accepts some compromise. That >>>> compromise may work well for a particular individual and may even >>>> produce a stronger program for them, but it's still a handicap. >>>> >>> Do you have anything to back this up? I was under the impression that >>> most decent assembly programmers agreed that they can't compete with the >>> best C compilers. Assembly is for when you *need* to be in touch with >>> the very lowest level, which in most cases you don't, because lots and >>> lots of other assembly programmers have been there before you and >>> distilled their knowledge into really really smart compilers that know >>> more, and can try out more, than you ever could in a lifetime. >>> >> I guess that you could say the original statement holds but humans >> generally can't properly code assembly anymore. ;-) >> >> > > What's to say that a computer program can't code assembly better than > any human possibly could? There are a ton of tasks that computers do > thousands of times better than humans. I think it makes perfect sense > that code written in C can execute faster than human-written assembly > code. > I hope you are right. I don't want to code in assembly.
But you are probably wrong because ansi C is platform portable and there are some things that might be done in assembler that cannot be naturally expressed in C. One example of this is an operation to find the leftmost or rightmost bit in a 32 or 64 bit word. Many processors have instructions for this, but there is no such instruction in C. Of course not all processors implement this efficiently, but we can assume that there might be some that do, or perhaps other instructions like this that ARE implemented efficiently with a single instruction in assembly, but require many in C. Of course you could argue that a super-clever C compiler may someday recognize what is going on and substitute the appropriate processor instruction for the C function. But that would take a truly amazing compiler that could do this in the general case. When that day comes, compilers may decide to completely reorganize your code, choosing more efficient algorithms! - Don > Colin > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
