Answers.Body: <p>This seems to be somehow LeelaFish's approach:</p>
  
  <p><a href="https://github.com/killerducky/lc0/wiki/LeelaFish" rel="nofollow noreferrer">https://github.com/killerducky/lc0/wiki/LeelaFish</a></p>
  
  <p>More about it here (and probably on more posts in the same forum):</p>
  
  <p><a href="http://www.talkchess.com/forum3/viewtopic.php?t=70803&amp;start=10" rel="nofollow noreferrer">http://www.talkchess.com/forum3/viewtopic.php?t=70803&amp;start=10</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-31T09:53:56.207Z
Answers.Text: Thanks for answer. This seems like it's only one way though, with Leela taking advantage of Stockfish's PV. Are there any attempts to make Stockfish take advantage of Leela's PV?
Answers.UserDisplayName: Allure
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-01T03:14:23.583Z
Answers.Text: The reasoning here is that Leela  is generally a better evaluator when she doesn't miss lines, while for SF it's blunders tend to be more due to mis-evaluating critical positions.
Answers.UserDisplayName: Oscar Smith
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-10-31T09:15:58.503Z
Answers.LastActivityDate: 2019-10-31T16:07:55.990Z
Answers.LastEditDate: 2019-10-31T16:07:55.990Z
Answers.UserDisplayName: emdio
Answers.Body: <p>Part of this can be accomplished with Chessbase GUI. There is an option called cloud analysis. It is thougt to use engines in the cloud additional to your own engine. It ever could be used with two local engines, one determining the 1-n main variants, the other to evaluate the variants. A third engine could make proposals for answers to the main moves and so on.</p>
  
  <p>With brute force engines like Stockfish, each engine needs CPU threads and RAM for caching. Loading more than one engine would reduce the rating of each of them. I haven’t tried, but it might be that you can run Leela and p.e. Stockfish in this scenario without reducing performance.</p>
  
  <p>One of the engine would use the proposals of the other, but not the other way. So it is only a partial answer to your question.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-11-02T18:39:17.233Z
Answers.LastActivityDate: 2019-11-02T18:39:17.233Z
Answers.UserDisplayName: Christian H. Kuhn
Body: <p>This is a speculative question since I don't know if such an engine is even plausible.</p>
  
  <p>The idea: we'll start Stockfish and Leela at the same time using both my CPU and GPU. Within a fraction of a second, both engines will output principal variations. Then we use the other engine's principal variations to influence our search. For example, suppose Stockfish wants to play 1. e4 and Leela wants to play 1. d4. Using this, we move 1. e4 up Leela's <a href="https://www.chessprogramming.org/Move_Ordering" rel="noreferrer">move ordering</a>, and do the same for 1. d4 and Stockfish.</p>
  
  <p>In other words, both engines use the other engines' principal variation to influence their search, such that both engines is preferentially searching the other engine's principal variation. Then, combine the results from both engines, e.g. if the engines agree then play the move, and apply other heuristics if they don't. The idea seems straightforward to extend if the principal variations are the same up to 5 moves ahead, etc, and it also sounds obvious that it should produce a stronger engine.</p>
  
  <p>This kind of engine would still be reliant on Leela and Stockfish individually, but be able to take advantage of both CPU and GPU resources. As far as I know there's no engine that does this (GPU engines already use some CPU power, but it's small; CPU engines don't use the GPU at all). So: does this idea work? If so, has anyone tried it? If not, why not?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-11-01T18:23:45.277Z
Comments.Text: Hmmmm. Not sure what this accomplishes. More importantly, it's hard to see how this converges (or am I just being blind today). When you get to the end, how do you pick between the two engine's choices, when they will presumably have different evaluations (hence the different PVs). You've been building out two long variations where each engine plays one color against the other, so we have to assume they have different evaluations of the position.
Comments.UserDisplayName: Arlen
Tags: <engines><stockfish><leela>
Title: Is it possible to combine CPU and GPU engines to use the other's principal variation?
ThreadText: # Is it possible to combine CPU and GPU engines to use the other's principal variation?
  
  (Asked by: username_0 on 2019-10-31)
  
  This is a speculative question since I don't know if such an engine is even plausible.
  
  The idea: we'll start Stockfish and Leela at the same time using both my CPU and GPU. Within a fraction of a second, both engines will output principal variations. Then we use the other engine's principal variations to influence our search. For example, suppose Stockfish wants to play 1. e4 and Leela wants to play 1. d4. Using this, we move 1. e4 up Leela's [move ordering](https://www.chessprogramming.org/Move_Ordering), and do the same for 1. d4 and Stockfish.
  
  In other words, both engines use the other engines' principal variation to influence their search, such that both engines is preferentially searching the other engine's principal variation. Then, combine the results from both engines, e.g. if the engines agree then play the move, and apply other heuristics if they don't. The idea seems straightforward to extend if the principal variations are the same up to 5 moves ahead, etc, and it also sounds obvious that it should produce a stronger engine.
  
  This kind of engine would still be reliant on Leela and Stockfish individually, but be able to take advantage of both CPU and GPU resources. As far as I know there's no engine that does this (GPU engines already use some CPU power, but it's small; CPU engines don't use the GPU at all). So: does this idea work? If so, has anyone tried it? If not, why not?
  
  **Tags:** engines, stockfish, leela
  
  > **Comments:**
  > **username_1**: Hmmmm. Not sure what this accomplishes. More importantly, it's hard to see how this converges (or am I just being blind today). When you get to the end, how do you pick between the two engine's choices, when they will presumably have different evaluations (hence the different PVs). You've been building out two long variations where each engine plays one color against the other, so we have to assume they have different evaluations of the position.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2019-10-31. Score: 3 | Accepted answer
  
  This seems to be somehow LeelaFish's approach:
  
  <https://github.com/killerducky/lc0/wiki/LeelaFish>
  
  More about it here (and probably on more posts in the same forum):
  
  <http://www.talkchess.com/forum3/viewtopic.php?t=70803&start=10>
  
  > **Comments:**
  > **username_0**: Thanks for answer. This seems like it's only one way though, with Leela taking advantage of Stockfish's PV. Are there any attempts to make Stockfish take advantage of Leela's PV?  
  > **username_3**: The reasoning here is that Leela  is generally a better evaluator when she doesn't miss lines, while for SF it's blunders tend to be more due to mis-evaluating critical positions.  
  
  ---
  
  ### Answer by username_4 on 2019-11-02. Score: 2
  
  Part of this can be accomplished with Chessbase GUI. There is an option called cloud analysis. It is thougt to use engines in the cloud additional to your own engine. It ever could be used with two local engines, one determining the 1-n main variants, the other to evaluate the variants. A third engine could make proposals for answers to the main moves and so on.
  
  With brute force engines like Stockfish, each engine needs CPU threads and RAM for caching. Loading more than one engine would reduce the rating of each of them. I haven’t tried, but it might be that you can run Leela and p.e. Stockfish in this scenario without reducing performance.
  
  One of the engine would use the proposals of the other, but not the other way. So it is only a partial answer to your question.
  
  
  ---
  
  