view release on metacpan or  search on metacpan

lib/Chess/Plisco/Engine/Win32Wrapper.pm  view on Meta::CPAN

	if ($params->{movestogo} && $params->{movestogo} < $mtg) {
		$mtg = $params->{movestogo};
	}

	my $time_left = $params->{mytime} + $params->{movestogo} * $params->{myinc};

	# FIXME! This should not be fixed_time but have a better name.
	# FIXME! Depending on the volatility of the position, there should be
	# a time cushion that can be used if the evaluation changes a lot between      
	# iterations.
	$tree->{allocated_time} = int (0.5 + $time_left / $mtg);
}

sub movesToGo {
	my ($self) = @_;

	# FIXME! These parameters should be configurable and their defaults
	# should be tuned!
	my $min_moves_remaining = 20;
	my $max_moves_remaining = 60;

lib/Chess/Plisco/Tutorial.pod  view on Meta::CPAN

At the end of the loop body, you clear the least significant bit of the
bitboard.  Therefore, the population count of the bitboard decreases by
one with each iteration.

If you want to benchmark both approaches, make sure to remove the expensive
operations inside the loop body, that is the call to C<cp_shift_to_square()>
and especially the print to the console.

What you will find out is that the second approach runs around 10-15 %
faster than the conventional approach.  On the one hand you have less
iterations (8 vs. 64) but masking out the bits and especially counting the
trailing zero bits outweighs that mostly.

But if you replace "pawn" with "king" in the code, the 2nd variation runs
around 700 % or seven times faster than the conventional approach.  This is
because you always have exactly one loop iteration instead of 64.  And in
the case of kings you could improve that even further by taking advantage of
the fact that there is always exactly one white king on the board.  So you
do not even need a loop.

Most of the time, the bitboards you are dealing with are sparsely populated