ARGOMENTO:

Un'idea per il Team, per ottimizzare le risorse e elaborare piu' veloce.

Ho provato a fare questa prova in proprio. Dall'inizio del mese di aprile ho messo tutti i processori con SSE4 (tipicamente Core2Duo) sul Einstein@home e tutti quelli senza (P4, Xeon ecc) su ABC@home.
I crediti e quindi spero anche la velocita' di elaborazione sono saliti del 25% (RAC da 30000 a 40000 circa):



Se chiedessimo ai membri del Team di seguire una strategia di questo tipo potremmo avvanggiare il Team ma sopratutto l'efficienza del calcolo.

Che ne dite ?

Ciao,
Ale

P.S. Naturalmente si potrebbe perfezionare la cosa valutando attentamente l'efficienza di altri tipi di processori su tutti i progetti supportati dal Team.

Io sul sistema a 64bit seguo principalmente ABC@home e Einstein@Home che ottengono validi benefici. Sugli altri sistemi seguo Rosetta (perchè mi piace). Su tutti LHC.

Se trovassi un qualche Core2Duo abbandonato valuterò l'idea di mettere sotto Einstein... ma davvero sfrutta le SSE4?

Mah, sai Ale, non so quanto potrebbe essere seguita questa idea...

Certo, sapere che il proprio PC potrebbe rendere di più su quel progetto piuttosto che su quell'altro può essere un'indicazione utile, ma poi è l'utente che sceglie dove girare le proprie risorse di calcolo.

Se mi piace il progetto X magari elaboro per quello anche se il mio PC ha un RAC leggermente più alto sul progetto Y.

Ovviamente il Team può dare delle indicazioni di massima e consigliare gli utenti su quale può essere il miglior progetto per il proprio PC.

Poi si possono lanciare gli appelli al RAC, vedi alla voce "Progetto del Mese", dove il Team per un mese chiede potenza su quello specifico progetto per recuperare posizioni, scalare le classifiche, ecc. A quel punto la "militanza combattente" gira le proprie macchine e si concentra su quel progetto. Ma il tutto resta sempre nell'ambito della libera scelta degli utenti.

Dire ad un utente "Hai un Quad, elabora sul progetto X" o "Hai un AMD scrauso, vai sul progetto Y", mi sembra un po' eccessivo...

In più è riduttivo! L'efficienza di una macchina varia anche in termini di memoria, di cache, ecc. Bisogna andare anche oltre alle singole istruzioni implementate nel PC per valutare in maniera corretta.

Una cosa che viene già fatta, all'interno dei thread ufficiali dei progetti, è quella di sconsigliare determinati progetti, esosi di risorse, a determinate categorie di macchine (con poca memoria, con processori anzianotti, ecc.).

Te fai benissimo a girare le macchine che hai a disposizione in base alle loro caratteristiche... Ma ad un utente che ha un solo PC, magari vecchiotto, non puoi dire "Vai su X che il tuo PC rende di più!"... Se lui vuole portare a termine una WU di Climate, deve poter essere libero di farlo... Certo, noi gli diremo che può scegliere altri progetti più adatti al proprio hardware e di solito riusciamo anche ad essere convincenti... ma la scelta finale spetta sempre all'utente, ci mancherebbe!

Gli altri che ne pensano? Altri pareri?

LucaB76 ha scritto:

Poi si possono lanciare gli appelli al RAC, vedi alla voce "Progetto del Mese", dove il Team per un mese chiede potenza su quello specifico progetto per recuperare posizioni, scalare le classifiche, ecc. A quel punto la "militanza combattente" gira le proprie macchine e si concentra su quel progetto. Ma il tutto resta sempre nell'ambito della libera scelta degli utenti.

Certo, e' quello che intendevo anche io, infatti scrivevo, chiedere non imporre. Direi addirittura solo "suggerire", e con una pagina apposta che mostri l'utilizzo di RAM di ogni progetto e la sua resa relativa ad ogni specifico processore.

Piu' che altro la mia proposta era quella di iniziare a costruire una tabella che incroci RAC con CPU/RAM, raccolta in un modo un minimo rigoroso (media su un tot di WU per un minimo di CPU time). Sia con numeri assoluti che relativi (percentuali) per poter fare i confronti.

Tanto per iniziare a vedere cosa ne esce fuori. Posso iniziare a fornire io un po' di dati ...

