HT questo sconosciuto

[peter2]

Originariamente inviato da MaxArt
Non ha detto questo: ti ha solo dato un metodo per verificare se l'HT è attivo oppure no.

appunto, e dato che non appare la doppia finestra secondo lui l'ht non è attivo=>50%, che non è la tua tesi, giusto?

Berno ha ragione. Che dubbi avresti?
Un'applicazione multithreaded gira meglio su un sistema a più processori, cosìcché i singoli thread che compongono il programma si distribuiscono sui processori disponibli.

quindi secondo te un applicazione scritta e compilata in multithreading sfrutta automaticamente il doppio prcessore? ...

Poco. Il compilatore parallelizza quel che può.

Non uso il Fortran e non so che opzioni dovresti mettere. Tu fa' delle prove! Usando magari un programmino di cronometro dei thread, ora non mi ricordo come si chiami...

provo, ma faccio un backuppino prima

quante cose si imparano!!!

[peter2]

aggiornamento!!!!
nella gestione risorse c'è la possibilità di graficare l'utilizzo di più cpu in un grafico solo: da me era abilitato!!! ecco perchè non le vedevo tutt'e due!!!!
allora il 50% di utilizzo è reale: nel senso che usail 50% di ogni core logico, giusto?

[MaxArt]

Originariamente inviato da peter2
quindi secondo te un applicazione scritta e compilata in multithreading sfrutta automaticamente il doppio prcessore? ...

E direi di sì, altrimenti che senso avrebbe tutto quello sbattimento?

Quando all'HT attivo o meno: non so che risponderti! Non so che programmi usi, e purtroppo non ho un P4 per verificare di persona.

[peter2]

Originariamente inviato da MaxArt
E direi di sì, altrimenti che senso avrebbe tutto quello sbattimento?

quindi a parte tmpgenc nessuno software commerciale (3dstudio o autocad per esempio) è scritto in multi threading... e allora chi caspita lo usa sto multithreading???

[MaxArt]

Originariamente inviato da peter2
quindi a parte tmpgenc nessuno software commerciale (3dstudio o autocad per esempio) è scritto in multi threading... e allora chi caspita lo usa sto multithreading???

Se un software è scritto per multithreading ciò non vuol che che per ogni cosa che fanno è utile o necessario il multithreading.

[jappilas]

Originariamente inviato da peter2
quindi secondo te un applicazione scritta e compilata in multithreading sfrutta automaticamente il doppio prcessore? ...

da un lato sì perchè alla fine, "scritta" vuol dire in base a determinati criteri di SW design a cui accennavo in altre occasioni e che non si limitano a mettere fork() oppure new CWinThread nel codice
(il non rispettare tali criteri, ad esempio non proteggere le variabili condivise da sezioni critiche o semafori, ha una grossa chance di produrre errori/crash/condizioni di race al momento dell' esecuzione, anche su un sistema monoprocessore)
e dall' altro "dipende" perchè "compilata" implica che, al momento dell' esecuzione, si ha una libreria, compilata staticamente o dinamicamente, che gestisce i thread multipli appartenti allo spazio di una stesso processo: tale gestione può seguire uno di vari modelli possibili, alcuni dei quali, contrariamente a quanto comunemente supposto (come leggevo poco fa qui a proposito della libreria GNU Pthread ) non scalano su più CPU, per via della politica di thread scheduling "interna" al programma

C'è anche da tenere presente che, un programma con thread multipli attivi, ci si aspetta che faccia richieste concorrenti al kernel per interagire con l' I/O, nel caso questo sia di esclusiva competenza del kernel (come nel caso di linux e unix)
ma se il kernel non serve richieste concorrenti, magari perchè i suoi sottosistemi devono sottostare a un "lock" comune (accade in versioni dei kernel sia linux sia bsd... ) è il kernel a fare da "collo di bottiglia"... e infatti molti sforzi si sono fatti o si stanno facendo per rimuovere il global lock, o almeno ridurre il numero di system call affette da esso
TRA L' ALTRO

[MaxArt]

Originariamente inviato da jappilas
TRA L' ALTRO

Minkia che rispostona!

[jappilas]

la rispostona si riferiva agli accorgimenti implementati da sviluppatori di un po' tutti gli OS (linux, bsd, anche la M$ su NT) per, "tra l' altro",
rimuovere il global lock e trasformarlo in mutue esclusioni a più elevata "granularità"...
ridurre le latenze delle system call del kernel , ricorrendo a vari metodi , tra gli altri () la kernel preemption ...

... aventi lo scopo ultimo di migliorare l' efficienza, la reattività del sistema sotto carico, o almeno della sua gui ecc..

...e che adesso si danno molto per scontate ma che sui kernel monolitici sono state a lungo sospirate, e che altri progetti più sconosciuti (sto pensando ad atheos, oppure i kernel L4 abbinati al DOpE gui engine) invece integravano fin dall' inizio ...