Due patch Microsoft specifiche per sistemi AMD Bulldozer

Due patch Microsoft specifiche per sistemi AMD Bulldozer

Microsoft rilascia due aggiornamenti per sistemi operativi Windows 7 e Windows Server 2008 R2, con i quali meglio gestire le peculiarità architetturali delle soluzioni Bulldozer

di pubblicata il , alle 09:41 nel canale Sistemi Operativi
AMDMicrosoftWindows
 

Poco meno di un mese fa Microsoft ha rilasciato una patch per i sistemi operativi Windows 7 e Windows Server 2008 R2, con la quale incrementare le prestazioni velocistiche dei sistemi basati su processori AMD appartenenti alla famiglia Bulldozer: ci riferiamo quindi alle CPU AMD FX e a quelle Opteron 4200 e Opteron 6200. La patch è rimasta online per poche ore per venire poi prontamente rimossa da Microsoft, in quanto non ancora competa e pronta per essere resa pubblica.

Alla base di questa patch una nuova logica di gestione dei core a disposizione del sistema, in grado di meglio beneficiare della particolare architettura di queste soluzioni. Le CPU Bulldozer, infatti, implementano un approccio Simultaneous Multithreading: ogni coppia di core condivide alcune risorse, quelle legate alla componente di calcolo in virgola mobile oltre alla cache L2 da 2 Mbytes, avendone a disposizione altre completamente indipendenti quali la parte di calcolo integer.

Nella giornata di ieri Microsoft ha rilasciato due patch per i due sistemi operativi sopra menzionati, specifiche per le soluzioni AMD della famiglia Bulldozer:

http://support.microsoft.com/kb/2646060
aggiornamento che consente di disabilitare in modo selettivo la funzionalità di stazionamento Core in Windows 7 o in Windows Server 2008 R2

http://support.microsoft.com/kb/2645594
aggiornamento per i computer che presentano un FX AMD, un 4200 di AMD Opteron, AMD Opteron 6200 serie processore o installato e che eseguono Windows 7 o Windows Server 2008 R2

Grazie alle due nuove patch il sistema operativo utilizzerà i core a disposizione in modo tale da occupare i threads sfruttando al meglio la logica di funzionamento del Simultaneous Multithreading. Questo implica, ad esempio, che durante l'elaborazione di un programma che utilizzi solo due core a venir sfruttati non siano due core che appartengono allo stesso modulo Bulldozer, quindi con risorse in condivisione tra di loro, ma siano selezionati core appartenenti a due distinti moduli. Le logiche di funzionamento in ogni caso sono differenti, portando a migliorare sia le prestazioni velocistiche sia i consumi istantanei a seconda dello specifico carico di lavoro richiesto alla CPU.

La conseguenza diretta, per i possessori di sistemi Bulldozer, dovrebbe essere un incremento delle prestazioni velocistiche medie soprattutto con quelle applicazioni che non sfruttano contemporaneamente tutti i core di processore che queste architetture mettono a disposizione. Se l'applicazione è in grado di saturare tutti i threads a disposizione, infatti, le risorse di elaborazione vengono tutte occupate rendendo ininfluente dal punto di vista prestazionale spostare alcuni threads in esecuzione da un core all'altro.

In ogni caso questa coppia di patch permette solo in parte di sfruttare tutte le potenzialità dell'architettura Bulldozer; la migliore gestione arriverà solo con sistema operativo Windows 8, all'interno del quale i sistemi basati su questo tipo di architettura con Simultaneous Multithreading vengono riconosciuti in modo nativo.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

29 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
PhoEniX-VooDoo12 Gennaio 2012, 10:12 #1
farete dei test?
Dumah Brazorf12 Gennaio 2012, 10:12 #2
Un due bench prima/dopo?
Aenil12 Gennaio 2012, 10:35 #3
sembra interessante ma concordo che servono dei Test!
birmarco12 Gennaio 2012, 11:33 #4
Si si ci vogliono dei test prima e dopo
devilred12 Gennaio 2012, 12:09 #5
ma quali test??? si parla nella migliore delle ipotesi di un aumento di prestazioni che non supera 1/2%. come ho scritto su un altro forum: questi perdono i buoi e cercano le funi.
Pier220412 Gennaio 2012, 12:29 #6
Originariamente inviato da: devilred
ma quali test??? si parla nella migliore delle ipotesi di un aumento di prestazioni che non supera 1/2%. come ho scritto su un altro forum: questi perdono i buoi e cercano le funi.


Se non hai fatto i test, come fai ad affermare che l'aumento delle prestazioni si ferma a un 1 / 2 % ? Chiedo.

Poi bisogna anche vedere il tipo di applicazioni, come scritto nella news queste patch danno il meglio con programmi che sfruttano l'architettura BD nel calcolo parallelo.
Phoenix Fire12 Gennaio 2012, 12:44 #7
Originariamente inviato da: Pier2204
Se non hai fatto i test, come fai ad affermare che l'aumento delle prestazioni si ferma a un 1 / 2 % ? Chiedo.

