Schließe mich meinem Vorredner (dir) vollhinhaltlich an.
Aber weil einander die Threads mit dem über den neu erschienen Crystal etwas überschneiden, dort wie da her passend, selbst bei der Mattsuche, bei der man meint, man könnte time to solution und somit auch time to (best) eval leicht definieren, kommt's immer noch drauf an, was für Mattbilder in welcher Distanz, wenn man die "Leistung" der Engine, und sei's "nur" (anders geht's eh nicht exakt) am Output einer einzelnen Engine und einer einzelnen Stellung bewerten wollte.
Welche die genau richtige Eval (wie auch immer man sie ausdrücken wollte, in cp, Informator- Symbolen, WDL- Wahrscheinlichkeit...) für Stellungen wäre, die keine DTM ausrechenbar haben, ist eine Frage der schachlichen Phantasie und der programmier- technischen Absichten.

Wollte man wirklich anfangen, die numerischen Evals beim Wort zu nehmen, und ich finde auch, dass es höchste Zeit ist, müsste man mit den Relationen zwischen ihnen anfangen, weil der alte Unfug, cp einfach zu addieren oder subtrahieren, um zu vergleichen, was die eine Engine besser oder schlechter in Hinblick auf die schachliche Wahrheit dahinter bewertet, spätestens da als solcher (Unsinn) klar wird, wo man Stellungen, bei denen eine Seite im Vorteil ist, mit solchen im Nachteil vergleicht, Stellungen in der Eröffnung mit solchen im Endspiel, und dann ist eine Gretchenfrage schlechthin rein mathematisch, die sich nur in Bruchrechnungen beantworten lässt, ob der Vorteil ein großer oder ein kleiner ist.

Dass, wollte man bei einer klar gewonnenen Stellung, in der gerade noch keine DTM anrechenbar ist, zwischen 900 und 800 cp einen schachlich relevanten Unterschied zwischen den Evals von 2 Kandidatenzügen und oder zweier Engines festmachen, das ein völlig anderer sein muss als zwischen 0.01 und 1.01, ist klar.

Wollte man da für auch nur 2 willkürlich heraus gegriffene Beispiele einen gemeinsamen Bewertungsschlüssel, und sei's nur für die zwei einzelnen Stellungen und 2 beliebige einzelne Engines finden, müsste er in Prozent oder irgendeiner anderen rechnerischen Relation im Sinn von Division (durch 0.00 lässt sich halt schwer dividieren, aber da müsste man halt immer auf 0.01 oder -0.01 im Nenner runden, weil das Vorzeichen ja auch noch ein Problem für sich wäre) angegeben werden, die das Verhältnis abbilden könnte.

Bei Stellungen mit wenigen, dafür großteils forcierten Abspielen ist es auch etwas ganz  anderes, das Verhältnis von Suche zu "statischer" Eval (aus hard coded oder NN- bzw. NNUE- Parametern und - Einträgen) ist vom Suchbaum und damit auch der Evaluierung und Zugsortierung ein ganz anderes als bei "positionellen" Stellungen (ein Begriff, der im Computerschach noch nie viel Sinn gemacht hat und je besser sie im Rechnen und im Bewerten werden, umso weniger macht).

Das einzige, was bleibt, so lange man sich da nicht willkürlich auf bestimmte rechnerische Methoden zum direkten Eval- Vergleich einigt, ist die gute alte time to solution (von jeher der schachlich einzig relevante, weil exakt messbare Leistungs- Parameter) , man legt für die Stellung eine Eval- Range für einen best move und für weitere ähnlich gute Kandidatenzüge fest und misst die Zeit, die die Engines of interest auf bestimmter Hardware brauchen, um den Zug oben zu haben, den man für den besten hält oder (einen muss es immer gegen, lässt er sich nicht gut genug vom nächst besten schachlich unterscheiden oder seien sie durch mehr oder weniger zwingende Zugumstellung wirklich objektiv gleich gut, dann) die besten, wieder eine Frage von Eval- Ranges, auf die man sich für die einzelne Stellung geeinig hat, ist die time to solution, (in unserem Fall jetzt=time to (best) eval, ein exakt messbarer Wert. Natürlich immer nur für eine einzelne Stellung, aber dass Messungen von jeder Art von Spielstärke (bei Menschen ja auch) strikt stellungsabhängig zu betrachten sind, hat sich mittlerweile (im Zeitalter von UHO) wohl herumgesprochen.

Aber auch das nur ganz am Rande und unter Applaus an Walter für den Artikel im Glarean an und für sich

... und vor allem ist Manzo's Ansatz interessant, mit seinem SF-Derivat ShashChess die "Denk-Methode" zu "programmieren",
die der St. Petersburger Schach-Trainer und Buchautor Alexander Shashin entwickelt hat in seinem Buch:
"A Universal Method For Discovering The Strongest Move":
https://pdfcoffee.com/best-play-a-new-method-for-discovering-the-strongest-move-alexander-shashin-2-13-pdf-free.html

Vielleicht sind sowohl Buch als auch Engine auch nur der nutzlose Versuch einer Quadratur des Kreises - aber wenn diese programmiertechnische Adaption einer "Schachmethode"
auch nur halbwegs gelungen ist, dann ist es eines der besten Lehrbücher der Welt. Denn ShashChess ist eine der besten Engines der Welt -
in einigen Aspekten besser als das SF-Original...

.

Ja, das Thema gäbe noch viel her.
Ich würde, weil's da gerade so gut passt, mal einen Begriff propagieren wollen, der so noch kaum verwendet wird, die
time to eval.
Time to solution ist bekannt, wird aber in seiner vollen Relevanz auch oft unterschätzt, wie schon gesagt, für mich der einzig schachlich wirklich relevante Leistungsparameter einer Engine bei einer Stellung, ohne Evals in numerischer Form kommt man eventuell aus, ganze und halbe Punkte hat man immer erst nach ganzen Partien, woraus die aber bestehen, die Züge und die Stellungen, darauf muss man mit time to solution eingehen, wenn man mehr will als nur Punkte zählen.

Man kann immer nur ein einzelne Stellung wirklich exakt (was Output- Lines, Abspiele und Evals einschließlich ihrer Relationen und Verläufe zwischen den Kandidaten und den Folgezügen) untersuchen, Spielstärkemessungen jeder Art sind immer Stellungs- abhängig, will man genaue Vergleiche, muss man die einzelnen Stellungen genau anschauen.

Und wenn man sich über time to solution (muss ja nicht eine einzelne Lösung sein, genau weiß man auch von der immer nur, wie singulär sie ist, wenn man sie mit den alternativen Kandidaten vergleicht) Hardware- Software- abhängig klar ist, und, was die Eval- Ranges angeht, diese als Ziel- Eval definiert hat (und sei's nur innerhalb von Informator- Symbol- Bereichen oder  anderen entsprechend klassifizierenden Einschätzungen), dann wäre
time to eval
eigentlich eine ebenso klare Sache.
Ohne den im Schach an und für sich immer auch zu messenden Faktor Zeit, der wie eine dritte oder vierte Dimension jedes Zuges dazu gehört im Spiel, ist jede Spielstärke- Messung zumindest ungenau.
Bei den numerischen Evals sind im Output ohnehin auch immer Rechenzeit und -Tiefe dabei, das Wichtigste sind natürlich die Züge, die Evals hängen immer von mehr als nur dem einen einzelnen Zug ab, für den sie gelten, (wie lange die zu beachtenden Variante sind bis zu welchen Folgestellungen mit viel oder weniger Veränderung, ist z.B. auch wichtig, ebenso wie vom Fortschritt, der in der Partie bis zur Eval- Stellung schon passiert ist) aber von der Zeit jedenfalls auch.