Prime Cores V1.0 Freeware

[One1ros]

Bel programma!

funziona pero' se lo eseguo piu' volte c'è un'oscillazione del valore e questo scarto arriva anche a 2 secondi.

[apix_1024]

funziona anche troppo bene tanto che l'ultimo step per il maggior numero di numeri primi, imho, è anche troppo veloce... 35sec circa sul mio superpippa II!!

alla fine sei arrivato ad un algoritmo anche troppo efficiente :asd:

[Xstreme]

apix_1024 ha scritto:

funziona anche troppo bene tanto che l'ultimo step per il maggior numero di numeri primi, imho, è anche troppo veloce... 35sec circa sul mio superpippa II!!

alla fine sei arrivato ad un algoritmo anche troppo efficiente :asd:

per ogni core parto da 0 e arrivo a trovare max 21336354 numeri primi

quindi il tuo computer non calcola 512072496 numeri primi reali ,

ma (0 -> 21336354) * (numero di core)

21336354 * 24 = 51207249

in queste ore ho messo a punto (e funziona) lo stesso algoritmo

ma con il THREAD_PRIORITY_HIGHEST settato su ON per migliorarne

l'efficenza, senza toccare la priorità dell'intero processo, ho implementato

anche un multithreading sui singoli processi restanti

per migliorare la latenza,

e ho scoperto che i benchmark multicore che danno sempre lo stesso tempo

su sistemi multicore o.... sono ottimizzati da piccoli omini verdi o.... secondo

me non sono reali.....

come Toto ti potra confermare , il 75 % del codice è in C ,

la routine che estrapola i numeri primi è in Assembler (INLINE nel codice C),

quindi Thread gestiti in C e calcoli in Assembler.

[Xstreme]

mi servirebbe una cortesia, il risultato esatto

del livello 1 con Primecores appena lanciato.

solo per chi ha un quad core o superiore.

grazie

[dj883u2]

bonis62 ha scritto:

mi servirebbe una cortesia, il risultato esatto

del livello 1 con Primecores appena lanciato.

solo per chi ha un quad core o superiore.

grazie

Eccolo:

[gear667]

[apix_1024]

[Totocellux]

anche se l'E5200 non è un quad, posto ugualmente lo score del livello 01 (potrebbe esserti utile ugualmente):

livello 02:

[principino1984]

non capisco una cosa.. per quale motivo se do un livello più alto di toh... 5 o 6 dove c'è da calcolare un bel po' di numeri.. primecore mi stressa la CPU al 100% su tutti gli 8 cores per circa 5 secondi e poi va in vacanza.

Comunque ecco i due risultati:

Marco

[Xstreme]

principino1984 ha scritto:

non capisco una cosa.. per quale motivo se do un livello più alto di toh... 5 o 6 dove c'è da calcolare un bel po' di numeri.. primecore mi stressa la CPU al 100% su tutti gli 8 cores per circa 5 secondi e poi va in vacanza.

Comunque ecco i due risultati:

Marco

se provi i livelli 1 2 4 8 e 24... dovrebbe funzionare tutto,

gli altri livelli li sto ancora ottimizzando....

[Xstreme]

Ciao,

ecco una nuova versione in cui dovrei aver stabilizzato i tempi dei test

con un controllo più accurato dei vari thread,

i livelli attivi sono da 01 a 10 e il 24 per ora.

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

.

[Totocellux]

stai facendo davvero un lavoro superlativo

Complimenti, soprattutto per la velocità dell'algoritmo :clapclap:

[Xstreme]

Totocellux ha scritto:

stai facendo davvero un lavoro superlativo

Complimenti, soprattutto per la velocità dell'algoritmo :clapclap:

grazie

anche se devo dire che il codice che gestisce

fino a 24 cores non è da meno dell'algoritmo ,

il "wait" del multithread ho dovuto riscriverlo a modo mio,

altrimenti il ciclo, in attesa che uno dei threads terminava,

non mi permetteva di uscire nel momento in cui si premeva

il pulsante di abort....essendo multitasking se termini

il processo che ha lanciato il task , non vuol dire terminare

il task in esecuzione.. non so se mi sono spiegato...bene...

in altri termini...se atterri chi ha lanciato la pietra...non vuol dire che la pietra smetta la sua corsa

specialmente se chi tira la pietra è scritto in C, e la pietra e scritta in assembler....

mi fermo qui....è meglio....

[Totocellux]

bonis62 ha scritto:

grazie

anche se devo dire che il codice che gestisce

fino a 24 cores non è da meno dell'algoritmo ,

il "wait" del multithread ho dovuto riscriverlo a modo mio,

altrimenti il ciclo, in attesa che uno dei threads terminava,

non mi permetteva di uscire nel momento in cui si premeva

il pulsante di abort....essendo multitasking se termini

il processo che ha lanciato il task , non vuol dire terminare

il task in esecuzione.. non so se mi sono spiegato...bene...

in altri termini...se atterri chi ha lanciato la pietra...non vuol dire che la pietra smetta la sua corsa

non so quanto sia nidificato e profondo tale tipo di controllo, hai calcolato quanto ha inciso sull'efficienza, cioè quanto ti è costato in termini di % sul ciclo primario?

