ARGOMENTO:

C'è anche il fattore Linux Vs. Windows, a quanto vedo. In effetti, le due app potrebbero essere diverse.

come al solito Nubman ci azzecchi sempre
appena ho settato l'ìutilizzo cpu al 50% le 6 wusimultanee hanno accellerato fino ad arrivare a 2400s
ho fatto 2 calcoli e mi conviene tenere tutti i 12 thread attivi.
-
12 thread: 3700s/ 60= 61min 1440min / 61=23,6 Wu per core al giorno *12= 283wu consegnate al giorno
-6 thread: 2400s/60=40min 1440/40=36wu per core al giorno *6= 216wu consegnate al giorno
quelle 65-70 wu in più sono circa 2400cr
ovviamente è un discorso teorico senza tenere in considerazione i wingman

PS: farò ancora dei test sull'overclock perchè mi sembra strano che non migliori le prestazioni

Buro87 ha scritto:

-12 thread: 3700s/ 60= 61min 1440min / 61=23,6 Wu per core al giorno *12= 283wu consegnate al giorno
-6 thread: 2400s/60=40min 1440/40=36wu per core al giorno *6= 216wu consegnate al giorno

Quindi attivando l'smt si ottiene: (283/216)=1.31
Cioè un rac aumentanto del 30% circa.
Interessante perché simile alle cpu intel, forse leggermente migliore.
Grazie.

Buro87 ha scritto:

come al solito Nubman ci azzecchi sempre
appena ho settato l'ìutilizzo cpu al 50% le 6 wusimultanee hanno accellerato fino ad arrivare a 2400s
ho fatto 2 calcoli e mi conviene tenere tutti i 12 thread attivi.

Che c...

Disabilitando i 6 core logici a livello più basso (firmware, cioè bios/uefi), se si può, per esperienza posso dire che si guadagna qualcosina in più.
Tuttavia, come hai anche tu riscontrato, non c'è guadagno nella produttività, anzi! Soltanto su applicazioni matematiche ottimizzate si riesce quasi ad appianare la differenza tra SMT (mi sembra di aver capito che si chiami così) on e off.
Anche sul mio i7 c'è una differenza di produttività quando attivo/disattivo l'HT da uefi, soprattutto per le applicazioni che non elaborano stressando la CPU al massimo. Altra cosa che ho osservato è una riduzione importante delle temperature, sui consumi invece non ricordo di aver fatto test a riguardo. Per esempio qualche tempo fa su Asteroids ho osservato 98tasks/day e Temp=70°C con HT off; 103tasks/day e Temp=77°C con HT on. Ovvio che in tal caso si sceglie la prima opzione.

Nubman ha scritto:

Buro87 ha scritto:

come al solito Nubman ci azzecchi sempre
appena ho settato l'ìutilizzo cpu al 50% le 6 wusimultanee hanno accellerato fino ad arrivare a 2400s
ho fatto 2 calcoli e mi conviene tenere tutti i 12 thread attivi.

Che c...

Disabilitando i 6 core logici a livello più basso (firmware, cioè bios/uefi), se si può, per esperienza posso dire che si guadagna qualcosina in più.
Tuttavia, come hai anche tu riscontrato, non c'è guadagno nella produttività, anzi! Soltanto su applicazioni matematiche ottimizzate si riesce quasi ad appianare la differenza tra SMT (mi sembra di aver capito che si chiami così) on e off.
Anche sul mio i7 c'è una differenza di produttività quando attivo/disattivo l'HT da uefi, soprattutto per le applicazioni che non elaborano stressando la CPU al massimo. Altra cosa che ho osservato è una riduzione importante delle temperature, sui consumi invece non ricordo di aver fatto test a riguardo. Per esempio qualche tempo fa su Asteroids ho osservato 98tasks/day e Temp=70°C con HT off; 103tasks/day e Temp=77°C con HT on. Ovvio che in tal caso si sceglie la prima opzione.

la questione delle temperature e consumi (da HWMonitor) l'ho notata anche io:
-12 thread: 51°C e circa 58w
-6 thread: 46°C e circa 50w

comunque si seguito posto la risposta di Daniel sul forum TN-grid


TN-Grid app is very memory-intensive. One person from my team wrote that on his Xeon 14c/28t (I do not know exact model, probably it is E5-2683 v3) 4 TN-Grid WUs consumed all available memory bandwidth. So when you hit this limit, increasing CPU speed will not help, it will faster wait for memory

