Starting a new project - Rommie

[Mike Sherwin]

The pawns can wait a little while. I lowered the overclock on my R9-3950x to 4.0 GHz from 4.4x8/4.2x8 GHz because when I Use SF on all 32 threads the 12 fans in my system are very annoying. At 4.4GHz the result would be over 100 million n/s. When speedt() is debugged I'm hoping that someone will report results on a 12th gen INTEL or 5000 series AMD.

98,343,529 n/s
[fen]rnbqkbnr/8/8/8/8/8/8/RNBQKBNR w - - 0 1 [/fen]

[dangi12012]

I used this one in my ryzen system - and its dead silent even under full load!
Its specifically for ryzen and not some generic AIO.
https://www2.arctic.ac/liquidfreezer2/w ... LowRes.pdf

[Mike Sherwin]

I used this one in my ryzen system - and its dead silent even under full load!
Its specifically for ryzen and not some generic AIO.
https://www2.arctic.ac/liquidfreezer2/w ... LowRes.pdf

When I built my system I had a Liquid_Freezer_II on order from Amazon but it never arrived. Do you use intake filters or just leave it open for airflow? I use filters because it is very dusty here. Also my case lives in a cubby hole with only back and front open. I measured a 5c difference which certainly does not help.

[Mike Sherwin]

Kings are slow, only 34,378,000 n/s. Why are kings so slow? So if I extrapolate the true queen performance it would be roughly (q + 34) / 2 = 108, (q + 34) = 108 x 2, q = 108 x 2 - 34 = 182 million gen-make-unmake moves per second. Knights are n = 70 x 2 - 34 = 106 million m/s. The king and knight code is very similar. Something must be wrong with the king code?

EDIT: Solved. In my original test the kings were on e3 and e6 only two squares away from each other. Therefore they were dancing all around each other generating a lot of illegal moves that were not counted. Moving the kings farther away to g2 and b2 resulted in 106,733,100 n/s. Whew!

[Mike Sherwin]

I optimized Speedt(). This shows how much eliminating one poorly predicted branch can speed up the code.

Code: Select all

void Speedt(Thread* t, s32 depth) {
  uMove move;
  u64 fSquares, tSquares;
  GenMovesBB(t);
  fSquares = pieceSquareBits[stm];
  do {
    move.s.fs = std::countr_zero(fSquares);
    fSquares ^= 1ull << move.s.fs;
    tSquares = genbb[ply][move.s.fs];
    tSquares &= ~kings[1 - stm]; // added this line
    while (tSquares) {
      move.s.ts = std::countr_zero(tSquares);
      tSquares ^= 1ull << move.s.ts;
      // if (1ull << move.s.ts == kings[1 - stm]) continue;
      numberOfMoves++;
      MakeMove(t, &move);
      if (depth > 1) Speedt(t, depth - 1);
      TakeBack(t, &move);
    }
  } while (fSquares);
}

114,995,902 n/s vs before 109,209,822 n/s. That is almost 6 million n/s!
[fen]8/1q6/4k3/8/8/4K3/2Q5/8 w - - 0 1[/fen]

[Mike Sherwin]

Some optimizations made to classical Bob-Mike. Here is the newest rook getter. The nodes per second went from 111,384,578 to 117,813,538. The queen went from 109,209,822 to 120,756,722.

Code: Select all

	  sqNN = std::countr_zero(ray[fs].rayNN & occ);
	  rayNN = sqNN == 64 ? 0 : ray[sqNN].rayNN;
	  sqEE = std::countr_zero(ray[fs].rayEE & occ);
	  rayEE = sqEE == 64 ? 0 : ray[sqEE].rayEE;
	  sqSS = std::countl_zero(ray[fs].raySS & occ);
	  raySS = sqSS == 64 ? 0 : ray[sqSS].raySS;
	  sqWW = std::countl_zero(ray[fs].rayWW & occ);
	  rayWW = sqWW == 64 ? 0 : ray[sqWW].rayWW;
	  genbb[ply][fs] = rayNN | rayEE | raySS | rayWW;
	  genbb[ply][fs] ^= rob[fs]; // rook on board [fs]
	  atkbb[ply] |= genbb[ply][fs];
	  genbb[ply][fs] &= notMe;

Once the pawns are fixed the exe and source code will be uploaded to MediaFire. Then if anyone would like to replace the slider algo with another for comparison or try to make Classical Bob-Mike any faster it would be interesting and appreciated.

[Mike Sherwin]

104,385,606 nodes per second
[fen]rnbqkbnr/8/8/8/8/8/8/RNBQKBNR w - - 0 1[/fen]

[Mike Sherwin]

I promise that this will be my last post today. However tomorrow here is in 12 minutes.
Another optimization and:

104,385,606 n/s to 107,734,512 n/s
[fen]rnbqkbnr/8/8/8/8/8/8/RNBQKBNR w - - 0 1[/fen]

[Mike Sherwin]

I have the white pawns working. The black pawns are still baffling me. Anyway I'm very surprised at the white pawns performance!

119,133,688 n/s
[fen]4k3/8/8/8/8/8/PPPPPPPP/4K3 w - - 0 1[/fen]

[Mike Sherwin]

Ta-da, time for a scooby snack! // Not the Urban Dictionary type.

In the starting position the node rate is tampered down a bit because move generation is done on pieces that can't move. But I am still very happy with the node rate. Though probably there are some more optimizations to find.

After adding a couple of niceties and doing some cleanup I'll post the exe and source code to MediaFire.

98,656,565 n/s
[fen]rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1[/fen]