Newsgroup: it.hobby.scacchi
Titolo: quando un engine perde per il tempo

La prossima settimana iniziera' la superfinale del TCEC, che rappresenta 
per molti versi il campionato del mondo ufficioso dei motori 
scacchistici. A contendersi il titolo sono Komodo e Stockfish, i due 
indiscussi programmi piu' forti del momento.
 
Nell'ultimo girone di eliminazione Komodo e Stockfish hanno chiuso 
rispettivamente a 20.5 e 18.5 punti, distanziando Gull (16.5), Houdini 
(12.5), Hannibal e Protector (entrambi a 11).
 
La cosa che pero' ha fatto scalpore sono state le tre sconfitte di 
Stockfish per il tempo (!!!): una in posizione vinta, una in posizione 
superiore, e una in posizione del tutto patta.
 
Le sconfitte sono dovute probabilmente ad un bug del programma stesso, 
che pero' si e' manifestato solo su un hardware assolutamente "di punta" 
quale quello usato nel TCEC, in combinazione forse anche con il sistema 
operativo e l'interfaccia di gioco usata. Per questo motivo, il bug 
risulta difficile da riprodurre, e dunque da diagnosticare e correggere.
 
Si spera che la versione di Stockfish utilizzata per la finalissima sia 
esente da questo bug, in modo che il confronto con Komodo sia equo e il 
risultato finale sia chiaro e senza polemiche. Rimanete sintonizzati!
 
Ciao, Bruno.
 


come programmatore, spero vivamente che non sia possibile aggiornare il
software durante il "torneo".. altrimenti gli organizzatori dovrebbero
farsi qualche corso di informatica, o di fair-play (per farmi capire,
lasciando da parte i motori e focalizzandoci su chi li scrive, è una gara
di conoscenza del gioco o di chi mette più velocemente "pezze" al codice
per battere l'avversario di turno?)
 
Se nella versione in gara c'è un bug poco male, siamo stati fortunati a
scoprirlo, per il prossimo anno sarà sistemato..
 
Ciao!

Forse è un "bug" che si può correggere con una differente configurazion edei parametri del motore, senza bisogno di patch sul codice.
 
In questo caso trovo lecito correggere i parametri del motore durante il torneo.
 
m


In questo caso, se le regole lo permettessero (non so), sarebbe un po'
più comprensibile (anche se, pure in questo caso, se ne potrebbe parlare -
e di sicuro non sarebbe un "bug" nell'accezione comune del termine).
 
Ciao!


 
Se ha perso per il tempo gia prima, figuriamoci ora, che se la prende 
con Komodo ...
 
 
frengo
 
-- 
__________________________
http://www.nobilgiuoco.com
 


LOL!!!
 
-- 
"Everybody should pay taxes with a smile"
I tried, but they want money.

 velocemente "pezze" al codice per battere l'avversario di turno?)
 
Infatti è così: di solito gli aggiornamenti sono possibili solo fra una
fase e l'altra della competizione, non all'interno della stessa fase.
Quello che è successo stavolta è stato un caso particolare e il ritorno
alla vecchia versione di SF è stato concordato con tutti gli autori dei
motori in gara (almeno quelli che hanno potuto essere raggiunti).
http://www.chessdom.com/press-release-regarding-the-stockfish-case-in-tcec-stage-3/
 
 
Del resto Thoresen e compagni non sono certo gli ultimi arrivati in
questo campo.
 
Piuttosto mi preoccupa un po' che l'ultima sconfitta di SF per il tempo
sia arrivata con la versione "vecchia". Speriamo che per la superfinale
abbiano potuto sistemare…
 
Gabry (partiti, forza StockFish!) :-)
 

 abbiano potuto sistemare…
 
 
In realta' probabilmente non c'era un bug nel codice "lazy-smp" di 
Stockfish, come sembrava in un primo tempo e come indicato nel link da 
te riportato, ma piuttosto una impossibilita' pratica di predire con 
esattezza che il sistema operativo avrebbe risposto nel tempo desiderato.
 
A chi interessano i dettagli tecnici, la cosa pare che dipenda dal modo 
in cui Stockfish si affida alla funzione sleep(), ed e' discussa ad 
esempio su Talkchess:
http://talkchess.com/forum/viewtopic.php?topic_view=threads&p=646213&t=58056
 
 
Ovviamente questo dipende dall'hardware particolarmente complesso usato 
per il TCEC, e puo' succedere solo in condizioni estreme e per sistemi 
con un numero di processori molto elevato.
 
La soluzione banale e' stata quella di lasciare un margine di sicurezza 
piu' ampio per il tempo di riflessione, senza cercare di sfruttare fino 
all'ultimo millisecondo. Nella pratica, dovrebbero aver aggiustato il 
parametro Move Overhead, che e' uno dei pochi modificabili a piacere tra 
uno stage e l'altro del TCEC.
 
In sintesi, dunque: versione vecchia o nuova, nello stage precedente 
poteva crashare. Qui nella superfinale non dovebbe crashare (le ultime 
parole famose...).
 
Ciao, Bruno.
 
 

 
 
Anche non conoscendo l'architettura interna di SF, leggendo i commenti nel
link che hai postato (di cui la maggior parte scritti da chi non ha la
minima idea di cosa parla, ma tra cui fortunatamente uno ha postato il
punto del codice dove si verifica probabilmente il problema), direi che
non "dipende dall'hardware", ma da una scelta veramente infelice, direi
da principianti, dei programmatori che hanno ideato quel sistema.
 
Una delle prime cose che s'insegna nella gestione dei thread e che mettere
un thread in sleep in quel modo non solo non garantisce che ripartirà "in
tempo", ma potrebbe anche non ripartire mai. In pratica una situazione
del genere non succede mai, ed evidentemente qualcuno ha pensato che la
pratica valesse bene la teoria :) ed ora ne paga le conseguenze.
 