[Xstreme]

Totocellux ha scritto:

non so quanto sia nidificato e profondo tale tipo di controllo, hai calcolato quanto ha inciso sull'efficienza, cioè quanto ti è costato in termini di % sul ciclo primario?

in multithreading non devi più ragionare cosi.....

mi spiego meglio...con un esempio

{

un cavo porta corrente a 24 lampadine

questo è quando lavoravi senza multithreading

}

{

24 cavi portano corrente a 24 lampadine

questo è quando lavori con il multithreading

}

{

la lampadina senza corrente si spegne

}

{

un thread per restare "acceso" deve rimanere all'interno

un ciclo che ne permette la sua esecuzione fino alla fine

}

quindi....

se fai un controllo per verificare, per esempio che

il thread n. 15 ha terminato, se il controllo

non è lui stesso inserito in un contesto multithreading,

ritorniamo alla singola esescuzione monocorde,

per non nidificare basta creare un multithreading nel multithreading,

dove cè la classe multithreading che esegue i cicli di calcolo,

((la classe multithreading al suo interno non deve contenere

thread figli, altrimenti il controllo del singolo threads va a pallini ))

l'atro mutithreading controlla che la classe multithreadig "calcoli"

abbia terminato di far lavorare tutti i thread aperti sui singoli cores,

quando la classe multithreading "controllo" ha tutti i registri a zero,

significa che tutti i threads "calcoli" hanno concluso,

preleva il tempo trascorso e lo visualizza;

finchè lavori in mono linguaggio questo è releativamente

semplice, ma come tu ben sai, il pacchetto e composto

da 3 linguaggi, --- basic , c , assembler ---

il basic racchiude il C, il C racchiude l'assembler,

quindi

con l'assembler faccio i calcoli,

con il C gestisco la classe multhithread "calcoli"

con il basic gestisco la classe multithread "controllo"

basic > controlla C > controlla assembler > controlla calcoli

con un return del C ho il tempo impiegato,

con il basic lo stampo a schermo

The End

:uglystupid2::uglystupid2::uglystupid2:

ps

nella versione che sto scrivendo, nei tempi morti di controllo

della classe multithread "calcoli" ho inserito una pezza scritta

in C che esegue un "memmove" a 20Kb di dati 100 volte al

secondo in modo che nel risultato finale rientri anche la

velocità delle memorie, ho usato 20Kb per rimanere sempre

in ambito memoria fisica, altrimenti mi usava lo swap da disco

con i vecchi pentium o amd.

[apix_1024]

fantastico... pure un pò di cicli sulle ram!! incredibile!! :AAAAH::AAAAH::AAAAH: ed hai spiegato bene anche la parte della programmazione. insomma se l'ho capita io dopo 19 ore di attività cerebrale devo dire che è proprio spiegata benissimoO0O0O0

[Totocellux]

mmmhhhh ........

eravamo partiti da questo problema che tu avevi rilevato:

bonis62 ha scritto:

grazie

[..........]

il "wait" del multithread ho dovuto riscriverlo a modo mio,

altrimenti il ciclo, in attesa che uno dei threads terminava,

non mi permetteva di uscire nel momento in cui si premeva

il pulsante di abort....

[..........]

quindi ti ho chiesto:

non so quanto sia nidificato e profondo tale tipo di controllo, hai calcolato quanto ha inciso sull'efficienza, cioè quanto ti è costato in termini di % sul ciclo primario?

in sintesi, mi hai risposto:

bonis62 ha scritto:

in multithreading non devi più ragionare cosi.....

[..........]

{

un thread per restare "acceso" deve rimanere all'interno

un ciclo che ne permette la sua esecuzione fino alla fine

}

quindi....

per non nidificare basta creare un multithreading nel multithreading,

dove cè la classe multithreading che esegue i cicli di calcolo,

((la classe multithreading al suo interno non deve contenere

thread figli, altrimenti il controllo del singolo threads va a pallini ))

1) l'atro mutithreading controlla che

2) la classe multithreading "calcoli" abbia terminato di far lavorare tutti i thread aperti sui singoli cores,

[..........]

riformulo la domanda, ed esponendola in diverso modo spero di essere più diretto.

Per risolvere quel problema inerente il tasto abort hai utilizzato un sistema di classi, e al momento non ha importanza in che linguaggio esse siano state scritte.

dopo che viene premuto il tasto abort, quanti cicli della propria elaborazione impiega mediamente la classe multithreading "calcoli" o chi per essa (la classe multithreading di controllo) per accorgersi dell'evento e quindi avere la contezza che il calcolo debba essere immediatamente interrotto?

[Xstreme]

Totocellux ha scritto:

mmmhhhh ........

eravamo partiti da questo problema che tu avevi rilevato:

quindi ti ho chiesto:

in sintesi, mi hai risposto:

riformulo la domanda, ed esponendola in diverso modo spero di essere più diretto.

Per risolvere quel problema inerente il tasto abort hai utilizzato un sistema di classi, e al momento non ha importanza in che linguaggio esse siano state scritte.

