"It must be a clone of some sort..."

[IanKennedy]

What is exactly the reason to keep an engine private/closed?

Engine not competitive/coding horrors etc.

[Tony P.]

If you opensource an early, much weaker, version of an engine that you're releasing without the current source, then it's hardly a mortification because it's known that your coding skills have improved since the early days because your engine now plays strong. The weaker version serves as a proof of creativity, as it can be checked for gameplay similarities with the full-strength one, and yet, it doesn't have to leak all the secret sauce.

Another option is to make the open version not a full engine but a solver for a specific class of problems where it does well in comparison with other engines. Say, if the full engine is good at endgames, then it makes sense to release its EG module separately, with a generator of test EG positions for matches with other engines.

[JohnWoe]

When you look at these fresh 3000 Elo engines. They all have similar 1500 lines super complex search function as SF.
Null move, LMR, IID etc all in the same steps as i in SF. All are the same old AB stuff. It might be original.

Forget the 1500 lines search. Stockfish actually have a really fast move generator.To write something similar speed is actually time consuming.

Which is no wonder. It's all big tuning process. You could have all the good stuff. But if it's not tuned it's worth crap.
To actually tune chess engine you need to run billions of games and produce tonnes of CO2 in the process.

Try to sneak into Linux kernel a super complex 1500 lines function. It wont happen

[mar]

move generator speed is totally irrelevant in terms of engine strength

nps is also completely irrelevant - SF8 searches startpos at ~1.6MNps while Crafty 25.3 at ~5.3MNps (both single core)
only difference is that SF8 is nearly 400 elo stronger
now compare that to nps of LC0 and then compare the relative strength etc.

I wonder why people are so obsessed with movegen speed - this won't magically get you a strong engine
that's not to say that having a faster movegen is a bad thing, just that a fast movegen per se means very little

[Joost Buijs]

Indeed, in a full-fledged engine the move-generator takes maybe 5% of the total time, if you make the move-generator twice as slow it will cost you at most 5 Elo. Functions that consume the most time are (at least in my engine) : the evaluation, SEE and probing the hash-table (the latter only when I probe in quiescence).

NNUE shows again that evaluation is the most important part of an engine and that speed is of secondary importance. It was somewhat different in the very distant past when the hardware was slow and the compilers were bad, at that time you had to code everything for speed to get the engine tactically sufficient.

[JohnWoe]

Indeed, in a full-fledged engine the move-generator takes maybe 5% of the total time, if you make the move-generator twice as slow it will cost you at most 5 Elo. Functions that consume the most time are (at least in my engine) : the evaluation, SEE and probing the hash-table (the latter only when I probe in quiescence).

NNUE shows again that evaluation is the most important part of an engine and that speed is of secondary importance. It was somewhat different in the very distant past when the hardware was slow and the compilers were bad, at that time you had to code everything for speed to get the engine tactically sufficient.

SF generates 120 Mnps on my machine. So 50% is still 60Mnps. Obviously it has better eval/search.. You could get away with 1000 nps move generator if you are probing a 32 men EGTB.

I don't know if my engine is "full-fledged". But it spends majority of its time generating moves.
The most called functions are AddW/AddB both movegen functions.
Also where the time is spent.
I have posted the gprof report many times here.
But you try it yourself.
My Search/Eval are super fast. I'm making them more branchless.
So there will be even more speed.

In quick games that speed shows.

Code: Select all

Started game 3223 of 10000 (Sapeli 1.91 vs Stockfish 12)
Finished game 3223 (Sapeli 1.91 vs Stockfish 12): 0-1 {Black mates}
Score of Sapeli 1.91 vs Stockfish 12: 92 - 2968 - 163  [0.054] 3223
Started game 3224 of 10000 (Stockfish 12 vs Sapeli 1.91)
^CTerminating process of engine Sapeli 1.91(0)
Terminating process of engine Stockfish 12(1)
Finished game 3224 (Stockfish 12 vs Sapeli 1.91): * {No result}
Score of Sapeli 1.91 vs Stockfish 12: 92 - 2968 - 163  [0.054] 3223
Elo difference: -497.97 +/- 23.12

[mar]

