Author: Robert Hyatt
Date: 21:58:30 12/25/02
Go up one level in this thread
On December 24, 2002 at 22:13:35, Matt Taylor wrote: >On December 24, 2002 at 20:33:34, Gerd Isenberg wrote: > >>On December 23, 2002 at 21:33:50, Matt Taylor wrote: >> >>>On December 23, 2002 at 21:29:08, Arshad F. Syed wrote: >>> >>>>Is there anyone here who has actually converted their C code to C++ while >>>>keeping the NPS the same or even managed to improve upon it? Sune did mention >>>>that he did so only at the cost of 15% degradation in speed. Why do people even >>>>bother wasting their time with C++ for a chess program when it inevitably leads >>>>to taking a hit in NPS? Regardless, of all the advice to simply inline the >>>>functions, I have yet to see a living example of chess program code which >>>>performed faster in C++. >>>> >>>>Regards, >>>>Arshad >>> >>>The biggest hit you take in C++ is virtual functions, and inevitably people use >>>them. The virtual functions are very damaging due to the fact that they're >>>implemented with a function pointer, and at the machine level it translates into >>>an indirect call. The indirect calls branch mispredict because the CPU can't >>>figure out ahead-of-time where you're calling to, and branch mispredicts are >>>expensive. >> >>Hi Matt, >> >>really? The vtable index of a virtual function is a compile time constant. >>Is an indirect call via register a mispredicted branch per se, even if the >>register was loaded with this->vptr->someVfunctionPointer an appropriate time >>before the indirect call occurs? What branch could be executed, other than the >>determined indirect call? > >I spent a while perusing the Athlon optimization manual, and I don't see >anything about that. Even in the Xeon optimization manual, it says little about >this. I do recall reading it somewhere, but I have no idea where now. > >The one thing that the Xeon manual mentions is that, in static prediction, >indirect branches are predicted as not taken. From my understanding of how >dynamic branch prediction works, you would take the penalty once for each time >you made the call. E.g. the following will eat 2 penalties: I am hoping you are mis-interpreting this. I don't believe there is _any_ "prediction" on an unconditional branch. I believe that is referring to a conditional branch to an address that is in a register... It makes no sense to even update the BTB for unconditional branches since there is nothing to predict. It _is_ going to branch. > >; Note esi is preserved across the call. I'm going to assume that ecx is, too. >mov esi, [ecx->SomeFunction] >call esi >call esi > >The dynamic prediction mechanism stores the -address- that you branch to, so if >this were the body of a loop, you would eat the penalty twice, and every other >prediction (assuming it didn't get wiped from the BTB) would pick correctly >assuming you were calling to the same place. If you were to, say, cycle through >an unsorted list of pieces and call a function for move generation, you would be >eating major penalties because it would mispredict almost every time. > >The major problem with indirect branches is easily seen in the code sample >there. Static prediction -can't- guess where it's going to go because it needs >to know about the contents of esi at the front of the pipeline. It won't know >where to continue executing until the u-op that assigns to esi retires. There I agree. But once esi is set, there is no prediction of any kind to handle... since this is an unconditional branch (or call, same thing). > >The alternative of switch/case will at -least- prefetch the correct code if it's >small, and it has a chance of getting the prediction right. > >>>Unfortunately, not using virtual functions (mostly) defeats the benefits you >>>would get from OO here. >>> >>>If you convert to C++ without using virtual functions, you probably won't take >>>much of a hit at all. Personally, I've never seen a -need- to convert to C++. I >>>can implement my OO in C, and it simplifies linking because C doesn't have name >>>mangling. >> >>But polymorphism is nice to have, even without virtual functions. >>I don't believe that name mangling affects the linker a lot ;-) >> >>Regards, >>Gerd > >It's not a problem until you want to mix in some assembly or link to someone's C >code or use code written in some other language. Then the >"?#@#$%@$@#2#@@#$FunctionXYZ" names become very obnoxious. > >-Matt
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.