Author: Robert Hyatt
Date: 07:40:48 01/14/02
Go up one level in this thread
On January 13, 2002 at 23:54:27, Eugene Nalimov wrote: >On January 13, 2002 at 16:27:01, Tom Kerrigan wrote: > >>On January 13, 2002 at 10:22:52, Robert Hyatt wrote: >> >>>1. You know more about the program than the compiler. No bounds-checking >>>on "switch" type statements is necessary. >> >>What bounds checking or "switch type statements" are going on in a C program if >>you don't explicitly put them in? > > switch (x) { > case 0: > ... > case 1: > ... > case 2: > ... > } > >Good compiler will generate something like: > > if (x == 0) > ... > else if (x == 1) > ... > else if (x == 2) // That condition is not necessary > // if x can be only 0, 1, or 2 > ... > >In more general case, compiler have to generate even more complex check, i.e. > > if (((unsigned)(x-(lower value)) > (unsigned)(upper value - lower value)) > goto default; > >>>2. you know whether a value can be positive, negative, or both. The >>>compiler can't. >> >>Why does this matter? Just deal with 32 bits (or whatever your word size is) and >>call it good. > >On 64-bit system you can avoid sign extension if you know that the value is >non-negative. Sometime you can achieve similar effect in C casting the value to >the unsigned, but code becomes uglier than even assembly one. > >>>3. you know whether a value can exceed (say) 127 or not. The compiler can't. >> >>Again, why does this matter? > >Once again, to avoid ZXT/SXT. > >>>4. You know how many registers the CPU has and can design code around that, >>>while C doesn't give you such control. >> >>You can change the C until it produces the assembly that you want. > >That can be hard in the marginal cases. If your compiled program needs less >registers than target CPU have, than it easily can be at least not worse than >assembly program. If both your program and assembly program run out of >registers, usually there is no much speed difference, too. But in marginal case >you can see huge difference -- e.g. on x86 compiler was not able to fit >everything into 7 registers (it wanted 8, but there is no 8th register there, so >there are spills), but programmer was able to slightly rearrange the code and >still squeeze everything on 7 registers... > >>>5. you know exactly which registers procedure "x" will destroy, so you don't >>>have to save everything before calling it. If you are careful, you don't have >>>to save _anything_. >> >>The really strict calling conventions that you're thinking of here are no longer >>present in today's compilers. > >Here you are only partially right... There are still cases where compiler have >to honour standard calling conventions. > >And I can add > >6. Usually programmer knows much more about possible aliases in his program than >even the best compiler can find out. > >But Tom is partially right, too -- today's compilers are much better than ones >from 10 years ago. I am not talking about vectorizers, obviously major compiler >vendors started to look at them only recently, but for the control-heavy integer >code current compilers should produce reasonable code. > >Eugene > I never said they didn't produce "reasonable code". I simply said that no compiler can optimize as well as a good human... Otherwise the compiler would be _very large_ with the thousands of "special cases" that humans have learned about by experience... >>-Tom
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.