Prime Cores V1.0 Freeware

Totocellux

apix_1024 ha scritto:

seguendo questa attentissima analisi sarebbe anche spiegato il lentissimo phenom II X4 che ho io nei vostri confronti...
:muro:

si Aris, nell'ottica di ciò che ritengo possa accadere con questo tipo di elaborazioni, una quantità doppia di entrambe le cache di 1° livello del Phenom-II (64KB sia dati che istruzioni, rispetto ai 32KB Intel) influisce molto poco nella capacità ed efficienza elaborativa: considerato che è organizzata solo su due blocchi, dovrebbe praticamente sopravvenire un continuo di cache miss e penalty, cioè cpu praticamente ferma ad attendere le sostituzioni operate dalla cache stessa

Le085

Totocellux ha scritto:

si Antonio, lo dicevo precedentemente: in elaborazioni di questo tipo, molto brevi, che spostano pochissimi dati e soprattutto che (come mi è sembrato dal listato che bonis62 ha postato) utilizzano svariate istruzioni in rapidissima successione, un ruolo molto importante nella efficienza elaborativa è rappresentato, in talune circostanze, dalla lunghezza della pipeline e dalla quantità e soprattutto dal numero di blocchi dell'associatività in cache.
In caso di miss cache dovuto alle numerose istruzioni, incorrerebbe purtroppo la necessità della continua sostituzione dei blocchi, e del quasi certo relativo stallo la cpu (e conseguente miss penalty).

Per diminuire tale evenienza in elaborazioni come la nostra, dovrebbe poter aiutare un elevato valore di associatività.

In questo particolare ambito, se ho ben compreso, sarebbe quindi spiegata la minore efficienza di un Core i7 rispetto ad un Core 2:

Core i7 (per ciascun core)

32KB di cache associativa a 8 vie per i dati

32KB di cache associativa a 4 vie per le istruzioni

Core 2 (per ciascun core)

32KB di cache associativa a 8 vie per i dati

32KB di cache associativa a 8 vie per le istruzioni

Pertanto, dovrebbero essere le maggiori probabilità di cache miss (e penalty), per quanto riguarda le istruzioni, a penalizzare il Core i7 in questo particolare tipo di elaborazioni.

Imho, per sopperire a caratteristiche architetturali differenti sarebbe necessario un diverso tipo di ottimizzazione del codice, in modo tale da divenire il più possibile cache independent.

si, anch'io sono dell'idea di doverlo farlo spaziare maggiormente in questo senso, ma se prima non viene raggiunta una maggior obiettività e coerenza del codice, potrebbe divenire solo tempo perso, e inutilmente

Attendiamo a questo punto le riflessioni e le determinazioni di bonis62

ragionamento profondissimo e che per quanto mi riguarda non fa una piega :clapclap:

avvalorato ancor più dal risultato di aris

apix_1024

Totocellux ha scritto:

si Aris, nell'ottica di ciò che ritengo possa accadere con questo tipo di elaborazioni, una quantità doppia di entrambe le cache di 1° livello del Phenom-II (64KB sia dati che istruzioni, rispetto ai 32KB Intel) influisce molto poco nella capacità ed efficienza elaborativa: considerato che è organizzata solo su due blocchi, dovrebbe praticamente sopravvenire un continuo di cache miss e penalty, cioè cpu praticamente ferma ad attendere le sostituzioni operate dalla cache stessa

l'unico modo che avrei io per riprendere il gap e passare ogni volta un set di istruzioni alla cpu superiore ai 32kb :fiufiu: tale da inficiare le vostre mille mila linee rispetto alle mie 2 sui 64kb... utopia pura... :asd:

Le085

apix_1024 ha scritto:

l'unico modo che avrei io per riprendere il gap e passare ogni volta un set di istruzioni alla cpu superiore ai 32kb :fiufiu: tale da inficiare le vostre mille mila linee rispetto alle mie 2 sui 64kb... utopia pura...

nella maggior parte dei casi è così

e alla fin fine riempiendo la cache delle istruzioni dovresti avere all'incirca l'equivalente di 32kb 4-way...

e infatti questa differenza così marcata si ha soltanto in questa applicazione specifica che usa poche e semplici istruzioni

utopia pura nell'utilizzo comune del pc e infatti quelli di amd ancora non stanno a zappare la terra...

non ancora :asd:

Xstreme

Totocellux ha scritto:

si Antonio, lo dicevo precedentemente: in elaborazioni di questo tipo, molto brevi, che spostano pochissimi dati e soprattutto che (come mi è sembrato dal listato che bonis62 ha postato) utilizzano svariate istruzioni in rapidissima successione, un ruolo molto importante nella efficienza elaborativa è rappresentato, in talune circostanze, dalla lunghezza della pipeline e dalla quantità e soprattutto dal numero di blocchi dell'associatività in cache.
In caso di miss cache dovuto alle numerose istruzioni, incorrerebbe purtroppo la necessità della continua sostituzione dei blocchi, e del quasi certo relativo stallo la cpu (e conseguente miss penalty).

Per diminuire tale evenienza in elaborazioni come la nostra, dovrebbe poter aiutare un elevato valore di associatività.

