Prime Cores V1.0 Freeware

gear667

dj883u2 ha scritto:

Un grazie per l'ottimo lavoro svolto da bonis62.:clapclap:

quoto

apix_1024

il buon bonis62 ha preso alla lettera il mio consiglio di far calcolare un macello di numeri primi.... l'ultimo step è un pò superiore a quello che avevo pensato io... ma non di tanto... solo 3 ordini di grandezza :asd: :asd: :asd:

100milioni di numeri primi per ogni core... il mio phenom va in pensione prima credo :2funny:

cmq grande bonis62, ottimo lavoro!

dj883u2

Provato questa nuova versione.

L'aspetto grafico è bello.

Il test non riesce a sfruttare interamente al 100% tutti core della cpu:

mediamente il valore oscilla dal 93% al 100%. Misogna farlo restare fermo al 100%.

Il test quando arriva verso la fine, diciamo quando manca 1/3 per finirlo, fa scendere le varie cpu al 50% del loro potenziale....

bisogna fare in modo che dall'inizio fino alla fine la cpu resti costante al 100%.

Io metterei un test che calcola in maniera "infinita" i numeri primi, in modo da poterlo usare come "stress" per testare la stabilità della cpu. :coolsmiley:

apix_1024

dj883u2 ha scritto:

Provato questa nuova versione.
L'aspetto grafico è bello.

bisogna fare in modo che dall'inizio fino alla fine la cpu resti costante al 100%.

Io metterei un test che calcola in maniera "infinita" i numeri primi, in modo da poterlo usare come "stress" per testare la stabilità della cpu.

per il load credo basti fare in modo che il prgramma di suo si setti a priorità alta! diremo a bonis62.

per lo stress test fai i 100milioni di numeri primi e poi dimmi se non basta :asd:

principino1984

si..ha ragione antò...verso la fine il load della cpu scende al 50% mentre durante il test comunque non è fissa al 100%

La lunghezza del test penso sia più che adeguata...100M di numeri primi sono una cosa disumana

Marco

Xstreme

ok, quelli sono problemi già a me noti,

e ci sto lavorando, purtroppo non è

colpa del codice, ma di come il sistema

operativo gestisce la coda dei thread,

tipo la cache del disco fisso, ma sto ottimizzando

per risolvere.......

per i risultati potete anche visualizzare la schermata

tramite lo Showbench (vedi voce nel menu di primecores)

che presto avrà la funzione di grab della finestra,

ricordo che i files generati sono protetti; qualcuno

è in grado di testarne la sicurezza della integrità ?

per vedere se si è riusciti a superare la protezione,

dopo un eventuale prova di hacking,

basta dare in pasto a showbench il file manomesso,

se showbench si rifiuta di visulaizzarlo, la protezione

regge.

altri suggerimenti , bug, idee o quant'altro ?

di nuovo grazie a tutti per il supporto, appena parlo

con Marco credo si mettera sù qualcosa di dedicato

per Primecores, a livello di forum, ma ultimamente

ho un sacco di imprevisti, sperando che Marco

non si arrabbi prima, ma ho veramente un sacco

di noie in questo periodo, a momenti non ho il tempo

per fare la PP

Xstreme

apix_1024 ha scritto:

per il load credo basti fare in modo che il prgramma di suo si setti a priorità alta! diremo a bonis62.
+++++++++++++

no, niente trucchetti

tu basta che mi dici quello che devo fare....................

e io lo faccio.....

+++++++++++++++

per lo stress test fai i 100milioni di numeri primi e poi dimmi se non basta

-----------------------------------------

Xstreme

se fate andare anziche 8 core , solo 4 , come si comporta ?

se a 4 core sta tutto al max ho trovato il punto critico :clapclap:

ps

appena ho i $$ mi doto anche io di un sistema i7 :muro:

Totocellux

ottimo lavoro per ciò che riguarda l'interfaccia

anche se ricca di riquadri, è decisamente gradevole: il wall-paper del portale come sfondo, mi piace parecchio

Devo dire, però, che il drawing dei riquadri risulta finanche troppo pesante su macchine non recentissime.

Sarebbe forse utile evidenziare con un colore più in risalto il riquadro in alto della selezione della dimensione del test (quello con il radio-button che si andrà ad attivare), perchè a primo acchitto non risulta ben rilevabile.