Edit: when you set CPU usage to 50%, app will be able to get data from memory faster (less apps will compete for the same limited bandwidth), every app instance could use more cache (additionally helping with loading data), plus CPU resources will not be shared between two apps (SMT/HT does not improve speed twice, usually it is much less).

If you want to improve speeds, use fastest possible memory, and overclock it if possible


in pratica conta moltissimo la frequenza ram
ho fatto un paio di test (sempre con 12 thread attivi)
-ram a 2133mhz -> wu completate in circa 4400s
-ram a 2933mhz -> wu completate in 3700s

quando i prezzi delle ram torneranno accettabili , aggiungerò un'altro modulo per sfruttare il dual channel

Buro87 ha scritto:

la questione delle temperature e consumi (da HWMonitor) l'ho notata anche io:
-12 thread: 51°C e circa 58w
-6 thread: 46°C e circa 50w

I valori di consumo sono all'interno del TDP dichiarato di 65W, molto interessante.
Prevedo scimmie in aumento.

in pratica conta moltissimo la frequenza ram
ho fatto un paio di test (sempre con 12 thread attivi)
-ram a 2133mhz -> wu completate in circa 4400s
-ram a 2933mhz -> wu completate in 3700s

Mi pare che la differenza sia notevole.

quando i prezzi delle ram torneranno accettabili , aggiungerò un'altro modulo per sfruttare il dual channel

Occhio che è bene prendere ram identica alla vecchia ma se aspetti troppo, il modello che hai comprato andrà fuori produzione.
A quel punto ti converrà vendere il modulo singolo e comprare un kit con due moduli. IMO.

Buro87 ha scritto:

la questione delle temperature e consumi (da HWMonitor) l'ho notata anche io:
-12 thread: 51°C e circa 58w
-6 thread: 46°C e circa 50w

[...]

in pratica conta moltissimo la frequenza ram
ho fatto un paio di test (sempre con 12 thread attivi)
-ram a 2133mhz -> wu completate in circa 4400s
-ram a 2933mhz -> wu completate in 3700s

Intanto hai potuto constatare che forse quei due host non vanno più veloci per via dell'overclock di CPU o RAM.

Inoltre, io non mi fossilizzerei sui meri tempi di completamento delle workunit. È vero che non hai raddoppiato le prestazioni (cosa che, come dicevo, si raggiunge o quasi in pochi casi), ma è anche vero che hai abbassato i consumi.
Usando 6 core una singola wu consuma 2400s*50W / 6 = 0.67h * 8.33W = 5.56Wh
Usando 12 core una singola wu consuma 3700s*58W / 12 = 1.03h * 4.83W = 4.97Wh

In pratica la soluzione dei 6 core ha una efficienza delll'89% rispetto a quella dei 12 core, con il pro di mantenere la CPU a una temperatura di 5°C inferiore. Per esempio in estate potrebbe essere meglio disabilitare l'SMT così da risparmiare sul raffreddamento, qualora usassi un condizionatore.

Nubman ha scritto:

Buro87 ha scritto:

la questione delle temperature e consumi (da HWMonitor) l'ho notata anche io:
-12 thread: 51°C e circa 58w
-6 thread: 46°C e circa 50w

[...]

in pratica conta moltissimo la frequenza ram
ho fatto un paio di test (sempre con 12 thread attivi)
-ram a 2133mhz -> wu completate in circa 4400s
-ram a 2933mhz -> wu completate in 3700s

Intanto hai potuto constatare che forse quei due host non vanno più veloci per via dell'overclock di CPU o RAM.

Inoltre, io non mi fossilizzerei sui meri tempi di completamento delle workunit. È vero che non hai raddoppiato le prestazioni (cosa che, come dicevo, si raggiunge o quasi in pochi casi), ma è anche vero che hai abbassato i consumi.
Usando 6 core una singola wu consuma 2400s*50W / 6 = 0.67h * 8.33W = 5.56Wh
Usando 12 core una singola wu consuma 3700s*58W / 12 = 1.03h * 4.83W = 4.97Wh

In pratica la soluzione dei 6 core ha una efficienza delll'89% rispetto a quella dei 12 core, con il pro di mantenere la CPU a una temperatura di 5°C inferiore. Per esempio in estate potrebbe essere meglio disabilitare l'SMT così da risparmiare sul raffreddamento, qualora usassi un condizionatore.

