user8406: I was setup stockfish with:
uci
setoption name hash value 128
setoption name threads value 4

That I try to evaluate my first moves to learn how it works (I am programmer) but I received random results.
go depth 20

First result cp = 16
info depth 20 seldepth 30 multipv 1 score cp 16 nodes 1327846 nps 1074309 hashfull 585 tbhits 0 time 1236 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 f1d3 g8f6 g1f3 f8d6 e1g1 e8g8 b1c3 c7c6 f3e5 f8e8 c1f4 f6g4 f1e1 d6e5 f4e5 g4e5 e1e5
bestmove e2e4 ponder e7e6

Second result cp = 20.
info depth 20 seldepth 29 multipv 1 score cp 20 nodes 4912037 nps 1040685 hashfull 986 tbhits 0 time 4720 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 f1d3 g8f6 g1f3 f8d6 e1g1 e8g8 b1c3 b8c6 c1g5 c6b4 c3b5 h7h6 b5d6 d8d6
bestmove e2e4 ponder e7e6

Why each time Stockfish produce something else for 20 depth - different scores - same move e2e4?

user825: The reason is simple - hashing. The first time you run the analysis, the engine stored the computed positions in a hash-table. This table was not clear the next time you run the analysis. Next time, when you ran the same analysis, the engine could search further and thus returned a different score for it's principal variation.
Evidence? Note the node counts was: 1327846 for your first attempt and 4912037 for your second attempt. The NPS (nodes per second) was very close (1074309 vs 1040685). Clearly Stockfish used the existing hash-table to skip moves it had already computed in your first attempt. 
Note that this is an expected behaviors, clearing hash-table after each move would dramatically reduce the engine strength.

8406: <p>I was setup stockfish with:</p>

<pre><code>uci
setoption name hash value 128
setoption name threads value 4
</code></pre>

<p>That I try to evaluate my first moves to learn how it works (I am programmer) but I received random results.</p>

<pre><code>go depth 20
</code></pre>

<p>First result cp = 16</p>

<pre><code>info depth 20 seldepth 30 multipv 1 score cp 16 nodes 1327846 nps 1074309 hashfull 585 tbhits 0 time 1236 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 f1d3 g8f6 g1f3 f8d6 e1g1 e8g8 b1c3 c7c6 f3e5 f8e8 c1f4 f6g4 f1e1 d6e5 f4e5 g4e5 e1e5
bestmove e2e4 ponder e7e6
</code></pre>

<p>Second result cp = 20.</p>

<pre><code>info depth 20 seldepth 29 multipv 1 score cp 20 nodes 4912037 nps 1040685 hashfull 986 tbhits 0 time 4720 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 f1d3 g8f6 g1f3 f8d6 e1g1 e8g8 b1c3 b8c6 c1g5 c6b4 c3b5 h7h6 b5d6 d8d6
bestmove e2e4 ponder e7e6
</code></pre>

<p>Why each time Stockfish produce something else for 20 depth - different <strong>scores</strong> - same move <strong>e2e4</strong>?</p>
 825: <p>The reason is simple - <code>hashing</code>. The first time you run the analysis, the engine stored the computed positions in a hash-table. This table was not <strong>clear</strong> the next time you run the analysis. Next time, when you ran the same analysis, the engine could search further and thus returned a different score for it's principal variation.</p>

<p>Evidence? Note the node counts was: <code>1327846</code> for your first attempt and <code>4912037</code> for your second attempt. The NPS (nodes per second) was very close (<code>1074309</code> vs <code>1040685</code>). Clearly Stockfish used the existing hash-table to skip moves it had already computed in your first attempt. </p>

<p>Note that this is an expected behaviors, clearing hash-table after each move would dramatically reduce the engine strength.</p>
