Author: Robert Hyatt
Date: 08:04:42 11/09/99
Go up one level in this thread
On November 09, 1999 at 01:39:12, David Blackman wrote: >On November 08, 1999 at 21:54:00, Robert Hyatt wrote: > > >>There was a discussion on r.g.c.c a couple of years ago about this. There are >>two ways to write assembler code: >> >>(1) do a 'conversion' using current C code as a model. This is an inefficient >>way to get something decent. I generally see modest improvements here, as >>in the 50% faster or so type improvement... >> >>(2) study the architecture carefully, and design the program to fit the >>architecture as closely as possible. I have seen 5x speedups by doing this. >>But it is a _lot_ of work. And is 100% non-portable. I would be surprised >>if someone did this and didn't get at least 2x faster than pure C, and I would >>hope for more. >> >>Optimizers are very good. But they are _nowhere_ as good as a human that knows >>the program... and knows about things that the compiler can't determine at all. > > >I can believe this for the Cray vector machines, where it was quite tricky to >get the best out of the vector units, and the compiler writers didn't care about >chess, only H-bomb simulations and weather forecasting, which have different >kinds of loops. > >I can believe it for other computers that have weird instruction models at a low >level that don't map very well to high level languages. For instance if you >stare really hard at MMX, or at a 3D accelerated video card, you might spot how >to write a chess program that uses them a lot, and you will have to use >assembler to get the best results there. > >But for standard integer mode on normal chips such as Intel X86 and most risc >chips, i can't see how you would beat the compiler by a factor of two. Popular >high level languages map down to the instructions very well, and the best >compilers do an excellent job of register allocation, scheduling to avoid >pipeline stalls, etc. If you can say it in X86 assembler, you can nearly always >say it at least as clearly in C. Just look at the generated code. lots of procedure calls. Library functions. saving/restoring registers. Compiler doesn't know that this value will fit in a single byte, doesn't know that that value can never be negative. Doesn't know that those values can only be 0/1. There are _many_ things that can happen in a program... and there are no compiler semantics that can be used to let the compiler know...
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.