hgm wrote: ↑Mon Apr 15, 2024 6:01 pm
But most people of course don't have 'modern hardware'. I guess this is sort of a blind spot for engines that have no real user base. They are only written for the select group of testers, who usually have the best of the best. On my PC (Intel Sandy Bridge) you would be bandwidth limited. Especially when running multi-threaded. The bus clock is 100MHz (multiplier 32), so for fetching a cache line reading 8 words of data alone already takes 256 CPU clocks, during which no other memory access can be served.
Tt in qsearch was shown to be beneficial in stockfish at times not so long after Sandy Bridge became available to market.
Not even saying that % of people that own this type of hardware nowadays is extremely low, so "most people don't have modern hardware" maye be true but most people have newer hardware than Sandy Bridge.
hgm wrote: ↑Mon Apr 15, 2024 1:53 pm
Crafty did this. I would not call Bob Hyatt 'no one'. He was always loudly present.
Mhm. Crafty, the very strong modern engine with current and even decade-old innovations in search.
hgm wrote: ↑Mon Apr 15, 2024 2:22 pm
Dozens of examples is not so impressive if you realize there are many hundreds of engines.
hgm wrote: ↑Mon Apr 15, 2024 6:01 pm
But most people of course don't have 'modern hardware'. I guess this is sort of a blind spot for engines that have no real user base. They are only written for the select group of testers, who usually have the best of the best. On my PC (Intel Sandy Bridge) you would be bandwidth limited. Especially when running multi-threaded. The bus clock is 100MHz (multiplier 32), so for fetching a cache line reading 8 words of data alone already takes 256 CPU clocks, during which no other memory access can be served.
You can complain from theory until your keyboard breaks, but that changes absolutely nothing about the fact that probing the TT in qsearch has been shown to work in dozens of the not-even-nearly-hundreds of currently relevant engines. Look at this titanic, incredible slowdown that it causes in Stormphrax:
I never claimed otherwise. I only pointed out that this is a long-known effect, what has been used to counteract it, and that for some engines this even proved beneficial.
Without knowing what hardware the OP has, or how fast his code is, there can be no prediction what would work best for him. Like with every feature of an engine it would have to be tested.
For my engines probing in QS was always better as well. But it could be different for engines that heavily use SMP, as this requires more memory bandwidth.
It depends on engine and hardware, modern hardware has ~10-way memory-level-parallelism per core, so bandwidth should not be the issue but latency, as mentioned, prefetch might help:
connor_mcmonigle wrote: ↑Mon Apr 15, 2024 12:57 am
Sure. However, telling someone not to perform the TT probe in quiescent search to avoid the slowdown is just bad advice generally and, when stated from a position of authority, especially unhelpful. It's pretty established at this point that the cost of performing a TT probe in the quiescent search is worth it, though I'd encourage any new authors to test this themselves and re-test as the cost of their evaluation function increases relative to the cost of a TT probe.
Whether it is worth it will depend on the engine. For most engines (that were not derived from SF), it is most likely not worth it to probe in the qsearch. For an engine written from scratch, it will probably take 10+ years of active development to make probing in the qsearch worth it. In the meantime, just don't probe in the qsearch.
hgm wrote: ↑Mon Apr 15, 2024 1:53 pm
Crafty did this. I would not call Bob Hyatt 'no one'. He was always loudly present.
DRAM access is very slow compared to CPU cycle time, equivalent to hundreds of instructions. Adding a slow operation to an otherwise much faster code normally slows it down a lot. But perhaps you consider it normal that engines are very slow to begin with. I suppose 'normal' is a somewhat subjective qualification. I was not the one to introduce it in the discussion, but it seemed was clear that the OP was using it in the sense of 'no indication that I did something wrong that I should worry about'.
No one nowadays does this, this is better?
What you are effectively saying is that everybody nowadays starts by forking SF. And this is simply not the case.
A programmer's first engine written from scratch in 2024 will be quite similar to a programmer's first engine written from scratch in 1994.
hgm wrote: ↑Mon Apr 15, 2024 1:53 pm
Crafty did this. I would not call Bob Hyatt 'no one'. He was always loudly present.
Mhm. Crafty, the very strong modern engine with current and even decade-old innovations in search.
For the third time in this thread: the TS is writing an engine from scratch. He does not start by forking SF. He does not even start from Crafty or gnuchess.
syzygy wrote: ↑Thu Apr 18, 2024 9:31 pmA programmer's first engine written from scratch in 2024 will be quite similar to a programmer's first engine written from scratch in 1994.
If I were writing a chess engine today, I would use one of the open source chess DLLs to take care of things like move generation. I'm guessing you wouldn't count that as "writing from scratch", but I would call it, "good development practice".
The simple reveals itself after the complex has been exhausted.
syzygy wrote: ↑Thu Apr 18, 2024 9:31 pmA programmer's first engine written from scratch in 2024 will be quite similar to a programmer's first engine written from scratch in 1994.
If I were writing a chess engine today, I would use one of the open source chess DLLs to take care of things like move generation. I'm guessing you wouldn't count that as "writing from scratch", but I would call it, "good development practice".
Good development practice is not writing a chess engine at all because there are plenty of engines already and you can just use one of those.
In principle I agree with you that not re-inventing the wheel is a good thing, but someone who starts writing a regular chess program will in most cases not do that for the end result (yet another chess engine) but for the (learning) experience. Why would one want to reduce that experience by copying someone else's code?
(Of course in reality there is nobody that could write a half-decent engine entirely from scratch without at least looking at some high-level code. So there will inevitably be some kind of borrowing, and that is fine. And if you want to borrow more than I would like to myself, then that is perfectly fine too (as long as copyrights are respected etc.). And once you have something that plays somewhat decent legal chess without crashing and want to add TBs, then by all means just copy the code from somewhere else.)
