Prime Cores V1.0 Freeware
-
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
-
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....
-
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 .
-
stai facendo davvero un lavoro superlativo
Complimenti, soprattutto per la velocità dell'algoritmo :clapclap:
-
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....
-
bonis62 ha scritto:
grazieanche 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?
-
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.
-
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
-
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:
in sintesi, mi hai risposto: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?
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?
-
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
-
bonis62 ha scritto:
su un calcolo con quad coreho 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.
-
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 ?
-
apix_1024 ha scritto:
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 benissimoO0O0O0quando la logica diventa un eccezzione per spiegarla occorre un altra eccezzione (autore : io)
-
bonis62 ha scritto:
[........]
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;
e cosa dovrebbero consumare tali cicli ?!
a carico di chi vengono eseguiti ?!
bonis62 ha scritto:
[........]
il thread che controlla i registri , ha un refresh di 700 volte al secondo.
immagino tu stia parlando dei registri della cpu.
ma non ho ben compreso cosa c'entri col controllo di cui stavamo parlando
bonis62 ha scritto:
[........]
se sali le scale con tre gambe anziche due, le sali più velocemente o con meno fatica ?
questo esempio, adottato nel tipo di elaborazione che stai portando avanti con la scoperta dei numeri primi, e la velocità e l'efficienza con la quale la si effettua, imho, dovrebbe entrarci ben poco.
Puoi utilizzare tutti i thread che vuoi ma la funzionalità di Windows resterà pur sempre di tipo time-sharing
: viene soltanto creata l'illusione di più processi eseguiti contemporaneamente! In realtà sono portati a termine di seguito, uno alla volta in frazioni di tempo rapidissime, quindi salvati, messi in coda, e poi rimessi in elaborazione e ..... via via così
Hai l'opportunità di avvalorare le tue tesi: sfornami l'eseguibile dell'ultima versione di PrimeCores senza qualsiasi riga di codice inerente ai controlli sul calcolo e sull'abort e potremo tirare le somme
-
Totocellux ha scritto:
e cosa dovrebbero consumare tali cicli ?!a carico di chi vengono eseguiti ?!
immagino tu stia parlando dei registri della cpu.
ma non ho ben compreso cosa c'entri col controllo di cui stavamo parlando
questo esempio, adottato nel tipo di elaborazione che stai portando avanti con la scoperta dei numeri primi, e la velocità e l'efficienza con la quale la si effettua, imho, dovrebbe entrarci ben poco.
Puoi utilizzare tutti i thread che vuoi ma la funzionalità di Windows resterà pur sempre di tipo time-sharing
: viene soltanto creata l'illusione di più processi eseguiti contemporaneamente! In realtà sono portati a termine di seguito, uno alla volta in frazioni di tempo rapidissime, quindi salvati, messi in coda, e poi rimessi in elaborazione e ..... via via così
Hai l'opportunità di avvalorare le tue tesi: sfornami l'eseguibile dell'ultima versione di PrimeCores senza qualsiasi riga di codice inerente ai controlli sul calcolo e sull'abort e potremo tirare le somme
a carico di chi vengono eseguiti ?!
ad un task che gira su tutti i cores presenti,
mediamente il tempo per il controllo di un registro si prende due o tre istruzioni,
spalmiamo questo tempo per tutti i cores rilevati nella CPU e ...
a mio parere non dovrebbe incidere più dello 0.001 sui tempi del test,
siamo nell'ordine dei microsecondi se non erro...
immagino tu stia parlando dei registri della cpu.
no, sto parlando dei registri di PrimeCores,
quando un thread ha finito il calcolo porta il
suo registro a zero, la routine di controllo controlla
700 volte al secondo quel registro,
lo ho portato fino a 700, perche fino a 700
ho rilevato i medesimi tempi,
oltre i 700 cicli di controllo appare un rallentamento di meno di mezzo secondo.
tipo time-sharing..
visto che il concetto del time-sharing è il mutitasking....,
l'illusione diventa realtà se scoperchi la tua cpu e ci trovi più di 1 core
In realtà sono portati a termine di seguito, uno alla volta...
posso dissociarmi da queste vaganti rivelazioni ?
-
bonis62 ha scritto:
tipo time-sharing..
visto che il concetto del time-sharing è il mutitasking....,
l'illusione diventa realtà se scoperchi la tua cpu e ci trovi più di 1 core
In realtà sono portati a termine di seguito, uno alla volta...
posso dissociarmi da queste vaganti rivelazioni ?
vaganti rivelazioni?!
l'affermazione non merita commento
il contenuto si
In un ambiente Time-Sharing come Windows:
Each thread is scheduled for a quantum, which defines the maximum amount of CPU time for which the thread can run before the kernel looks for other threads at the same priority to run. The exact duration of a quantum varies depending on what version of Windows is installed, the type of processor on which Windows is running, and the performance settings that have been established by a system administrator.
[........]
After a thread is scheduled, it runs until one of the following occurs:
- Its quantum expires.
- It enters a wait state.
- A higher-priority thread becomes ready to run.
tratto da:
- Its quantum expires.
-
questo thread sta diventando interessantissimo... continuate così perchè penso che state spiegando in termini "semplici" veramente tante cose su windows!
Marco
-
Totocellux ha scritto:
vaganti rivelazioni?!
l'affermazione non merita commento
il contenuto si
In un ambiente Time-Sharing come Windows:
Each thread is scheduled for a quantum, which defines the maximum amount of CPU time for which the thread can run before the kernel looks for other threads at the same priority to run. The exact duration of a quantum varies depending on what version of Windows is installed, the type of processor on which Windows is running, and the performance settings that have been established by a system administrator.
[........]
After a thread is scheduled, it runs until one of the following occurs:
- Its quantum expires.
- It enters a wait state.
- A higher-priority thread becomes ready to run.
tratto da:
interessante articolo dell'anno 2004....
ti consiglio una lettura di un intero capitolo sul multithreading
....ma dell'anno 2008 :
http://msdn.microsoft.com/en-us/library/hyz69czz.aspx
qua riprende a spiegare il multithreading ma siamo in realtime cioè fine 2009
- Its quantum expires.
-
bonis62 ha scritto:
interessante articolo dell'anno 2004....ti consiglio una lettura di un intero capitolo sul multithreading
....ma dell'anno 2008 :
http://msdn.microsoft.com/en-us/library/hyz69czz.aspx
interessante questa storia del multithreading simulato su una singola cpu.
Capisco il discorso che grazie a questo accorgimento, visto che le time slice sono molto piccole i thread sembra che vengano eseguiti tutti contemporaneamente dando così l'illusione del multithreading cosa che con il time-sharing non avviene perchè c'è più latenza tra un thread e l'altro.
ora non ho seguito bene il succo del dibattito (o meglio non l'ho capito
) ma a mio (modestissimo) parere questo multithreading virtuale è un po' più inefficciente del time-sharing perchè va spesso a interrompere l'esecuzione dei thread (quindi salvare tutti i registri del thread interrotto e caricare tutte le istruzioni dell'altro thread dal punto dove era astato interrotto) cosa che a mio avviso crea abbastanza inefficienza per via appunto di queste interruzioni.E' vero che queste nuove cpu hanno politiche di scheduling piuttosto sofisticate ma rimane il fatto che secondo me è un po' piu' inefficiente.
-
Le085 ha scritto:
interessante questa storia del multithreading simulato su una singola cpu.Capisco il discorso che grazie a questo accorgimento, visto che le time slice sono molto piccole i thread sembra che vengano eseguiti tutti contemporaneamente dando così l'illusione del multithreading cosa che con il time-sharing non avviene perchè c'è più latenza tra un thread e l'altro.
ora non ho seguito bene il succo del dibattito (o meglio non l'ho capito
) ma a mio (modestissimo) parere questo multithreading virtuale è un po' più inefficciente del time-sharing perchè va spesso a interrompere l'esecuzione dei thread (quindi salvare tutti i registri del thread interrotto e caricare tutte le istruzioni dell'altro thread dal punto dove era astato interrotto) cosa che a mio avviso crea abbastanza inefficienza per via appunto di queste interruzioni.E' vero che queste nuove cpu hanno politiche di scheduling piuttosto sofisticate ma rimane il fatto che secondo me è un po' piu' inefficiente.
si possono scrivere milioni di testi sull'argomento,
ma sono solo parole, il discorso cambia quando
stai davantti ad una consolle bianca come il latte
e ci cominci a scrivere il codice....
comunque, in linea di massima sono d'accordo...quando si parla di singola CPU con singolo Core.
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi