Newsgroup: it.hobby.scacchi
Titolo: Strano comportamento Strelka6 con problema di scacchi

Ciao a tutti.
Come vi spiegate il seguente comportamento del motore Strelka6 ?
L'altro ieri ho impostato il seguente problema: FEN
 
n1QBq1k1/5p1p/5KP1/p7/8/8/8/8 w - - 0 1
 
In pratica vince il bianco. Dopo circa 8 ore di elaborazione, Strelka6 ha trovato la soluzione (è abbastanza complesso)....
 
Ho riprovato ieri sera a dare in pasto a Strelka6 lo stesso problema,
ma STAVOLTA non trova la soluzione nemmeno dopo 24 ore......
 
Che può essere?
Grazie
Giovanni
 

Giovanni
 
 
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---


 
Houdini_15a_w32 e Stockfisch-dd-32 concordano per 0,00 dopo 200
milioni di nodi processati
 

motore? 

Caspita, mi capita anche con Critter.......
Il bello e' che pulisco la cache.
Giovanni
 


 
 
ma quale sarebbe la vittoria del bianco che solo Strelka6 vede? Ho 
provato Houdini e Stockfish e danno sempre 0.0, per� non per otto ore :)
 

Esegui la mossa: Alfiere D8-C7 (sacrificio).
Guarda come prosegue il motore...................


 Guarda come prosegue il motore...................
 
Dxc8
 


2.gxf7+ Rh8 3.Ae5 Dc5 4.Ab2 e matto in 9 mosse. Bella :)


 
Fantastico! Io avevo solo provato Ae7, ma ho Houdini 1.5 con quattro 
processori reali che gira da più di mezz'ora e ancora non ha trovato la 
soluzione. E la posizione è anche abbastanza naturale, una dimostrazione 
che i motori devono girare a lungo!
 

 che i motori devono girare a lungo!
 
Casomai una dimostrazione che i motori non posseggono fantasia/ 
creatività. Per aperture e finali pescano dai database, per il 
mediogioco si affidano a tecniche di forza bruta.
 
Quando si usa un motore per analizzare una posizione, è sempre buona 
norma provare a portarla avanti per una mossa/una serie di mosse; poi 
tornare indietro e provare altre varianti.
 
Un po' come si fa quando si analizza con il solo ausilio di scacchiera, 
carta&penna (o memoria) e cervello.
 
Solo che il motore fa due cose in più:
 
1. Calcola meglio e più velocemente del 99% dei giocatori abituali.
2. Toglie di mezzo paura e insicurezza.
 
Un motore può essere utile (per provare velocemente delle idee che 
possono frullare in testa), ma zero istruttivo (no studio => no idee).

 ma STAVOLTA non trova la soluzione nemmeno dopo 24 ore......
Se hai un sistema multicore, i threads, potrebbero entrare in conflitto 
e dare risultati non prevedibili.
 
ciao e buoni scacchi.

 e dare risultati non prevedibili.
 
questa fregnaccia da dove l'hai tirata fuori? :-)
 
 
M.


da stockfish, il cui bench viene effettuato con 1 thread perch� 
altrimenti non da risultati "sicuri", ovvero imprevedibili.
 
ciao e buone fregnacce anche a te :)

 altrimenti non da risultati "sicuri", ovvero imprevedibili.
 
OK, stiamo parlando di ben altro. Il benchmark serve per misurare le 
performance di un algoritmo. Usando un singolo core si ottengono i 
benchmark "nudi e crudi" dell'algoritmo "nudo e crudo" in termini di 
nodi / secondo <<per singolo core>>.
 
Ma..., l'algoritmo � multi-threading. Ora, si potrebbe voler vedere come 
regge lo stesso algoritmo su architettura multi-core / multi-threading. 
Non vale infatti la regola che se ci sono N core (o N thread)... 
l'algoritmo va esattamente N volte pi� veloce. Ci sono conflitti di 
risorse condivise, locks, attese, ... I risultati sono meno affidabili 
perch� di solito :
 
1) nel sistema multi-core / multi-thread girano altri processi alla 
stessa priorit� dell'engine (non sempre l'utente pu� cambiare la 
priorit� dell'engine, ci vogliono privilegi particolari);
 
2) come gestire la distribuzione dei processi / sotto-processi (thread) 
nei core / thread della CPU � compito del sistema operativo; � pi� 
facile dare tutte le risorse di un core / thread a un singolo processo 
che fare la stessa cosa per pi� processi della stessa applicazione; su 
questo l'applicazione ha praticamente zero controllo, per cui non si pu� 
sapere a priori con che ordine, priorit� e risorse CPU verr� eseguito un 
singolo thread.
 
(Per inciso, ma la sostanza non cambia, multi-thread non � la stessa 
cosa di multi-core)
 
Ecco il perch� di quello che hai letto. Comunque, sempre per inciso, con 
Crafty puoi decidere quanti thread usare per il benchmark. In questo 
modo, dal numero di nodi / secondo, puoi capire come parametrizzarlo meglio.
 
 
 
Quello che hai letto VALE SOLO PER I BENCHMARK.
 
 
 
Questo non significa che le analisi date dall'engine quando gira in 
multi-thread sono A CAPOCCHIA :-)
 
E questo non vale solo per gli engine, ma per tutti i software 
multi-theading / multi-core.
 
Se fosse diversamente... te lo vedi un software che per colpa dei thread 
impazzisce e d� risultati IMPREVEDIBILI? Sai quanti incidenti ferroviari 
o aerei? :-)
 
Ci sono svariate tecniche consolidate da tempo per lo sviluppo di 
software e algoritmi multi-thread e multi-core: stai tranquillo che i 
risultati numerici sono STRA-ATTENDIBILISSIMI :-)
 
I limiti ci sono, semmai, nella gestione delle mappe di hash. Le mappe 
di hash sono come degli archivi di memoria ad accesso rapido grazie 
all'uso di una chiave di ricerca (codice hash). Ci si salvano dentro le 
analisi numeriche degli engine per evitare il ripetersi dei calcoli gi� 
fatti, durante l'esplorazione dell'albero di ricerca. C'� un ben noto 
algoritmo che associa ogni possibile posizione di scacchi ad una chiave 
di ricerca (Zobrist). Visto che le risorse di memoria dei computer sono 
limitate, questa associazione non � UNIVOCA. Potenzialmente vi 
potrebbero essere DUE (o pi�) posizioni con la stessa chiave. Quindi 
significa che due posizioni che manco si conoscono, potrebbero avere la 
stessa valutazione numerica nella mappa di hash, anche se in realt� 
hanno valutazioni completamente differenti. Questo potrebbe portare 
l'engine a pescare dalla tabella di hash un valore pre-calcolato... per 
una posizione... valore calcolato in precedenza per un'altra!
Quindi, ad esempio, dare per persa una posizione che magari � stravinta, 
o viceversa. Ecco dove sta l'imprevedibilit�. Ma non ha nulla a che 
vedere col multi-thread...
 
Questo caso descritto � rarissimo, ma � possibile. (Pi� grande � la 
tabella di hash, pi� bit usi per la chiave, meno probabile �)
Con questa remota possibilit� gli sviluppatori ci convivono oramai da 
tempo e in maniera pacifica.
 
 
 
 
Spero che sia tutto chiaro, ho cercato di tenere la spiegazione meno 
tecnica possibile e comprensibile...
 
saluti,
M.
 
P.S.: Ti arriver� la fattura di 15� per la consulenza a breve :-) :-)
 

 capire come parametrizzarlo meglio.
stockfish bench 1 256 15
analizza con 1 core, 256 mb di ram, 15 mosse di profondit� e ti dice il 
tempo il nr di nodi etc... puoi specificare un nr di core ram o depth 
diversa e altri parametri ancora che ultimamente sono stati documentati 
meglio.
su talkchessforum o sul forum di stockfish puoi trovare qualcosa 
sull'argomento hash tables che si deteriorano se sono lette da threads 
diversi etc.. etc..
Multi thread non � la stessa cosa che multicore, per� credo che quando 
specifichi threads = 4 in polyglot.ini per esempio (la riga � puramente 
descrittiva non ho voglia di andare a leggerla e copiarla corretta) 
intende il nr di core, i threads per core possono essere variabili a 
seconda dell'architettura del computer che stai usando, i core possono 
gestirne un numero variabile, forse da qui l'inesattezza delle mie 
affermazioni.
 
