Prime Cores V1.0 Freeware

Le085

direi che c'è molto che non va, visto che ha dato 108 a tutti, indipendentemente dal sistema....

oppure in questo caso è da valutare il tempo che ci impiega a farne 108? in tal caso mi sembrano risultati coerenti

anche se il risultato dell'e5200 rimane sorprendentemente molto basso (in termini di tempo) rispetto alle piattaforme nehalem e phenom II

Totocellux

.... con quella conf sono già al limite : Human Proteome Folding a volte mi va in errore.

Dovremmo poter comprendere il meccanismo di elaborazione, i criteri di funzionamento, i tempi di esecuzione e l'assegnazione del punteggio.

principino1984

Le085 ha scritto:

direi che c'è molto che non va, visto che ha dato 108 a tutti, indipendentemente dal sistema....
oppure in questo caso è da valutare il tempo che ci impiega a farne 108? in tal caso mi sembrano risultati coerenti

anche se il risultato dell'e5200 rimane sorprendentemente molto basso (in termini di tempo) rispetto alle piattaforme nehalem e phenom II

leo, il programma calcola tot numeri primi e bisogna vedere quanto tempo ci mette il pc... quindi quello da vedere è il tempo che deve diminuire aumentando di frequenza (almeno è quello che penso di aver capito)

Marco

dj883u2

principino1984 ha scritto:

leo, il programma calcola tot numeri primi e bisogna vedere quanto tempo ci mette il pc... quindi quello da vedere è il tempo che deve diminuire aumentando di frequenza (almeno è quello che penso di aver capito)
Marco

Penso anche io che sia cosi.....ma comunque è sempre sballato lo stesso, anche se si guarda il tempo. Basta guardare come con il processore Intel E5200 che è un dual core portato a 3600Mhz finisca il calcolo in 1m e 36 secondi e un Core i7 920 con 8 core attivi portato a 4200Mhz impieghi 2 minuti e 4 secondi.....

Comunque, sarebbe da integrare il programma con diversi test. Da test + lunghi per testare la stabilità....direi tempo infinito, a test di pura velocità, come SuperPi...

Che dite?

Totocellux

Basta guardare come con il processore Intel E5200 che è un dual core portato a 3600Mhz finisca il calcolo in 1m e 36 secondi e un Core i7 920 con 8 core attivi portato a 4200Mhz impieghi 2 minuti e 4 secondi.....

si Antonio' date=' lo dicevo precedentemente: in elaborazioni di questo tipo, molto brevi, che spostano pochissimi dati e soprattutto che (come mi è sembrato dal listato che [b']bonis62[/b] 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.

Comunque' date=' sarebbe da integrare il programma con diversi test. Da test + lunghi per testare la stabilità....direi tempo infinito, a test di pura velocità, come SuperPi...

Che dite?[/quote']

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

apix_1024

Totocellux ha scritto:

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

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

:muro: :muro: :muro:

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?