visto che l'overclock della cpu è inutile, magari proverò a fare una prova in underclock/undervolt

Come ho scritto sul forum ufficiale, cosa ci aspetta il futuro??
Dai, dai, che arrivo al milione di punti!!!

Ho i core a secco da alcuni giorni.....aspettiamo che riparta il lavoro.

in effetti è qualche mese che sta girando a bassissimo regime

per fortuna non l'abbiamo messo come progetto per il nostro challenge RLM (avevo notato che anche in quel periodo era quasi a secco)

Il lavoro mi sembra che non manca, dev'essere il solito problema con il generatore di workunit che non sta al passo.
Fino ad una settimana fa c'erano delle wu lunghe e si era accumulata una bella scorta ma adesso sono particolarmente corte ed è diventato quasi impossibile acchiapparne

rattorosso ha scritto:

Fino ad una settimana fa c'erano delle wu lunghe e si era accumulata una bella scorta ma adesso sono particolarmente corte ed è diventato quasi impossibile acchiapparne

Oggi son riuscito a beccare delle Vitis....

boboviz ha scritto:

Oggi son riuscito a beccare delle Vitis....

...è una roba contagiosa?

rattorosso ha scritto:

Il lavoro mi sembra che non manca, dev'essere il solito problema con il generatore di workunit che non sta al passo.
Fino ad una settimana fa c'erano delle wu lunghe e si era accumulata una bella scorta ma adesso sono particolarmente corte ed è diventato quasi impossibile acchiapparne

lo penso anche io speriamo ottimizzino presto il generatore di WU
le wu lunghe erano Ec (Escherichia coli) che erano più complesse ma poco numerose (solo 117 geni da analizzare)
quelle di adesso sono Vv ( Vitis venifera) che sono molte di piu (28000 geni) ma durano troppo poco per fa si che il generatore di WU faccia una scorta

comunque in ottica challenge, con le wu Ec, non credo che ci siano problemi

Si, il problema e` sempre il solito (il generatore di lavoro che non ce la fa a soddisfare la richiesta...)

valterc ha scritto:

Si, il problema e` sempre il solito (il generatore di lavoro che non ce la fa a soddisfare la richiesta...)

banalizzando, quale sarebbe la via più "semplice"?
1) ottimizzare il generatire WU
2) rendere piu complesse ( e quindi più lunghe) le wu Vv

1 (forse) penso che riscrivendolo da zero (ora e` in python) in C++ la cosa migliorerebbe (ma non e` banale, la creazione di wu e` intrinsecamente complicata).
2 un pochino si può fare e lo abbiamo fatto in passato (rendere più complesse le wu) ovviamente se ha un qualche senso scientifico.
3 aggiungere nuovo hardware per far girare più generatori in parallelo.

la 'velocità' del calcolo dipende da tanti fattori, il principale e` la 'forma' del dataset contenente l'espressione genica del singolo organismo. In teoria pero`, in tempi brevi, dovremmo iniziare una serie nuova di esperimenti su un organismo che sappiamo già che ` 'complesso'......

Buro87 ha scritto:

valterc ha scritto:

Si, il problema e` sempre il solito (il generatore di lavoro che non ce la fa a soddisfare la richiesta...)

banalizzando, quale sarebbe la via più "semplice"?
1) ottimizzare il generatire WU
2) rendere piu complesse ( e quindi più lunghe) le wu Vv

Curiosità: avete mai pensato di riscrivere solamente le funzioni più "cariche" computazionalmente in C++ e richiamarle in Python implementando una estensione Python-C++ ?

Premesso (e lo scrivo dopo?) che non mi è nota la ragione per cui vorreste passare al C++ (immaginavo l'efficienza), il mio intervento è giusto per dare un'idea in più al brainstorming.

valterc ha scritto:

3 aggiungere nuovo hardware per far girare più generatori in parallelo.

a questa ipotesi non avevo pensato..
parrebbe essere la soluzione piu "flessibile" e attuabile più "facilmente"
-con esperimenti complessi (come Ec) fare andare il solito generatore
-con esperimenti veloci (come Vv) fare andare piu generatori in parallelo, solo quando sono effettivamente necessari

comunque ottimo lavoro, la mia richiesta di WU da TN-Grid è sempre aperta