di certo sarebbe più utile salvare i dati dei test nel formato più universale:

nomeutente_aaaa-mm-gg_hh-mm-ss

questa modalità garantirebbe da subito la corretta individuazione cronologica dei vari test, soprattutto per te qualora li acquisissi a un fine statistico

Su piattaforma P5WDG2 WS Pro e Q6600 lo scanning del sistema si blocca inesorabilmente in fase di acquisizione della configurazione.

su P5ND2 Sli e Pentium D805, va bene ma ho riscontrato anch'io quel problemino di utilizzazione del 2° core alla fine del test.

In seguito, altre impressioni

Xstreme

Totocellux ha scritto:

ottimo lavoro per ciò che riguarda l'interfaccia
anche se ricca di riquadri, è decisamente gradevole: il wall-paper del portale come sfondo, mi piace parecchio

Devo dire, però, che il drawing dei riquadri risulta finanche troppo pesante su macchine non recentissime.

Sarebbe forse utile evidenziare con un colore più in risalto il riquadro in alto della selezione della dimensione del test (quello con il radio-button che si andrà ad attivare), perchè a primo acchitto non risulta ben rilevabile.

di certo sarebbe più utile salvare i dati dei test nel formato più universale:

nomeutente_aaaa-mm-gg_hh-mm-ss

questa modalità garantirebbe da subito la corretta individuazione cronologica dei vari test, soprattutto per te qualora li acquisissi a un fine statistico

Su piattaforma P5WDG2 WS Pro e Q6600 lo scanning del sistema si blocca inesorabilmente in fase di acquisizione della configurazione.

su P5ND2 Sli e Pentium D805, va bene ma ho riscontrato anch'io quel problemino di utilizzazione del 2° core alla fine del test.

In seguito, altre impressioni

ciao

wow :clapclap:

ho scritto sul blocco appunti tutto quanto,

ti chiedo una cosa,

per cortesia, metti la cartella del programma

dentro una key usb, (è "portable"),

inserisci la key usb nel pc

P5WDG2 WS Pro e Q6600,

eseguendolo da key si blocca ancora ?

grazie

Xstreme

apix_1024 ha scritto:

per il load credo basti fare in modo che il prgramma di suo si setti a priorità alta! diremo a bonis62.
per lo stress test fai i 100milioni di numeri primi e poi dimmi se non basta

in realta non sono 100 milioni di numeri primi e basta,

calcolando che una routine secondaria lancia (in multithread)

il numero primo scoperto alla funzione int8(sqr(Atan2))

che estrae un numero intero a 8 bit basato sulla radice quadrata

dei tangenti atan2; i due tangenti atan2 usano come vettori:

1°) il numero primo scoperto come coordinata X

2°) il fattoriale "mersennizato" calcolato partendo dal

1° numero primo scoperto fino a quello in lavorazione

come coordinata Y, il numero intero a 8 bit risultante

(convertito da numero a doppia precisione in virgola

mobile, in intero arrotondato)

è il riferimento per la verifica del risultato, quindi nello

stesso momento da una matrice ottagonale precacolata,

viene estratto un numero intero a 8 bit e viene confrontato

con quel preciso risultato, se coincide la cpu esegue i calcoli in modo

corretto, ah, dimenticavo, la matrice ottagonale non è composta

da numeri interi, ma bensi, da stringhe di testo contenenti il numero

intero a 8 bit che viene convertito anchesso in real time da stringa

di testo in numero intero a 8 bit di eguale peso,

(utilizzo una stringa di testo per contenere il numero intero a 8 bit, per far

si che anche quando la cpu funziona male non può alterare il valore

della verifica da una stringa di testo, non essendo numericamente valida)

tieni presente

che se lavori con 8 core, questa procedura la devi moltiplicare

per 8 :asd: , tornando a noi, non sono solo numeri primi.

apix_1024

bonis62 ha scritto:

in realta non sono 100 milioni di numeri primi e basta,
calcolando che una routine secondaria lancia (in multithread)

il numero primo scoperto alla funzione int8(sqr(Atan2))

che estrae un numero intero a 8 bit basato sulla radice quadrata

dei tangenti atan2; i due tangenti atan2 usano come vettori:

1°) il numero primo scoperto come coordinata X

2°) il fattoriale "mersennizato" calcolato partendo dal