Poi da quello che ne viene fuori vediamo se ne vale la pena o meno.
Nel mio caso un 25% non e' stato poco ... teoricamente esteso a tutto il team significherebbe un +100000 nel RAC.

Ciao,
Ale

Venturini Dario ha scritto:

Io sul sistema a 64bit seguo principalmente ABC@home e Einstein@Home che ottengono validi benefici. Sugli altri sistemi seguo Rosetta (perchè mi piace). Su tutti LHC.

Se trovassi un qualche Core2Duo abbandonato valuterò l'idea di mettere sotto Einstein... ma davvero sfrutta le SSE4?

Questo non lo so, ma e' un ipotesi plausibile che mi viene in mente, vedi i numeri:

einstein + XP + E4300 = RAC 900
einstein + Suse 9 + E4300 = RAC 1500
ABC + XP + E4300 = RAC 600

La situazione si ribalta esattamente con lo stesso confronto ABC/einstein su P4 o su Xeon (in cui prevale il P4/Xeon).

La differenza che salta all'occhio e' che Xeon e P4 non hanno le SSE4.
Un'altra ipotesi potrebbe anche essere che ABC lavora principalmente sugli interi e einstein sui float. E che il rapporto Gflop/Gint dei due processori sia opposto ... in ogni caso se il rapporto non si invertisse ma rimanesse uguale potresti dedurre che l'ABC e' meno ottimizzato in assoluto o semplicemente che il server del progetto rilascia meno crediti, ma se il rapporto si ribalta significa se un tipo di processore rende di piu' con un eseguibile e viceversa.
Poi il perche' non e' strettamente indispensabile saperlo ... giusto ?
L'importante e' ottimizzare.


Un +25% vale quanto o piu' di un overclock e costa meno watt

Ciao,
Ale

astroale ha scritto:

Piu' che altro la mia proposta era quella di iniziare a costruire una tabella che incroci RAC con CPU/RAM, raccolta in un modo un minimo rigoroso (media su un tot di WU per un minimo di CPU time). Sia con numeri assoluti che relativi (percentuali) per poter fare i confronti.

Tanto per iniziare a vedere cosa ne esce fuori. Posso iniziare a fornire io un po' di dati ...
Ciao,
Ale

Potrebbe essere sicuramente un valido aiuto nella scelta del progetto più idoneo con un dato PC.

Il guaio è che per fare un lavoro del genere...

- Occorre girare i PC da testare su un solo progetto;
- Mantenerli tutti attivi 24h/24 per giorni, in attesa di un RAC stabile;
- Fare in modo che non restino MAI senza lavoro, altrimenti bisogna ricominciare;
- Non dovranno verificarsi interruzioni nell'elaborazione (blackout, deschedulazioni, guasti, ecc.);
- Raccogliere i dati;
- Passare al progetto successivo;

Anche ammesso di trovare un po' di volontari disposti a partecipare all'iniziativa, portando avanti i test in parallelo, quante configurazioni Processore/Cache/RAM/Sist.Oper. andrebbero testate? Se vuoi differenziare le architetture... ne occorrono parecchie...

Senza contare che ogni poco i progetti aggiornano l'applicazione (come è giusto che sia...), rendendo nulli i valori precedentemente calcolati...

Infine va messo in conto che su progetti con lavoro disponibile ad intermittenza (LHC, SIMAP, Cosmology, uFluids, Predictor, ecc.) il RAC non si stabilizza mai!!

Io la vedo durissima...

Non fraintendermi, non sto dicendo NO aprioristicamente!! Dico solo che per dare valori affidabili occorrerebbero ingenti risorse hardware e volontari per un bel po' di tempo... e poi magari tempo 15gg il progetto X rilascia la nuova applicazione ottimizzata per un altro set di istruzioni e...

Volontari... fatevi avanti e parliamone!!

astroale ha scritto:

Questo non lo so, ma e' un ipotesi plausibile che mi viene in mente, vedi i numeri:

einstein + XP + E4300 = RAC 900
einstein + Suse 9 + E4300 = RAC 1500
ABC + XP + E4300 = RAC 600

La situazione si ribalta esattamente con lo stesso confronto ABC/einstein su P4 o su Xeon (in cui prevale il P4/Xeon).

Sicuro che Suse non fosse a 64bit? Perchè io ho notato ad esempio che Einstein@Home su XP 32bit ci mette circa il doppio a completare una WU che su Ubuntu 64bit.