dopo che viene premuto il tasto abort, quanti cicli della propria elaborazione impiega mediamente la classe multithreading "calcoli" o chi per essa (la classe multithreading di controllo) per accorgersi dell'evento e quindi avere la contezza che il calcolo debba essere immediatamente interrotto?

su un calcolo con quad core

ho inserito il rilevamento dei millisecondi

alla pressione del tasto reset,

ho inserito un altro rilevamento sulla linea di codice

che toglie "corrente" alla classe "calcolo" :

premuto reset 183984037

intercettato in 183984038

1 millisecondo

Max Clock Speed (+/- 5% MHz) : 3347

1000 diviso 3347

0,29 cicli

[Totocellux]

bonis62 ha scritto:

su un calcolo con quad core

ho inserito il rilevamento dei millisecondi

alla pressione del tasto reset,

ho inserito un altro rilevamento sulla linea di codice

che toglie "corrente" alla classe "calcolo" :

premuto reset 183984037

intercettato in 183984038

1 millisecondo

Max Clock Speed (+/- 5% MHz) : 3347

1000 diviso 3347

0,29 cicli

ora correggimi se sbaglio, quel valore di 0.29 cicli viene, questa volta, sprecato anche quando l'elaborazione continua regolarmente, cioè allorchè la classe multithreading "calcoli" o quella di controllo non riesca ad intercettare alcun evento associato alla pressione del tasto abort: è corretto?

il problema creato dall'utilizzo di questi controlli di gestione dell'interruzione è sempre il medesimo: fa perdere +o- efficienza a seconda dell'implementazione e della strategia utilizzata, in quanto per forza di cose il controllo (con il proprio bagaglio di tempo di intervento dovuto all'interconnessione con i thread di calcolo e/o controllo) deve essere continuamente attivo (cioè poter intervenire) comunque a priori per poter intercettare un evento di valenza superiore ed esterno come quello dell'evento associato alla pressione del tasto abort in questione.

Se il valore (espresso in intervallo di tempo) di questa perdita viene applicata al programma di gestione che so io, della conta delle pecore al pascolo questa perdita è ampiamente accettabile, ma quando viene ad inficiare l'efficienza di un algoritmo molto spinto come il tuo, direi che è un vero peccato.

Ora, se riuscissimo a stabilire su quella macchina quanti numeri primi in media si possano riuscire a scoprire nell'arco di 0.29 cicli al secondo, e rapportando tale valore con quello del totale dei singoli numeri mediamente scopribili nell'arco dell'unità di tempo, ecco che saremmo riusciti a trovare il grado di inefficienza del controllo in questione rispetto a quello di efficeinza dell'algoritmo di estrazione

EDIT

spero di esser stato chiaro, e non macchinoso come spesso mi accade di credere.

[Xstreme]

Totocellux ha scritto:

ora correggimi se sbaglio, quel valore di 0.29 cicli viene, questa volta, sprecato anche quando l'elaborazione continua regolarmente, cioè allorchè la classe multithreading "calcoli" o quella di controllo non riesca ad intercettare alcun evento associato alla pressione del tasto abort: è corretto?

il problema creato dall'utilizzo di questi controlli di gestione dell'interruzione è sempre il medesimo: fa perdere +o- efficienza a seconda dell'implementazione e della strategia utilizzata, in quanto per forza di cose il controllo (con il proprio bagaglio di tempo di intervento dovuto all'interconnessione con i thread di calcolo e/o controllo) deve essere continuamente attivo (cioè poter intervenire) comunque a priori per poter intercettare un evento di valenza superiore ed esterno come quello dell'evento associato alla pressione del tasto abort in questione.

Se il valore (espresso in intervallo di tempo) di questa perdita viene applicata al programma di gestione che so io, della conta delle pecore al pascolo questa perdita è ampiamente accettabile, ma quando viene ad inficiare l'efficienza di un algoritmo molto spinto come il tuo, direi che è un vero peccato.

Ora, se riuscissimo a stabilire su quella macchina quanti numeri primi in media si possano riuscire a scoprire nell'arco di 0.29 cicli al secondo, e rapportando tale valore con quello del totale dei singoli numeri mediamente scopribili nell'arco dell'unità di tempo, ecco che saremmo riusciti a trovare il grado di inefficienza del controllo in questione rispetto a quello di efficeinza dell'algoritmo di estrazione

EDIT

spero di esser stato chiaro, e non macchinoso come spesso mi accade di credere.

Se ragioni alla vecchia maniera , il discorso non è macchinoso , anzi fila,

ma , prevedendoti , la mia lunga risposta precedente è la risposta a questa tua, in quanto il ceck dell'interfaccia è a sua volta in multithreading,

i cicli che vengono impiegati al controllo del tutto sono al di fuori degli altri task;

il thread che controlla i registri , ha un refresh di 700 volte al secondo.

quando Primecores si esegue su CPU a core singolo (ormai quasi introvabili)...

vengono sfruttati i 16 timer multitasking che "i Windows" hanno di serie per simulare un ipotetico multithread.

se sali le scale con tre gambe anziche due, le sali più velocemente o con meno fatica ?