Author: Matt Taylor
Date: 16:12:55 01/18/03
Go up one level in this thread
On January 18, 2003 at 15:57:08, David Rasmussen wrote: >On January 18, 2003 at 14:30:15, Matt Taylor wrote: > >> >>Perhaps they are generating inefficient code. I know MSVC 7 chokes big on 64-bit >>code. Multiply and divide go to library calls, and I think 64-bit shift does >>too. > >Mmm. That's weird. My bitboard-based program was as fast if not a little bit >faster with MSVC7 then with MSVC6. I can't believe it's library calls. VC 6 and VC 7 both implement complex 64-bit stuff with library calls. More primitive ops (add, subtract, compare) are handled inline as they ought to be. In the case of constant << count, the compiler -should- be able to generate good 64-bit emulation code inline. Back when I was first implementing the LSB scan functions, I compiled the 64-bit binary search algorithm using VC 7. There were several ways to implement a "round" of the search. VC 7 chose the worst way. I'm not terribly suprised, though. 64-bit computation isn't common, and the compiler likely has not been tuned to produce super 64-bit code. >>In that case, try the assembly I posted (noting the redundancy that Dieter >>pointed out in the gcc version). >> >>I truly find this sad if the compiler cannot make enough assumptions to generate >>decent code for 1ull << count. (Though I can sympathize with the >>compiler-writers a little bit.) > >I don't know, but I guess I should check it's generated code. > >/David Probably should. I'm betting they use a library call. If not, they may use a combination of shld (slow) and logical ops to accomplish the shift. The assembly I posted should be ideal for you as it avoids the table (even though the table is small) and runs just as fast. Downside is it doesn't run on old, old machines (like original Pentium/original K6). -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.