Venturini Dario ha scritto:

astroale ha scritto:

Questo non lo so, ma e' un ipotesi plausibile che mi viene in mente, vedi i numeri:

einstein + XP + E4300 = RAC 900
einstein + Suse 9 + E4300 = RAC 1500
ABC + XP + E4300 = RAC 600

La situazione si ribalta esattamente con lo stesso confronto ABC/einstein su P4 o su Xeon (in cui prevale il P4/Xeon).

Sicuro che Suse non fosse a 64bit? Perchè io ho notato ad esempio che Einstein@Home su XP 32bit ci mette circa il doppio a completare una WU che su Ubuntu 64bit.

Beh, una WU non fa' primavera, devi guardare il RAC o cmq calcolare a mano il RAC su almeno una ventina di WU. Ho letto in giro che in genere nel passaggio da 32 a 64 sullo stesso S.O. dovresti guadagnare pochino al max un 30%, non il 100%.

64 bit:
direi di no, visto che si tratta di un Core2Duo E4300, mi confermi che non e' un 64 bit ? Inoltre uname mi da:

Linux localhost 2.6.5-7.244-smp #1 SMP Mon Dec 12 18:32:25 UTC 2005 i686 i686 i386 GNU/Linux

Cmq ti confermo che ho vari E4300 su linux (suse fedora e ubuntu) e altri identici su XP e' c'e' questa differenza nel RAC.

Avevo delle mezze ipotesi per quel che succede, vedi anche qui:
www.boincitaly.org/i...Itemid=2&func=view&id=4236&catid=10#4236

ma rimangono delle ipotesi.

Ciao,
Ale

LucaB76 ha scritto:

astroale ha scritto:

Piu' che altro la mia proposta era quella di iniziare a costruire una tabella che incroci RAC con CPU/RAM, raccolta in un modo un minimo rigoroso (media su un tot di WU per un minimo di CPU time). Sia con numeri assoluti che relativi (percentuali) per poter fare i confronti.

Tanto per iniziare a vedere cosa ne esce fuori. Posso iniziare a fornire io un po' di dati ...
Ciao,
Ale

Potrebbe essere sicuramente un valido aiuto nella scelta del progetto più idoneo con un dato PC.

Il guaio è che per fare un lavoro del genere...

- Occorre girare i PC da testare su un solo progetto;
- Mantenerli tutti attivi 24h/24 per giorni, in attesa di un RAC stabile;
- Fare in modo che non restino MAI senza lavoro, altrimenti bisogna ricominciare;
- Non dovranno verificarsi interruzioni nell'elaborazione (blackout, deschedulazioni, guasti, ecc.);
- Raccogliere i dati;
- Passare al progetto successivo;

Anche ammesso di trovare un po' di volontari disposti a partecipare all'iniziativa, portando avanti i test in parallelo, quante configurazioni Processore/Cache/RAM/Sist.Oper. andrebbero testate? Se vuoi differenziare le architetture... ne occorrono parecchie...

Senza contare che ogni poco i progetti aggiornano l'applicazione (come è giusto che sia...), rendendo nulli i valori precedentemente calcolati...

Infine va messo in conto che su progetti con lavoro disponibile ad intermittenza (LHC, SIMAP, Cosmology, uFluids, Predictor, ecc.) il RAC non si stabilizza mai!!

Io la vedo durissima...

Non fraintendermi, non sto dicendo NO aprioristicamente!! Dico solo che per dare valori affidabili occorrerebbero ingenti risorse hardware e volontari per un bel po' di tempo... e poi magari tempo 15gg il progetto X rilascia la nuova applicazione ottimizzata per un altro set di istruzioni e...

Volontari... fatevi avanti e parliamone!!

Ok, quasi tutte la macchine che uso sono nelle condizioni ottimali per valutare il RAC, cio' non toglie che quando ho fretta uso un metodo approssimato ma che, ho potuto verificare, da risultati attendibili:

1 - copia e incolla dalla pagina html dei result sul server di almeno 20 righe con "credit granted" assegnato, in un file .txt
2 - modifica (es. con 3 passi in gvim) del file .txt in .csv
3 - import del file cvs in excel (o equivalente)
4 - aggiunta di due formulette per fare somma e media

O 20 righe (WU) o se le WU sono molto corte un numero sufficiente ad avere almeno un giorno di CPU time.

