Komodo benefits less from TBs?

[cdani]

How do you account for it not seeing a draw in the following position, then?

To cover all the endgames without tablebases, you need a lot of time and code, and for some endgames is almost impossible to code, not for this position of course. When I discover positions like this that Andscacs does not know, I put it in the infinite list of things to improve, and sure for Komodo guys do the same.

[Tdunbug]

I want to see if Komodo would benefit from relying on it's own calculations more during the middle stages of the games.

Good ! It does, actually, but I have no Proof, as its only an Observation of mine while watching online Engine-Engine Matches. Unfortunately, its not consistent enough, but perhaps that's because current version of Komodo is inherently weak.
But why are you using speed as a parameter/benchmark ? I don't think that's a good idea and has little to do with Komodo's unique approach to the Middle Game.

It is just a preliminary observation. The main point I was trying to make was that the speed seems to be a trade off between the transition for the middle game to the endgame.

By the way I forgot to mention the System specs and such

Dual xeon 2695 vs 2 with HT off
12 cpu a side
Memory: 4098 mb
TBS 5 man
TC 1 min 2 secs

Min 10k games

[mjlef]

You seem to be confusing a comment I made in general about endgame play versus a single position. But looking at your position, since the position is a draw, and will eventually end in a draw when Komodo plays, the result of the games does not change. Playing on could indeed lead to an opponent blunder, but I see nothing wrong in that position.

We have found trying to "fix" the search for a specific position often hurts overall play. But I will revisit the position in the future (and another bishop ending someone sent in as well).