Poi bisogna anche vedere il tipo di applicazioni, come scritto nella news queste patch danno il meglio con programmi che sfruttano l'architettura BD nel calcolo parallelo.

piccola correzione, visto l'architettura modulare di BD, con i metodi "standard" di assegnazione poteva capitare che su 4 core dove ognuno ha 3 moduli, venissero usati 3 moduli dello stesso core, mandando a quel paese il paralleilismo della cpu, data la condivisione di risorse tra moduli.
Le patch quindi mirano a far attivare moduli so "core" separati in modo da massimizzare le performance, l'effetto però non si nota quando tutti i "core" sono sotto utilizzo, ma quando alcuni core sono spenti


ps passatemi il termine core e modulo anche se non sono precisi per AMD
calabar12 Gennaio 2012, 12:46 #8
Lo afferma probabilmente perchè così dicono i test fatti da AMD (click).

Mi chiedo in ogni caso che fine abbiano fatto gli incrementi mirabolanti che in alcuni casi si ottenevano impostando a mano l'affinità dei core.

Mi chiedo anche che ne sia stato di tutti quei discorsi fatti prima dell'uscita di BD.
Anche io ero dell'idea che associando prima un thread per ogni modulo si potesse avere un elevato ipc, ma poi, dopo diverse discussioni sul topic "aspettando" pareva che l'insieme di frequenze più elevate (grazie al power gate sui moduli) e sfruttamento della cache condivisa tra i core di un modulo dovesse fare in modo che lo sfruttamento di tutti i core di un modulo prima di passare allo sfruttamento dei moduli successivi fosse la soluzione migliore e più efficiente.

Tra l'altro mi chiedo come possano esserci miglioramenti così risicati rispetto alla situazione iniziale in cui windows usava i core di BD praticamente in modo casuale, eliminando di fatto i vantaggi di entrambe le soluzioni descritte prima.

Ovviamente le mie domande sono dovute anche al fatto che non sto più seguendo come prima l'evoluzione di questi processori.
Se qualcuno ha risposte adeguate, sarò lieto di levarmi i dubbi.
coschizza12 Gennaio 2012, 12:55 #9
Originariamente inviato da: Phoenix Fire
piccola correzione, visto l'architettura modulare di BD, con i metodi "standard" di assegnazione poteva capitare che su 4 core dove ognuno ha 3 moduli, venissero usati 3 moduli dello stesso core, mandando a quel paese il paralleilismo della cpu, data la condivisione di risorse tra moduli.
Le patch quindi mirano a far attivare moduli so "core" separati in modo da massimizzare le performance, l'effetto però non si nota quando tutti i "core" sono sotto utilizzo, ma quando alcuni core sono spenti


la patch fa l'esatto opposto cioè cerca di usare il minor numero di moduli in modo da poter spegnere quelli non attivi e attivare il turbo con frequenze elevate. E' proprio per il funzionamento che hai descritto tu che il buldozzer soffriva di consumi elevati anche con basso carico.

i benchmark su windows 8 mostrano infatti che i thread vengono indirizzati sugli stessi moduli in base alle loro dipendenze in questo modo i moduli non usati si spengono.
coschizza12 Gennaio 2012, 12:59 #10
Originariamente inviato da: calabar
Lo afferma probabilmente perchè così dicono i test fatti da AMD (click).

Mi chiedo in ogni caso che fine abbiano fatto gli incrementi mirabolanti che in alcuni casi si ottenevano impostando a mano l'affinità dei core.

Mi chiedo anche che ne sia stato di tutti quei discorsi fatti prima dell'uscita di BD.
Anche io ero dell'idea che associando prima un thread per ogni modulo si potesse avere un elevato ipc, ma poi, dopo diverse discussioni sul topic "aspettando" pareva che l'insieme di frequenze più elevate (grazie al power gate sui moduli) e sfruttamento della cache condivisa tra i core di un modulo dovesse fare in modo che lo sfruttamento di tutti i core di un modulo prima di passare allo sfruttamento dei moduli successivi fosse la soluzione migliore e più efficiente.

Tra l'altro mi chiedo come possano esserci miglioramenti così risicati rispetto alla situazione iniziale in cui windows usava i core di BD praticamente in modo casuale, eliminando di fatto i vantaggi di entrambe le soluzioni descritte prima.

Ovviamente le mie domande sono dovute anche al fatto che non sto più seguendo come prima l'evoluzione di questi processori.
Se qualcuno ha risposte adeguate, sarò lieto di levarmi i dubbi.


ti consilgio di leggere questo confronto tra win 7 e win 8, è ancora una situazione preliminare visto che win8 è in fase di alpha ma dovrebbe rispondere alla tua domanda

http://punto-informatico.it/3329436...scheduling.aspx
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^