Ciao,
Ale

I Core2Duo hanno il supporto per i 64bit, di questo son sicuro.
Per quanto riguarda i boost da 32 a 64bit non so che dirti. Ma il dimezzamento dei tempi di elaborazione su Einstein non è stato un caso isolato, ho elaborato 5 WU su XP e 5 su Ubuntu64bit per controllare..

Venturini Dario ha scritto:

I Core2Duo hanno il supporto per i 64bit, di questo son sicuro.
Per quanto riguarda i boost da 32 a 64bit non so che dirti. Ma il dimezzamento dei tempi di elaborazione su Einstein non è stato un caso isolato, ho elaborato 5 WU su XP e 5 su Ubuntu64bit per controllare..

Mah, ho fatto un giro sul sito e mi pare di capire che i 64 sono supportati nel senso che anche se hai un SO 64 riesci lo stesso a scaricare il client che e' a 32 bit, leggi qui:

einstein.phys.uwm.ed...rum_thread.php?id=1910&nowrap=true#74892

infatti nella pagina delle applicazioni:

einstein.phys.uwm.edu/apps.php

non vedo versioni a 64 bit.

Vi torna, o e' troppo tardi e il mio neurone e' in free-running ?

Ciao,
Ale

In effetti hai ragione. Boh! Vuoi che sia solo il fatto del bind progetto-core? O le librerie più veloci? Perchè io non ho le SSE4, uso un Athlon64...

Venturini Dario ha scritto:

In effetti hai ragione. Boh! Vuoi che sia solo il fatto del bind progetto-core? O le librerie più veloci? Perchè io non ho le SSE4, uso un Athlon64...

Mumble ... dual core ?

Sì, Athlon64 3800X2 @2500Mhz, ma anche su XP usavo la stessa configurazione (e frequenza di clock). Inoltre non è che l'altro core sia a riposarsi.. ABC@Home

Si ma se XP continua a rischedulare i due processi scambiandoli di core alla fine e' probabile che il tutto si disottimizzi parecchio.

Sarebbe bello, avendo un po' di tempo cercare la fonte di questa "news" per verificarla (purtroppo non ricordo dove l'avevo letta) e poi se e' vera ravanare sul sito MS per vedere se esiste una patch un workaround o qualsiasi altro cazzobuffo che consenta di mettere in bolla XP.


Ciao,
Ale

astroale ha scritto:

Si ma se XP continua a rischedulare i due processi scambiandoli di core alla fine e' probabile che il tutto si disottimizzi parecchio.

Sarebbe bello, avendo un po' di tempo cercare la fonte di questa "news" per verificarla (purtroppo non ricordo dove l'avevo letta) e poi se e' vera ravanare sul sito MS per vedere se esiste una patch un workaround o qualsiasi altro cazzobuffo che consenta di mettere in bolla XP.


Ciao,
Ale

Tempo fa erano stati fatti dei client boinc che gestivano l'affinità con la cpu e la priorità dei processi dei client, però da oltre 2 anni non sono più stati aggiornati, probabilmente perchè il vantaggio era così elevato....sinceramente io non li ho mai provati....sarebbe interessante fare dei test...

GHz ha scritto:

Tempo fa erano stati fatti dei client boinc che gestivano l'affinità con la cpu e la priorità dei processi dei client, però da oltre 2 anni non sono più stati aggiornati, probabilmente perchè il vantaggio era così elevato....sinceramente io non li ho mai provati....sarebbe interessante fare dei test...

Casomai il vantaggio NON era così elevato!

Io per un po' provai il Manager di TruXoft... era il periodo dei primi client ottimizzati di Seti... la cosa finì perchè quel Manager, oltre ad avere features interessanti come l'affinità task-cpu, aveva anche il compito di gonfiare opportunamente i claimed credits per evitare che i tempi ridotti delle applicazioni ottimizzate facessero precipitare i crediti ricevuti (che allora dipendevano sempre da TempoImpiegato*Benchmark). Ovviamente qualcuno iniziò a gonfiare in modo spropositato i crediti richiesti e quel Manager venne messo al bando.

