Author: Eugene Nalimov
Date: 10:08:39 01/15/02
Go up one level in this thread
On January 15, 2002 at 04:27:46, Tom Kerrigan wrote: >On January 13, 2002 at 23:54:27, Eugene Nalimov 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? > >Right, sorry, I had misread the "on" as an "or." Anyway, if you (third person) >think switch statements are slow, there's nobody forcing you to use them... I don't think they are slow. I just pointed out why equivalent assembly instructions can be even faster. >>>>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. > >I'm not sure where this would come up. With the RISC instruction sets I can >remember, when you do loads of bytes, you can get sign extensions for free. Not true on IA-64, Alpha, PA-RISC, and PowerPC (sometimes some loads can be sign-extended, but not byte loads). On ARM signed loads are second-class instructions, i.e. there are less addressing modes and bits in the offest field available for them. >>>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. > >Yeah, but not in the cases where you would need code to be really fast. Unless >you're doing API calls or something, which is a bummer, but doesn't need to >happen in chess programs. Usually compilers still have some restrictions, i.e. sometimes they cannot use non-standard calling conventions even when all call sites for function is known. I am working on one of those compilers myself... >>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. > >I also think that what most people have been talking about--taking VC assembly >output and tweaking it so it's faster--is cheating. I mean, is it really >hand-coding when 90+% of your "hand code" comes from VC? And can you really say >you're better at assembly programming than VC when if you wrote the assembly in >a vacuum, it would be much slower than VC's output? > >-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.