1° numero primo scoperto fino a quello in lavorazione

come coordinata Y, il numero intero a 8 bit risultante

(convertito da numero a doppia precisione in virgola

mobile, in intero arrotondato)

è il riferimento per la verifica del risultato, quindi nello

stesso momento da una matrice ottagonale precacolata,

viene estratto un numero intero a 8 bit e viene confrontato

con quel preciso risultato, se coincide la cpu esegue i calcoli in modo

corretto, ah, dimenticavo, la matrice ottagonale non è composta

da numeri interi, ma bensi, da stringhe di testo contenenti il numero

intero a 8 bit che viene convertito anchesso in real time da stringa

di testo in numero intero a 8 bit di eguale peso,

(utilizzo una stringa di testo per contenere il numero intero a 8 bit, per far

si che anche quando la cpu funziona male non può alterare il valore

della verifica da una stringa di testo, non essendo numericamente valida)

tieni presente

che se lavori con 8 core, questa procedura la devi moltiplicare

per 8 , tornando a noi, non sono solo numeri primi.

io che sono ingegnere meccanico se dovessi scrivere in formule quello che hai appena detto credo che un 15minuti buoni mi servirebbero! complimenti!! domani magari lo butto in esecuzione così vediamo quanto ci mette il il mio pippa II X4 a fare sta robetta :asd: :asd: :asd:

Xstreme

apix_1024 ha scritto:

io che sono ingegnere meccanico se dovessi scrivere in formule quello che hai appena detto credo che un 15minuti buoni mi servirebbero! complimenti!! domani magari lo butto in esecuzione così vediamo quanto ci mette il il mio pippa II X4 a fare sta robetta :asd:

una volta che hai scritto in concetto umano le formule descritte,

dovresti...dopo... tradurle ..alcune ottimizzate in C...è alcune

ottimizzate in Assembler...tieni presente...che per far lavorare

la CPU al 100 % devi fargli arrivare i calcoli in parallelismo puro

altrimenti il load del 100 % te lo scordi, quindi un compilatore

alla Visual basic & Company al massimo lo puoi utilizzare per

scrivere l'interfaccia interfacciandolo ai moduli c e assembler,

ti faccio presente che la routine che rallenta i calcoli sono

le barre barre di avanzamento di windows vista e seven,

che sono progettate da uno che secondo me il pc lo usa

al massimo per fare i conti della spesa :fiufiu: , infatti se noti

il refresh dell'interfaccia grafica l'ho minimizzato ai minimi

termini, dovrei riscrivere l'interfaccia escludendo il s.o.,

ma per adesso va bene cosi, a livello numerico un (+1) incremento

della barra di avanzamento ti fa perdere ben 6 ms che per

uno scroll di una barra, mi sembrano un pò eccessivi , non credi ?,

per arrivare al "purismo" si dovrebbero fare i calcoli senza la

parte grafica di mezzo, ma ... l'abito fà il monaco da queste parti :asd:

se vuoi vedere un esempio pratico:

http://www.xstreme.it/differenza.exe

è una semplice elevazione di numeri interi ""superparallelamenteottimizzata""

( la puoi fare con la calcolatrice non scientifica )

ps

io sono (ero) un sound ingegner, non il solito, mi occupavo

di progettare, configurare, finalizzare D.A.W. ;

(sto parlado da 48 tracce in sù, per spiegarmi meglio)

da lì è nata l'esigenza di avere delle pezze software

per avere tempi di latenza molto bassi, quindi, con

l'andare del tempo, mi sono perso nel mare infinito

della programmazione a basso livello ed eccoci

qui.... :ciao:

apix_1024

caro ragazzo tu hai le palle cubiche! :clapclap:

cmq ho provato il nuovo eseguibile....

millesecondi impiegati con interfaccia grafica attiva : 926

millesecondi impiegati con interfaccia grafica NON attiva : 731

sticazziii :AAAAH::AAAAH:

Totocellux

ti siamo tutti grati per il tempo che stai utilizzando insieme a noi, e personalmente ne seguo con estremo interesse lo sviluppo

Se avessi altro tempo a disposizione parteciperei volentieri più attivamente, ma purtroppo non lo posso avere :muro:

Ho notato che ora, lato riconoscimento hardware, utilizzi l'MSR Walker che CrystalMark ha sviluppato per il suo CrystalCpuId.