In questo particolare ambito, se ho ben compreso, sarebbe quindi spiegata la minore efficienza di un Core i7 rispetto ad un Core 2:

Core i7 (per ciascun core)

32KB di cache associativa a 8 vie per i dati

32KB di cache associativa a 4 vie per le istruzioni

Core 2 (per ciascun core)

32KB di cache associativa a 8 vie per i dati

32KB di cache associativa a 8 vie per le istruzioni

Pertanto, dovrebbero essere le maggiori probabilità di cache miss (e penalty), per quanto riguarda le istruzioni, a penalizzare il Core i7 in questo particolare tipo di elaborazioni.

Imho, per sopperire a caratteristiche architetturali differenti sarebbe necessario un diverso tipo di ottimizzazione del codice, in modo tale da divenire il più possibile cache independent.

si, anch'io sono dell'idea di doverlo farlo spaziare maggiormente in questo senso, ma se prima non viene raggiunta una maggior obiettività e coerenza del codice, potrebbe divenire solo tempo perso, e inutilmente

Attendiamo a questo punto le riflessioni e le determinazioni di bonis62

A PROPOSITO DI CACHE......... :nutkick:

ti REPLICO cosi :

mentre tu spegavi .....io ho finito di programmare questo....

http://www.xstreme.it/MSDT.zip

Xstreme Multithreading Speed Disk Test

DOVREBBE ESSERE IL PRIMO Speed Disk Test

IN Multithreading SULLA FACCIA DELLA TERRA e

:fiufiu: ALLA FACCIA DEL Loop Stream Detector :angel:

Xstreme

gear667 ha scritto:

I7 920@4GHz

cè qualcosa che non va ho gli stessi punteggi di prima

A ME MI SEMBRA CHE VA TUTTO BENE INVECE

guarda meglio...............le tue immagini.....

se noti il tempo per calcolare 108 numeri primi

mi sembra notevolmente diminuito.

ti ringrazio per le prove.

gear667

bonis62 ha scritto:

A ME MI SEMBRA CHE VA TUTTO BENE INVECE
guarda meglio...............le tue immagini.....

se noti il tempo per calcolare 108 numeri primi

mi sembra notevolmente diminuito.

ti ringrazio per le prove.

vero non mi ero accorto che il tempo cambiava, che nabbone:)

ps.: presto arrivano anche i test per l'HD

gear667

WD Raptor

Maxtor

ho notato che ripetendo il test più volte sullo stesso disco si ottengono punteggi sempre più elevati, è normale?

gear667

WD Raptor 60sec

Totocellux

Windows 7 64bit

Intel [email protected]

4GB DDR2@890 cas6

HD Hitachi HDT721075SLA380

test da 6 secondi:

1° test (scratch) punteggio 28

2° test (ripetuto) punteggio 86

3° test (scratch) punteggio 18

4° test (scratch) punteggio 23

5° test (ripetuto) punteggio 47

6° test (ripetuto) punteggio 73

7° test (ripetuto) punteggio 110

8° test (ripetuto) punteggio 137

9° test (scratch) punteggio 23

test da 60 secondi:

1° test bloccato

2° test bloccato

ad una prima occhiata, se sei indirizzato su test da 1KB sino a 2MB, servirebbe flushare la cache dell'hd dopo ogni prova.

Poi diminuirei senz'altro il numero dei task per eseguire il test (ben 12 per un dual core sono realmente troppi): uno o due per core sarebbero già più che sufficienti!

Due domande: quale criterio hai seguito per l'allocazione dei settori sui quali vengono effettuati i test, diretta o lasciata al criterio del s.o.?

Non vorrei entrare nel merito dei tuoi progetti, ma non sarebbe stato più produttivo se ti fossi dedicato completamente all'affinamento di PrimeScores, anziché concedere tempo ad un altro impegnativo sviluppo?

Xstreme

ho notato che ripetendo il test più volte sullo stesso disco si ottengono punteggi sempre più elevati, è normale?

presente quando winzip scompatta un file di archivio ?

più o meno il procedimento è lo stesso, ma anzichè un task

alla volta , qui si scompattano molti files alla volta, che dalla memoria

viaggiano diretti verso l'hdu, l'algoritmo di scompattazione

fà lavorare i cores, che producono una mole di dati che in

parallelo sono inviati all'hdu tramite il multithreading,

ho cercato di bypassare il più possibile il sistema operativo,

ma non troppo, anche per poter simulare una reale situazione,

quindi, si , dovrebbe essere normale;

sto lavorando ai risultati di più letture per eseguire una media

com'patata' finale abbastanza stabile, ma non dimentichiamoci

che qui si lavora su cores + hdu, e siamo abituati a testare o

uno o l'altro, mai tutti e due assieme....ma l'accoppiata

secondo me è interessante.

Xstreme

Totocellux ha scritto:

Windows 7 64bit
Intel [email protected]

4GB DDR2@890 cas6

HD Hitachi HDT721075SLA380

test da 6 secondi:

1° test (scratch) punteggio 28

2° test (ripetuto) punteggio 86

