Engine can't find the win!!

I am surprised that no one pointed out that 20. Nxg6? was a serious mistake that leaves white's king vulnerable to attack. It also over complicates the position which can be seen from the analysis on the YouTube video. King safety should always take precedence over grabbing material. It seems that even GMs are not immune to these types of lapses in judgement.

Instead, white should have played 20. Qc1! threatening to exchange queens. If black then plays 20...Nc4 then 21.Qxa3 Nxa3+ 22.Kb2 and white has a modest positional advantage. if 20...Qa5? then 21.Qb2 and if 21...Nc4 then there follows 22.c3 Ba3 23.Qe2 and white is better here too.

That is very true @WilliamShakespeare , didn't mention it because I thought it was a bit outside the scope of the video. 20. Qc1 would have been the better move, but it's incredibly hard to calculate and evaluate every line. If you think you can take on g6 and your opponent agrees, then I don't think we talk of a lapse in judgement.

@IM TricksOnlyNL This game clearly reinforces the idea that grabbing material before safeguarding your king can lead to a lost position for the side defending the attack. That is why I said the GM playing the white side had a lapse in judgement in respect to the general rule of thumb of safeguarding your king before going on a piece gathering expedition. 20.Kc1 would be an illegal move. Did you mean 20.Qc1 was the best move like I suggested?

Yes 20. Qc1 is what I meant, changed it.

@butterfli : this explanation about the hash table is completely new to me. I've seen the setting, but never understood it's value. So if I'm preparing openings and am constantly going back and forth and switching between lines, is it better to have more ram on my hash table? Is it worh sacrificing some ram that I'd else use for my engine to calculate? Is there a maximum or preffered setting for your hash table size?

I guess there is some gain in knowing all this when analysing a specific position or certain openings.

Yeah, if you are keeping the engine running for a long time and going back and forth a lot (or just letting it analyze a single position deeply), a large hash table would be nice.

Try setting your hash table to half of the total amount of RAM you have. This might cause other things you are doing with your computer to perform poorly, or it might cause some delay before you see any output at all from the engine. If that is happening, then just reduce the size of the table (maybe try 1/4th of total RAM next)