Vibe Coding

[BertTuyt]

Michel, interesting result.
So KR is still (around) 29 ELO better compared with Dragon 4.8
The Dragon 5.0 - 4.8 match revealed a result of ELO = 49, but with increasing time (like 1 min/game) this will become smaller.
So curious what KR - Dragon 5.0 will bring.

In all tests done, I was never able to surpass KR with many points, or with a large ELO margin.
The last time that we have seen a jump in playing strength was in 2015 with Scan from Fabien.

Sometimes Damage has a a 1 win and 157 draws, and the other time 2 losses and 1 win, and 155 draws (all perspective Damage).
So most likely break even.
Or too close to call with 158 games.

This tend me to believe that we have reached the maximum, but I hope some engines (like Dragon) prove the opposite.

Bert

[Joost Buijs]

I don't think any significant improvement is possible because this game contains too many mechanisms that lead to draws.

Kingsrow loses at most about 1% of its one-minute-per-move games when running on a single thread. It might be possible to gain another 5 Elo or so, but that's really the limit.

Playing matches from unbalanced starting positions is just a stopgap measure; it doesn't solve the underlying problem. The only real solution is to change the rules of the game so that it becomes less draw-prone.

Naturally, the draughts community has no appetite for such a radical solution as changing the rules of the game, so that's the end of the story.

[orac81]

Derek Oldbury always advocated the "spot behind the last man" rule used in 8x8 pool draughts, a fair number of players used this rule. The rule is you must land immediately behind the last piece in a capture sequence, I understand it forces more wins.

[BertTuyt]

I think it is called Killer Draughts. Not 100% sure but I believe if the last captured piece was a king, the "attacker" king should stop after that piece.
We did not embark on this journey yet, although Dragon and Scan have endgame databases based upon this principle.

Bert

[BertTuyt]

Hi Bert,

What are the results if you use 1 minute/75 moves? If I use 5 min/80 moves GWD draws all the time against Kingsrow, with 1 minute/75 moves sometimes GWD loses a game (but also sometimes wins).

GW

Gijsbert, the test I did this afternoon with 1 min/80 moves, 1 core , 6p db, both book, and Damage 18.6 did not use a permanent hash. This means every new search, the hashtable was build up again. I did not clear the hashtable, only increased the age, and only accepted search-results for the same age. Background, if i see a weird move, i can start from that position and get the same result.

KR - Damage 18.6 8 wins - 2 losses - 148 draws. So ELO wise around 13.

Bert

[MatteoRaso]

Besides engines, I was able to get GPT-5.6-Sol to create a tablebase generator for both Brazilian and international draughts. I gave it instructions about how I wanted the generator to function, but the AI had a lot of discretion on how to implement the codebase. To give you some idea of my abilities, I'm decent at Python, but I have no experience with C++. Truth be told, I wouldn't have been able to make this at all with my level of coding skills. Remarkably, even after setting the reasoning level to `xhigh` and giving Sol access to the web (both of which massively increase the number of tokens used), it only cost me about a cent to make. If any of you are interested in checking it out, I open-sourced the entire project.

https://github.com/MatteoRaso/draughts-tb

[BertTuyt]

I played another match with Damage 18.6 against Kingsrow, similar result 7 losses, 149, draws, 2 unknowns. As the unknowns were a draw the final match result was 7 wins, 151 draws (perspective Kingsrow).
The "problem" with such a number is that it does not reveal if the draw games were interesting , or balanced.
For this reason I asked Codex to write an application (named matchexplorer) which summarizes the (extensive) log file of the match.
See below screenshot.

The tool/application takes the logfile, gives a summary and description of every game.
In this case 0 wins, 149 draws, 7 losses, and 2 incomplete. You can also see that according "matchexplorer", 129 games were quiet, but 29 interesting and 7 narrow escapes. For so far i need to check on which definitions (which i did not gave) these classifications are based.

In the next picture I selected the view narrow escapes (7 in total), and highlighted game 100.

And another image of a "quiet" game (game 9).

Again, Codex maybe wont improve "dramatically" improve your program, but it is really fast in building fast prototypes for tools.
Also there might be some errors in the analysis, but i already found more interesting clues, compared with the past, when only looking at the end result.

Bert