Ben fatto, meglio evitare rogne ulteriori e dedicarti esclusivamente allo sviluppo dell'interfaccia e dell'algoritmo

Ho visto anche che utilizzi Microsoft ASM v1.0

Soprattutto in ambiente Vista e 7 per agganciarti meglio (con le giuste librerie) con la GUI del s.o. dovresti passare allo sviluppo tramite .NET.

Questo ti permetterebbe senz'altro di interfacciarti più fluidamente e senza il verificarsi di ulteriori rallentamenti.

Quindi se non vuoi riscrivere d'accapo tutto il lavoro in un futuro prossimo, ti consiglio quanto prima di passare quantomeno a C# (Sharp) quindi a Visual Studio 2005-SP1/2008 o addirittura al nuovo 2010.

Un'ultima cosa: comprendo che sono solo righe di codice per un test, ma dovrei farti un piccolo appunto

http://www.xstreme.it/differenza.exe

2^3=4

2^4=8

2^5=16

etc. etc.

in partenza ti deve esser sfuggito un incremento sul fattore di potenza all'interno del primo ciclo nell'output di scrittura, e il risultato è tutto slittato indietro di un fattore

Continua con questo impegno, che riuscirai/riusciremo a tirar fuori belle cose

apix_1024

bravo toto l'avevo notato anche io lo slittamento del risultato

cmq per fare i 100M numeri primi e la smatricizzazione il mio pippa II X4 dovrebbe lavorare 24/27 per ben 64giorni :asd: :asd: :asd:

Xstreme

Totocellux ha scritto:

ti siamo tutti grati per il tempo che stai utilizzando insieme a noi, e personalmente ne seguo con estremo interesse lo sviluppo
Se avessi altro tempo a disposizione parteciperei volentieri più attivamente, ma purtroppo non lo posso avere

Ho notato che ora, lato riconoscimento hardware, utilizzi l'MSR Walker che CrystalMark ha sviluppato per il suo CrystalCpuId.

Ben fatto, meglio evitare rogne ulteriori e dedicarti esclusivamente allo sviluppo dell'interfaccia e dell'algoritmo

Ho visto anche che utilizzi Microsoft ASM v1.0

Soprattutto in ambiente Vista e 7 per agganciarti meglio (con le giuste librerie) con la GUI del s.o. dovresti passare allo sviluppo tramite .NET.

Questo ti permetterebbe senz'altro di interfacciarti più fluidamente e senza il verificarsi di ulteriori rallentamenti.

Quindi se non vuoi riscrivere d'accapo tutto il lavoro in un futuro prossimo, ti consiglio quanto prima di passare quantomeno a C# (Sharp) quindi a Visual Studio 2005-SP1/2008 o addirittura al nuovo 2010.

Un'ultima cosa: comprendo che sono solo righe di codice per un test, ma dovrei farti un piccolo appunto

http://www.xstreme.it/differenza.exe

2^3=4

2^4=8

2^5=16

etc. etc.

in partenza ti deve esser sfuggito un incremento sul fattore di potenza all'interno del primo ciclo nell'output di scrittura, e il risultato è tutto slittato indietro di un fattore

Continua con questo impegno, che riuscirai/riusciremo a tirar fuori belle cose

che debugger hai utilizzato ?

principino1984

apix_1024 ha scritto:

bravo toto l'avevo notato anche io lo slittamento del risultato
cmq per fare i 100M numeri primi e la smatricizzazione il mio pippa II X4 dovrebbe lavorare 24/27 per ben 64giorni :asd:

e non ti sembra un buon motivo per buttarlo al cesso? :asd:

bonis62 ha scritto:

che debugger hai utilizzato ?

il debugger utilizzato è la sua infinita saggezza :asd: !

Xstreme

principino1984 ha scritto:

e non ti sembra un buon motivo per buttarlo al cesso?
il debugger utilizzato è la sua infinita saggezza !

no.....perchè.......

ci sono un pò di cose che non quadrano :knuppel2: , volevo verificare di persona.

Totocellux

bonis62 ha scritto:

che debugger hai utilizzato ?

ad un primo approccio non ne utilizzo alcuno ...... semplicemente visualizzo il linkeditato (l'eseguibile) in raw, o in alcuni casi utilizzo un editor esadecimale e mi oriento lì dentro