Curioso come, anche in programma così famoso e complesso, si possano
trovare cappellate simili.
 
Una pezza per ora riescono a metterla di sicuro, ma per sistemare questa
cosa a modo ci vorrà, direi, un bel po' di tempo!
 
Ciao!

 da principianti, dei programmatori che hanno ideato quel sistema.
 
 
Non metto in dubbio quello che dici, se ritieni che sia comunque un 
problema software - e pure da principianti.
 
Pero' e' anche vero che Stockfish e' testato su centinaia di macchine 
differenti, e l'aggiudicazione per il tempo e' avvenuta solo su quella 
con cui si svolge il TCE. E su nessuna altra. In particolare, dopo il 
fattaccio sono state fatte una quantita' enorme di stress-test in 
condizioni vicinissime allo zeitnot su una macchina a 20 processori, 
senza mai riuscire a riprodurre quel comportamento. In questo contesto, 
la frase "dipende dall'hardware" ci puo' stare.
 
Peraltro, concordo con te sul fatto che per sistemare questa
cosa "a modo" occorrerebbe intervenire sul codice e la cosa richiede 
tanto tempo, ma nella pratica la soluzione e' molto piu' semplice. 
Mentre nello stage precedente il parametro Move Overhead era 30 ms, ora 
e' stato portato ad 1000 ms, ossia un secondo di margine. Sara' pure un 
workaround, ma di fatto risolve tutto e subito, al costo di una frazione 
infinitesima di Elo.
 
Ciao, Bruno.
 
 


Mah, guarda, non è che.. faccio un paragone, forse infelice, ma secondo me
calzante rispetto al problema.
 
Questo tipo di "differenze tra teoria e pratica" è del tipo una di quelle
frasi che dici ai bambini "se non ti metti il caschetto per andare in bici
cadi e ti rompi la testa!". Poi nessuno se lo mette, o se lo mette e se lo
leva dietro l'angolo, e pure se si cade prima di rompersi la testa ce ne
vuole!
 
A livello economico (o di sviluppo) si dice che il valore atteso è dato
dalla figaggine data dal non mettersi il caschetto moltiplicato per la
probabilità di rompersi la testa.
 
Anche senza una laurea in economia, un ragazzino di otto anni il caschetto
non se lo metterà mai.
Poi, un giorno, al TG delle 20, passano la notizia di un ragazzino s'è rotto
la testa in bicicletta, dicendo "se avesse avuto il caschetto, forse si
sarebbe salvato!".
 
 
Quindi niente, quel tipo di gestione dei thread è un modo di fare abbastanza
comune, ed è sicuramente supportato da un sistema di sviluppo che premia
l'efficienza e la velocità sopra l'affidabilità, ma sbagliano tutti - o
meglio, visto che alla fine il premio non è per chi è più figo (scrive il
codice più in fretta) ma per chi torna a casa tutto intero (con un punto,
non perdendo per il tempo), di solito si spera che certi "consigli" vengano
seguiti.
 
Tutto qui :)
 
Ciao!
 
P.S.
Mai messo un caschetto in bici in vita mia.