grazie della precisazione che reputo esaustiva e competente.
 
ciao e buoni scacchi

 risultati numerici sono STRA-ATTENDIBILISSIMI :-)
Ti faccio un esempio con gcc e stockfish senza cambiare i comandi o le 
istruzioni dentro i sorgenti, compila 5 volte stockfish cambiandogli 
nome, io uso master1,2,3,4,5.
Poi lancia questi 5 comandi 5 volte.
 
sudo nice -n -20 taskset -c 0 ./master1 perft 7 >/dev/null
sudo nice -n -20 taskset -c 0 ./master2 perft 7 >/dev/null
sudo nice -n -20 taskset -c 0 ./master3 perft 7 >/dev/null
sudo nice -n -20 taskset -c 0 ./master4 perft 7 >/dev/null
sudo nice -n -20 taskset -c 0 ./master5 perft 7 >/dev/null
 
vedrai che vanno a velocit� diverse,anche 3% 6% potrebbe essere un caso, 
lancia 5 volte gli stessi 5 eseguibili, curando di non chiamare mai 
consecutivamente lo stesso esebuibile e vedrai che uno degli eseguibili 
creati � effettivamente pi� veloce.
Nota che perft conta lo stesso numero di nodi e nel farlo stockfish usa 
1 solo core.
Se persino gcc non da risultati affidabili, generando gli eseguibili, e 
di sicuro � un buon compilatore, te l'immagini il casino che pu� 
succedere con gli scacchi i core e threads ?
 
Butta via delle 5 esecuzioni di ciascun eseguibile la migliore e la 
peggiore per ciascun eseguibile e fai una media delle 3 che restano 
potresti restare a bocca aperta a me � capitato.
 
Altro esempio, se fai l'istruzione
if (a == 1 && b == 2 && c == 3)
con il C o il C++ hai modo di prevedere cosa far� il compilatore, ovvero 
quale test && eseguir� prima considerando poi che nelle opzioni del 
compilatore ci sono delle ottimizzazioni marcate ?
 
i programmi di scacchi fanno cose strane, prima generano le posizioni 
illegali e poi controllano se sono legali, questo per sprecare meno 
tempo, costa meno nell'ambito del programma fare un controllo su dati 
corrotti a posteriori che non generare dati perfetti lentamente, forse 
l'uso dei core e dei threads � pi� snello essendo un programma di 
scacchi a rischio zero se capita qualcosa di non gestito una volta su un 
milione � accettabile? No, importa se si trova un modo di non perdere 
elo nel ridurre i rischi.
Anche quando i dati sono generati correttamente e scritti nelle 
hashtable l'iterazione di pi� threads potrebbe renderli non pi� integri 
ho letto qualcosa su talk chess sull'argomento, se vuoi approfondisci.
Di sicuro sono stato pressapochista, se mi prendi alla lettera, ho 
sparato un sacco di fregnacce, vai oltre cerca di dare un senso al 
discorso :).
Poi io uso linux, magari anzi sicuramente su windows l'entropia aumenta. :D
 
ciao e buoni scacchi :)

> risultati numerici sono STRA-ATTENDIBILISSIMI :-)
 
Argomento interessante. Per quanto riguarda l'attendiblita' concordo.
 
Pero' il "determinismo" del trovare la soluzione e' un'altra cosa. Cioe':
a mio avviso e' lecito che ogni volta che il programma ci prova ci metta un tempo diverso, e che a volte riesca a risolverlo e a volte no. (forse ancora a maggior ragione se multithread)
 
E' come cercare una pentola d'oro in un albero infinito, a volte la trovo subito, a volte ci metto di piu', a volte non la trovo.
 
:-)
 
ciao
Marco