[jrambo92]

Nel frattempo blackshard ha aggiornato il post

Originariamente inviato da blackshard

Ok grazie per la riprova.

Comunque quel comportamento è banale ed è così da tempo immemore con Windows.

Quel comportamento è la causa del famigerato bug del c&q dei Phenom I che, sottolineo, non è affatto un bug! I Phenom I (e anche i Turion ZM/RM e QL, piattaforma Puma) hanno la possibilità di cambiare frequenza operativa per singolo core, invece che tutti assieme come nei Phenom II e i Core 2. Questo causa problemi allo scheduler di windows che invece è pensato per funzionare su sistemi multiprocessore dove tutti i processori hanno la stessa frequenza operativa. Quindi lo scheduler passa i thread da un core all'altro in continuazione al fine di bilanciare il carico. Sui phenom I questo giochetto causa fino ad un 25% di prestazioni in meno.
Al contrario, lo scheduler di Linux lavora molto meglio da questo punto di vista.

edit: ho anche alcuni dubbi sul turbo mode dei processori i7/i5. Il comportamento dello scheduler è appurato, come sia possibile che il turbo mode funzioni correttamente è probabilmente dovuto al fatto che Windows 7 ha introdotto il "core parking": se non è necessario che un core sia attivo, lo si può parcheggiare e non utilizzarlo per alcun thread. Questa feature a quanto pare è attiva solo con i5 e i7, mentre gioverebbe in modo notevole anche sui processori Phenom I e Phenom II, visto che anche i Phenom II possono variare la frequenza operativa per core (la famosa modalità unganged di k10stat, che non ha nulla a che fare con i memory controller) ma espongono via ACPI solo l'interfaccia per variare la frequenza per tutti i core contemporaneamente. Inoltre schedulare sempre sullo stesso core un thread ha il vantaggio di migliorare l'hit rate della cache, e uno scheduler come quello di windows privilegia processori con grandi e veloci cache L2 condivise come i Core 2 a discapito delle piccole cache L2 separate dei Phenom.