Xstreme

se sai programmare allora ti faccio vedere questa cosa, perchè sei in grado di intuirne la lavorazione : http://www.xstreme.it/b_for_t.zip tanto per iniziare a vedere la demo , appena lanciata, trascina con il mouse la scritta del tuo nick fino all'angolo inferiore destro con media/lenta velocità e poi lascia il tasto del mouse, poi attendi, ogni quattro secondi vi è una variazione dell'algoritmo di controllo del multithread, ovviamente visto che sei un programmatore vedendo la demo credo che intuirai +o- come è fatta e come sono gestiti singolarmente i punti. Ovviamente ti puoi divertire con il mouse a disegnare sullo screen altre forme e vedere cose interessanti , se poi tieni aperto la cronologia di utilizzo della cpu puoi vedere il codice lavore sui cores... (penso che se analizzi il codice vedrai una pezza in assembler abbastanza lunga, ma non ha nulla a vedere con la grafica, è uno spartano mini O.S. che ho scritto per bypassare alcune gestioni del win32 a modo mio) con i numeri primi non potevo farti vedere come io gestisco il multithreading, a livello grafico mi sembra un pò più visibile. Fermo restando che la tua teoria è esattissima. ah.... per uscire premi il tasto ESC. ps carino ASP macchinoso (secondo me) , ma ti da belle soddisfazioni.

---------------------------------------------------------------- ma cosa può entrarci questo.... perche volevo sapere se hai esperienza sul campo oltre che una ammirevole teoria . quindi cosa c'entra anche questa domanda?..... si, è un OT, ero curioso di sapere come ti sembrava.

posso farti due domande ? cosi per dirne una, io ho cominciato a programmare da quando uscì il PET2001, tu da quanto programmi ? la seconda potrebbe essere : questi hanno scritto un completo sistema oprativo multithread che gira su floppy da 1,44, funziona, lo hai provato ?... MenuetOS

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.

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 Multithreading with C and Win32

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 ?

quando la logica diventa un eccezzione per spiegarla occorre un altra eccezzione (autore : io)

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 ?

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

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.

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....

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 .

se provi i livelli 1 2 4 8 e 24... dovrebbe funzionare tutto, gli altri livelli li sto ancora ottimizzando....

mi servirebbe una cortesia, il risultato esatto del livello 1 con Primecores appena lanciato. solo per chi ha un quad core o superiore. grazie

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.

ok, tra una cosa e l'altra ho quasi terminato, se mi date l'ok trasformo questa pre release in final, aspetto i vostri commenti.... http://www.xstreme.it/PrimeCores2010_preR.zip

no, non ci crederai ma è lo scrausissimo MinGW ehm ottimizzando ottimizzando ....... Numeri Primi Scoperti : 45599980 In 23571 Millisecondi 99999989 199999991 199999993 199999995 199999997 199999999 Numeri Primi Scoperti : 78001134 In 39580 Millisecondi

sei mitico :clapclap:

ah a titolo personale, cioe, curiosità mia, a parte l'interfaccia grafica tirata su con blitzmax, il resto si vede con cosa è scritto ? :cheazz:

il giocattolo se lo metti a 4.1 ghz quanto ti fà ?

Scusa, quando ho postato avevo sonno, e sono stato molto telegrafico, ma non era per il.... carico.... il test, solo per vedere sè funzionava su CPU diverse; quasi sei milioni di numeri primi in 3 secondi e rotti....... due milioni di numeri primi al secondo, ....non è male ...credo ...

Ciao, Per cortesia , me lo potete testare ? Grazie. http://www.xstreme.it/pcr.zip

mi hai chiesto del ........ 7919 2/ constant maxp : primes ( -- n ) here maxp 1 FILL 1 ( count, including 2 ) maxp 0 DO I here + C@ IF I 2* 3 + ( dup .) DUP I + ( prime current ) begin DUP maxp U o del ..... top = 50 logical*2 flags(top) integer*2 i,j,k,count,iter,prime n = long(362) do 92 iter = 1,10 count=0 i=0 do 10 i = 1,top 10 flags(i) = .true. do 91 i = 1,top if (.not. flags(i)) go to 91 prime = i + i + 3 count = count + 1 k = i + prime if (k .gt. top) go to 91 do 60 j = k, top, prime 60 flags(j) = .false. 91 continue 92 continue write (9,*) count," primes in ",(long(362)-n)/60.0," seconds " pause end molto interessante per le matematiche è il compilatore Haskell primes = sieve [ 2.. ] where sieve (p:x) = p : sieve [ n | n 0 ]

Java : portabilità, discretamente veloce ma poco "commerciale" C++ : portabilità prossima allo 0, veloce PureBasic : Tantovale programmare in C++ Visual Basic : la patria dei BUG Flat Assembler : Bello e impossibile C : librerie scadenti :perfido: C# : indissolubile dal Framework .NET BlitzMax : Gui editor Inesistente ma compilatore quasi a livello Assembler :AAAAH: Delphi : carino ma vedi il C PowerBasic : più Basic Che Power Visual .NET: indissolubile dal Framework .NET :uglystupid2: Fortran : ottimo sui banchi di scuola, ma li rimane ? :cheazz: Ansi C : Dinamico, Stabile, ma più macchinoso del C++