Ora come ora non credo che il BOINC Manager sfrutti un determinato core per una determinata WU tenendola sempre lì in esecuzione. Al contrario, tempo fa mi rimasero in esecuzione solo tre task sul Quad e notai che le percentuali d'uso dei core non erano 100%-100%-100%-0% (come mi sarei aspettato), ma variavano... segno che le istruzioni richieste dalle WUs venivano assegnate ai core in modo disorganizzato, di certo non ottimizzato... O meglio, forse erano ottimizzate secondo le direttive di Intel, ma forse non troppo d'accordo con l'ottimizzazione che vorremmo per BOINC.

Del resto se una WU fosse lockata su un preciso core e tutti i core venissero lockati con le WUs di BOINC... come potremmo continuare ad utilizzare la macchina? La bassa priorità con cui girano i processi di BOINC permette all'utente di continuare a gestire la macchina senza neanche accorgersi che BOINC gira sul PC ed è ovvio che i processi vengano continuamente schedulati ora su un core e ora su un altro...

In fondo BOINC è pensato per sfruttare i tempi morti del PC... mi sembra troppo chiedergli di ottimizzare l'uso del processore, no?

Sono d'accordo, ma per quanto riguarda i vari livelli di cache (es nel mio q6600) quando i dati devono essere passati da una cache all'altra si perde del tempo, forse sarebbe meglio far progredire la Wu assegnata la core "libero" invece di spostare tutto e far partire quella "di turno". Non lo so, ci sarà poi alla fine un guadagno reale?
ciao

LucaB76 ha scritto:

GHz ha scritto:

Del resto se una WU fosse lockata su un preciso core e tutti i core venissero lockati con le WUs di BOINC... come potremmo continuare ad utilizzare la macchina? La bassa priorità con cui girano i processi di BOINC permette all'utente di continuare a gestire la macchina senza neanche accorgersi che BOINC gira sul PC ed è ovvio che i processi vengano continuamente schedulati ora su un core e ora su un altro...

Non vorrei genererare equivoci sulla parola "lock", cio' non vuol dire che gli altri processi iniziano ad avere difficolta' ad accedere a quel particolare core, o che la priorita' del client si alza. Semplicemente come succede sotto Linux, il processo A se ha a disposizione enne secondi di idle sul core 0 e sul core 1, non viene spostato ogni tot millisec da uno all'altro ma viaggia sempre sullo stesso consentendo di sfruttare le pipeline interne della CPU.
Questo non comporta nessun rallentamento dei processi a priorita' normal, anzi se anche loro fossero schedulati allo stesso modo, nel caso iniziassero a richiedere un uso continuativo della CPU anche per poche frazioni di sec, andrebbero piu' veloci.

In fondo BOINC è pensato per sfruttare i tempi morti del PC... mi sembra troppo chiedergli di ottimizzare l'uso del processore, no?

Attenzione, a BOINC come scheduler, in questo caso non chiediamo proprio nulla, lui poveretto e' totalmente incolpevole perche' schedula i client (a livello user) su tempi biblici rispetto allo scheduler del kernel di XP che (sarebbe) il responsabile di questo problema. Infatti solo il kernel puo' prendere un processo e decidere sul quale core farlo girare, BOINC puo' solo fare il run, il kill ed eventualmente il suspend.

Cmq ripeto cme che queste sono ipotesi, perche' sono basate su fonti non verificate.

Quindi ... chi ha un po' di tempo per navigare, scandagliare forum, newsgroup MS e siti ufficiali ? (per verificare la questione e eventualmente scovare una soluzione).
Sarebbe ottimo se lavorasse in una ditta con abbonamento MSDN o con altri rapporti diretti con MS per avere notizie di prima mano ... sarebbe un vero filantropo e avrebbe la riconoscenza di tutti i membri del team multicore-XP-dotati

Ciao,
Ale

Martinelli ha scritto:

Sono d'accordo, ma per quanto riguarda i vari livelli di cache (es nel mio q6600) quando i dati devono essere passati da una cache all'altra si perde del tempo, forse sarebbe meglio far progredire la Wu assegnata la core "libero" invece di spostare tutto e far partire quella "di turno". Non lo so, ci sarà poi alla fine un guadagno reale?
ciao

Il guadagno reale c'e' e non e' poco, vedi la tabella.
Sono tutte macchine che girano sempre, tranne la terza (linux) in classifica di RAC che si ferma 12 ore al giorno da lunedi' a venerdi.
In pratica le macchine XP (identiche come HW) e' come se si fumassero le 60 ore settimanali in questione:

astroale.altervista.org/einstein_at_home_su_E4300/index.htm

Ciao,
Ale