Author: Larry Griffiths
Date: 18:02:38 01/21/01
Go up one level in this thread
On January 21, 2001 at 17:20:11, Paul wrote: >On January 21, 2001 at 12:30:21, Larry Griffiths wrote: > >>The optimizing capability of the BCB compiler sucks! My inline asm has extra >>NOP instructions that do not serve any purpose other than to slow my code down. >>BCB 5 has severe alignment problems when using __int64. It does not align them >>to quadwords so I have to do it by hand. MMX takes bad performance hits when >>the variables are not aligned on quadwords. This also applys to creating >>instances of classes. I created a seperate assembler module at one time that >>contained "Align" statements, but the ILINK32 seems to ignore these and aligns >>everything to doubleword boundrys. > >Hmmm ... I didn't know BCB had alignment problems. I use int64's for hashing. >Haven't noticed a big speed penalty for that, is it only a problem in >combination with MMX or is it more general if I understand you right? MMX instructions take performance hits when the data is not aligned on a quadword boundry. Using int64's without MMX should be ok. > >>I seem to get a lot better performance using the MMX instructions. MMX >>registers cannot be tested for values since they don't set conditions codes. I >>could increase performance if this was available. They also force the >>destinations to be a MMX register, so you have to load a register, perform an >>operation, then store it. This is also a performance hit. > >But in return you've got a lot more registers too play with right? But if >you can't test on conditions their use must be very limited? Just And/Or etc? Correct Paul. Their are 8 MMX registers. They are the floating point registers in another mode. An EMMS instruction must be done before doing any floating point and can take up to 50 clock cycles to execute. > >>I really liked the IBM 370 instruction set. It has 16 registers and was very >>logically designed. > >Right, that's what I like, not these incomprehensible Intel chips :) > >I think I'm not gonna study assembler any time soon. So no bitboards for me! >I do want to change my GNU style movegen to the 0x88 one soon. Only >don't like the fact that ao the history array gets a lot bigger that way. > >>I used to have a GUI in the previous version, but I re-wrote it to use >>full-blown bitboards so my old GUI is broken right now. I have created several >>classes in my program and interfaced to Winboard so I could play against other >>programs without having to use the mouse. > >Yeah, I'm in the process of making the GUI independent of the Engine. >That way I can load different engines into my GUI without problems. Makes it >easier to try out new ideas. > >I looked at the way TSCP communicates with WinBoard, and that's through the >use of printf/fgets on stdout/in, but am not sure if that works from a >GUI exe; will just have to try I guess, or do you know? I am using the VCL and communicating with Winboard at the same time. > >Paul
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.