Weaker play with TT

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 25520
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Weaker play with TT

Post by hgm » Tue Jan 12, 2021 7:07 pm

Dann Corbit wrote:
Tue Jan 12, 2021 6:20 pm
Your approach is a good approach.
First make it correct, and only after it works correctly, you can make it faster.
In order to make it faster, you should always profile first.
After the profile you will have discovered the slow spots.
The best way to speed it up is to choose a better algorithm.

But early in development correctness is absolutely crucial.
If you try to make an incorrect program fast you will just get wrong answers quicker
But it is also true that doing things in a complex and cumbersome way, rather than simple and straightforward, is more likely to produce bugs, and thus requires more effort to 'first make it work correctly'. The current issue is actually a good example of that. There was a bug in the saving and restoring of the hash key. That bug could not have existed if the hash key would not have had to be saved and restored in the first place.

Incremental techniques are typically much more bug prone than straightforward calculation of the quantity you need. If they are also slower and less efficient it would not be very wise to bother with them just to be able to 'make it faster' later by abandoning them again.

User avatar
maksimKorzh
Posts: 525
Joined: Sat Sep 08, 2018 3:37 pm
Location: Ukraine
Full name: Maksim Korzh
Contact:

Re: Weaker play with TT

Post by maksimKorzh » Tue Jan 12, 2021 9:13 pm

hgm wrote:
Tue Jan 12, 2021 7:07 pm
Dann Corbit wrote:
Tue Jan 12, 2021 6:20 pm
Your approach is a good approach.
First make it correct, and only after it works correctly, you can make it faster.
In order to make it faster, you should always profile first.
After the profile you will have discovered the slow spots.
The best way to speed it up is to choose a better algorithm.

But early in development correctness is absolutely crucial.
If you try to make an incorrect program fast you will just get wrong answers quicker
But it is also true that doing things in a complex and cumbersome way, rather than simple and straightforward, is more likely to produce bugs, and thus requires more effort to 'first make it work correctly'. The current issue is actually a good example of that. There was a bug in the saving and restoring of the hash key. That bug could not have existed if the hash key would not have had to be saved and restored in the first place.

Incremental techniques are typically much more bug prone than straightforward calculation of the quantity you need. If they are also slower and less efficient it would not be very wise to bother with them just to be able to 'make it faster' later by abandoning them again.
Well, at the moment I'm happy to come up with at least bug free program. Latest fix made my program at least 150 Elo stronger so now it crushes TSCP - that's good enough for me for now.
JavaScript chess engine with UCI support, own GUI and public API:
https://github.com/maksimKorzh/wukongJS

Chess programming YouTube channel:
https://www.youtube.com/channel/UCB9-pr ... KKqDgXhsMQ

Post Reply