3° test (scratch) punteggio 18

4° test (scratch) punteggio 23

5° test (ripetuto) punteggio 47

6° test (ripetuto) punteggio 73

7° test (ripetuto) punteggio 110

8° test (ripetuto) punteggio 137

9° test (scratch) punteggio 23

test da 60 secondi:

1° test bloccato

2° test bloccato

ad una prima occhiata, se sei indirizzato su test da 1KB sino a 2MB,

occhi di falco ? :perfido:

servirebbe flushare la cache dell'hd dopo ogni prova.

normalmente su un task sarebbe sempliccissimo, su 12,

le attese, se non programmate bene farebbero saltare

il Multithreading , per essere una beta non mi ...ci possiamo lamentare :clapclap:

Poi diminuirei senz'altro il numero dei task per eseguire il test (ben 12 per un dual core sono realmente troppi): uno o due per core sarebbero già più che sufficienti!

dei 12 task in realtà ne viene sfruttato solo il parallelismo per la scompattazione dei flussi, poi si occupa il main thread a fare da

interfaccia con l'hdu, ma si può fare sicuramente di meglio :n2mu:,

non voglio alterare molto il codice, la pappa deve essere

uguale pèer tutti, pero, se hai meno cpu, sarai meno veloce,

ovvio....legge della natura...ma sicuramente va migliorato

questo aspetto, sicuramente.

Due domande: quale criterio hai seguito per l'allocazione dei settori sui quali vengono effettuati i test, diretta o lasciata al criterio del s.o.?

la prima versione sfruttava la virtualizzazione di cluster mirrorati

poi su hdu, ma se vogliamo simulare un utilizzo reale, quale

criterio useresti tu ?

Non vorrei entrare nel merito dei tuoi progetti, ma non sarebbe stato più produttivo se ti fossi dedicato completamente all'affinamento di PrimeScores, anziché concedere tempo ad un altro impegnativo sviluppo?

sicuro, ma ..sai ....il multithreading è contagioso

...........................................................................................

grazie per quelle letture.

ps

per un benchmark dedicato al multithreading due core non sono un pò pochi ?

Xstreme

ciao

sto lavorando all'interfaccia, questo è un esempio:

http://www.xstreme.it/primecorebeta.zip

dj883u2

bonis62 ha scritto:

ciao
sto lavorando all'interfaccia, questo è un esempio:

http://www.xstreme.it/primecorebeta.zip

Carina l'interfaccia.

Ma oltre a quella, hai deciso se differenziare i vari test?In modo da rendere + veritieri i risultati e rendere il test + flessibile?

Xstreme

dj883u2 ha scritto:

Carina l'interfaccia.
Ma oltre a quella, hai deciso se differenziare i vari test?In modo da rendere + veritieri i risultati e rendere il test + flessibile?

se mi spieghi in dettaglio cosa dovrei fare, cosi me la

stampo e ci lavoro, mi faresti un favore :clapclap:

nel frattempo se vuoi ho aggiunto una funzione...

http://www.xstreme.it/PrimeCores30Beta.zip

dj883u2

bonis62 ha scritto:

se mi spieghi in dettaglio cosa dovrei fare, cosi me la
stampo e ci lavoro, mi faresti un favore :clapclap:

nel frattempo se vuoi ho aggiunto una funzione...

http://www.xstreme.it/PrimeCores30Beta.zip

Personalmente, diversificherei il test in modo tale da ottenere + test.

Es:

1) Un test lo farei per ottenere le massime prestazioni con diversi gradi di "pesantezza" come avviene con SuperPi

2) Un test per la stabilità operativa in Overclock, come avviene per "Prime95" o Linx.

Cercherei di rendere il programma multifunzionale per sfruttare da 1 ad infiniti core della cpu.

apix_1024

bonis62 ha scritto:

se mi spieghi in dettaglio cosa dovrei fare, cosi me la
stampo e ci lavoro, mi faresti un favore :clapclap:

nel frattempo se vuoi ho aggiunto una funzione...

http://www.xstreme.it/PrimeCores30Beta.zip

non mi fornisce gli score premendo il tasto score ma solo andando a cercare l'eseguibile manualmente nella cartella prova a controllareO0 cmq ottima grafica. se facessi gli step che ti ha detto antonio potrebbe essere un buon programma per i test della cpu anche se credo che non carichi al 100% tutta la logica delle cpu visto che con il calcolo al 100% arriva a 48°C il mio phenom mentre con linX o occt supero i 50°C abbondantemente.:n2mu:

dj883u2

Sei al lavoro con il programma?

Mi aspetto molte soddisfazioni!

apix_1024

dj883u2 ha scritto:

Sei al lavoro con il programma?
Mi aspetto molte soddisfazioni!

vedrai ho il presentimento che il prossimo pacchetto superi di gran lunga i 5mb :asd: gli hai dato troppe idee :2funny: :ave: :ave:

dj883u2

apix_1024 ha scritto:

vedrai ho il presentimento che il prossimo pacchetto superi di gran lunga i 5mb gli hai dato troppe idee :ave:

Molto bene.:clapclap: