Quote:
Originariamente inviato da Ratatosk
Vero. Il mio dubbio sull'utilità comune di ciò rimane, comunque. Quali software potranno veramente beneficiare di molti core, a parte quelli di scarsa diffusione perché di uso essenzialmente professionale?
L'utilità del dual è indipendente da ciò, visto che la presenza del secondo core garantisce un offload dal primo dei compiti ordinari in modo da dedicarlo all'uso intensivo eventualmente richiesto, ma quella del quad o octa/hexa mi rimane abbastanza oscura. Tutto ciò senza contare che anche un gioco spacchettato per servirsi del multicore verrà spacchettato sempre e comunque in base a diverse funzioni (GUI, Fisica, IA...) e sono poche quelle che richiedono una potenza di calcolo tale da necessitare un core esclusivamente dedicato a loro. Magari in futuro servirà, ma non certo nel 2009 :>
|
Sull'utilità del dual non c'è dubbio, ma ciò deriva dal fatto che le applicazioni attuali sono tutte single-threaded e passare da 1 a 2 core porta benefici tangibili senza dover ricompilare. I oggi cores si dedicano ad una applicazione per volta, applicazione che comunque lavora ad un thread alla volta.
Al contrario, col multi-core massiccio, ogni singola applicazioni potrebbe diventare multi-threaded (ovviamente riprogettandola/ricompilandola), con i vantaggi che ne conseguono (ed ecco che il compilatore ricoprirà un ruolo essenziale nell'ottimizzazione dei software).
Non è necessariamente vero che ogni core va assegnato ad una mansione: prova ad immaginare un engine fisico multi-threaded in cui ogni singolo oggetto è assegnato dinamicamente ai vari core. Stessa cosa vale per l'AI: ogni entità potrebbe avere suo thread separato (eppure stiamo parlando di una parte di un videogame) anzichè essere "esaminate" una per volta da un solo core.
In ambito "applicativo" ciò si sta già verificando (alcuni compressori multi-thread scalano linearmente, pur essendo nell'ambito della singola applicazione, in presenza di più cores).
In ambito "office", l'applicazione di un filtro ad una immagine anzichè portare in full un solo core e lasciare idle gli altri, potrebbe essere applicato a "n" parti dell'immagine ogniuna assegnata ad un core diverso... con tutti i vantaggi che ne conseguono.
Da ciò (apparte il discorso OC che abbiamo detto essere "di nicchia") non sono in grado di comprendere l'utilità di poter variare dinamicamente il clock di ogni singolo core, visto che la tendenza sarà quella di portare tutti i core in full pur essendo nell'ambito della singola applicazione.
Il clock "separato" va bene oggi, quando comprimere con winzip porta in full un solo core. Ma domani (con codice multi-threaded), comprimere un file porterà in full tutti i cores, vanificando quindi l'opportunità di cloccare separamente i cores.
(tutto ciò, ovviamente, IMHO).