Indeed, in a full-fledged engine the move-generator takes maybe 5% of the total time, if you make the move-generator twice as slow it will cost you at most 5 Elo. Functions that consume the most time are (at least in my engine) : the evaluation, SEE and probing the hash-table (the latter only when I probe in quiescence).

NNUE shows again that evaluation is the most important part of an engine and that speed is of secondary importance. It was somewhat different in the very distant past when the hardware was slow and the compilers were bad, at that time you had to code everything for speed to get the engine tactically sufficient.

SF generates 120 Mnps on my machine. So 50% is still 60Mnps.

huh? if you have "a=movegen" that is 5% of something (that strongly correlates with nps) and you make "a" 2x slower, you will get nowhere near half nps (2x total slowdown), the total slowdown should be around 5%, just as Joost wrote

Code: Select all

constexpr double a = 0.05;
constexpr double aspeedup = 0.5;

void main()
{
	// relative speedup
	double rspd = 1.0 / (a/aspeedup + (1.0-a));
	"relative speedup = %t\n", rspd;
}

this gives 0.952381, which is slightly below 5%, at most 5 elo at hyper-bullet (unless I made an error somewhere, still you won't get 2x slowdown by having 2x slower movegen, which was the point)

[JohnWoe]

Indeed, in a full-fledged engine the move-generator takes maybe 5% of the total time, if you make the move-generator twice as slow it will cost you at most 5 Elo. Functions that consume the most time are (at least in my engine) : the evaluation, SEE and probing the hash-table (the latter only when I probe in quiescence).

NNUE shows again that evaluation is the most important part of an engine and that speed is of secondary importance. It was somewhat different in the very distant past when the hardware was slow and the compilers were bad, at that time you had to code everything for speed to get the engine tactically sufficient.

SF generates 120 Mnps on my machine. So 50% is still 60Mnps.

huh? if you have "a=movegen" that is 5% of something (that strongly correlates with nps) and you make "a" 2x slower, you will get nowhere near half nps (2x total slowdown), the total slowdown should be around 5%, just as Joost wrote

Code: Select all

constexpr double a = 0.05;
constexpr double aspeedup = 0.5;

void main()
{
	// relative speedup
	double rspd = 1.0 / (a/aspeedup + (1.0-a));
	"relative speedup = %t\n", rspd;
}

this gives 0.952381, which is slightly below 5%, at most 5 elo at hyper-bullet (unless I made an error somewhere, still you won't get 2x slowdown by having 2x slower movegen, which was the point)

But I only stated 50% of 120 Mnps is 60 Mnps. (Let's go again. 50% of 70 is 35.) Nothing else. Which is still 60 Mnps. Faster than Sapeli's 40 Mnps. I'm not sure if my math is correct or not.
It's surely missing some fancy derivates/other academic BS.

[mar]

But I only stated 50% of 120 Mnps is 60 Mnps. (Let's go again. 50% of 70 is 35.) Nothing else. Which is still 60 Mnps. Faster than Sapeli's 40 Mnps. I'm not sure if my math is correct or not.
It's surely missing some fancy derivates/other academic BS.

sure, 50% of 120 is 60, but then I don't understand the context. I thought we were talking movegen speed which is typically a fraction of total time and I was merely stating the obvious.
120Mnps - how many cores, what position? 120Mnps out of context means very little

btw what "fancy derivatives/academic BS"?! this is elementary school...

[JohnWoe]

But I only stated 50% of 120 Mnps is 60 Mnps. (Let's go again. 50% of 70 is 35.) Nothing else. Which is still 60 Mnps. Faster than Sapeli's 40 Mnps. I'm not sure if my math is correct or not.
It's surely missing some fancy derivates/other academic BS.

sure, 50% of 120 is 60, but then I don't understand the context. I thought we were talking movegen speed which is typically a fraction of total time and I was merely stating the obvious.
120Mnps - how many cores, what position? 120Mnps out of context means very little

btw what "fancy derivatives/academic BS"?! this is elementary school...

Read my post. It isn't a fraction. This is where my engine spends most of its time. Generating moves. How the hell it's fraction when it isn't? Not that it matters in strength. Stockfish isn't my engine. It's totally irrelevant.

You produce text like GPT-3. Where is your engine? Have you written your engine from scratch? Move generator and everything?