[BertTuyt]

Here the flexibility of Codex.

I wanted to study (fore example) games lost.
Now i can drag a cursor in the graph window and select a specific move.
I get a diagram with the actual position, and one where i can see the position after all moves are executed in the principal variation (pv).
In Damage the pv is complete and i have (for example) no hash cuts.

I can even switch the mode of the first diagram, and single step through the pv.

Se below 2 images.

At least doing so revealed some information which normally disappears under the surface, and gives some "food for thoughts".

Bert

[BertTuyt]

In the CRC32 post from Gijsbert, Joost in a reply wrote

Using SIMD for the transposition table seems like a good idea, something I never thought of before.

As this was also on my mind for some time, but never started, I asked Codex to change my current Damage engine hash-table implementation into a SIMD version.
As DDR5 reads anyway always 64 bytes when memory is accessed this seemed not a completely weird idea.
Some changes where needed, as in my previous implementation the 64bit key and data where interleaved, but in the end Codex seemed to work everything out.
I did not test in detail if it 100% correct or if it was faster (first insight a few % faster, but it is too early to tell).
Anyway, it took around 15 minutes, from first discussion to implementation.

See below code (from Codex, including comments) for the probe.

Code: Select all

bool tts_probe(ttkey_t ttkey, ttdata_t* result)
{
	const unsigned int bucket_index = static_cast<unsigned int>((ttkey & tts_mask) / tt_cluster_size);
	const ttsbucket_t* bucket = tts_bucket + bucket_index;

	// Reconstruct four full keys in parallel: stored_key XOR packed_data.
	// A match means the key and data snapshot are mutually consistent under
	// Hyatt's lockless convention, even if another thread is writing nearby.
	const __m256i stored_keys = _mm256_load_si256(reinterpret_cast<const __m256i*>(bucket->key));
	const __m256i packed_data = _mm256_load_si256(reinterpret_cast<const __m256i*>(bucket->data));
	const __m256i reconstructed = _mm256_xor_si256(stored_keys, packed_data);
	const __m256i wanted = _mm256_set1_epi64x(static_cast<long long>(ttkey));
	const __m256i equal = _mm256_cmpeq_epi64(reconstructed, wanted);
	const int matches = _mm256_movemask_pd(_mm256_castsi256_pd(equal));

	if (matches == 0) return false;

	// Return data from the same SIMD snapshot used for comparison.  Reloading
	// the lane from memory here could pair the matched key with a newer write.
	alignas(32) uint64_t snapshot[tt_cluster_size];
	_mm256_store_si256(reinterpret_cast<__m256i*>(snapshot), packed_data);

	for (int lane = 0; lane < tt_cluster_size; ++lane)
	{
		if ((matches & (1 << lane)) == 0) continue;

		const ttdata_t candidate = data_from_bits(snapshot[lane]);
		// With persistence disabled, entries from earlier searches are treated
		// as misses.  Persistent mode permits entries of every generation.
		if (engine::enginedata.btt_persistent || candidate.age == tts_age)
		{
			*result = candidate;
			return true;
		}
	}

	return false;
}

Bert

[Joost Buijs]

It's a pity that not every machine supports AVX-512, with AVX-512 it's possible to shuffle the (usually) 4 entries in a bucket in a single clock-cycle. With AVX2 (which most X86 machines have) you'll need at least 3 instructions to do the same, so it can help a bit but I don't expect miracles from it.

Prefetching data into the processor-cache could help as well, but I never saw a significant improvement with that. Memory bandwidth is important, that's why a server CPU with 4, 8 or 12 memory channels will usually be faster than a consumer CPU, even with a lower clock frequency.

Joost

[BertTuyt]

Joost, i also don't think it will have a measurable effect.
At least what I wanted to share, is that with tools like Codex, it is easy and fast to implement and test some new ideas.
However also Codex is not a miracle tool, you need (for now) remain the architect, and feed the tool with ideas.

Bert

[Joost Buijs]

Joost, i also don't think it will have a measurable effect.

It will probably help if you want to shuffle the entries within a bucket to put a new entry (or an updated entry) into the first slot (like Gijsbert does). Currently it's too hot in my study (over 30 C), but when it's getting colder I will implement it, to see if it gives an improvement.

Joost