Originariamente inviato da aleritty
C'è da dire che in ambiente *nix dato che la maggior parte dei programmi è possibile compilarli sulla macchina su cui gireranno, se il programma rispetta i requisiti di cui sopra, è lo stesso programma ad adattarsi un minimo al numero di processori, quindi girerà meglio!

Faccio un esempio banale, office per windows è ottimizzato per un solo processore per compatibilità... Io openoffice me lo potrei compilare sul mio 4 core ed ottenere un incremento di prestazioni notevole! Lo stesso per molte altre cose!
Ti sbagli; il vantaggio di compilarsi da sé i programmi ottimizzati per la tua specifica macchina è limitato al tweaking di qualche opzione del compilatore, tra cui:
  • attivare i set di istruzioni avanzati come MMX, SSE, SSE2, di cui beneficiano le operazioni su numeri in virgola mobile;
  • se si ha un processore a 64 bit, compilare a 64 bit invece di usare i binari a 32 bit, ottenendo così miglioramenti di prestazione grazie ai registri aggiuntivi (di cui beneficiano in particolare le chiamate a funzione), alla certezza che MMX, SSE, SSE2 sono presenti e alla maggiore velocità con cui vengono trattati gli interi a 64 bit;
  • dire al compilatore per quale categoria di processori ottimizzare il programma, in base alla quale prediligerà una traduzione o l'altra di certi costrutti in codice macchina, o deciderà se vale la pena o meno di effettuare certe ottimizzazioni; alcune ottimizzazioni, infatti, su macchine vecchie possono rendere il codice più veloce, ma su processori moderni possono rallentarlo (ad esempio perché vanno ad interferire con il branch predictor);

tutte cose che in alcuni casi possono dare sensibili incrementi di prestazioni, ma che non hanno nulla a che vedere con il multithreading.
In generale invece l'adeguamento di un'applicazione per l'impiego di più core è un'operazione da effettuare manualmente: non è una semplice opzione del compilatore, ma la modifica del codice perché impieghi maggiormente i thread. Va detto comunque che se già l'applicazione è multithreaded non c'è molto di più da fare, i binari compilati su un'altra macchina vanno più che bene: i thread creati dall'applicazione infatti vengono distribuiti automaticamente dallo scheduler del sistema operativo sui core che questo ritiene più adeguati.
Comunque tieni conto che i binari distribuiti solitamente sono ottimizzati per la famiglia di processori più diffusa al momento; ogni nuova versione del compilatore Microsoft Visual C++, ad esempio, cambia il valore di default dell'opzione del processore target in base ai processori più diffusi.
Ti adoro

Tornando a noi, allora non saresti d'accordo che intel (visto che è stata lei ad aprire le danze sui 6 core) avrebbe dovuto aspettare un po' e dare un po' di fiato alle softwarehouse, che mi sembrano un po' in ritardo ed in difficoltà sul discorso multicore?
Io sinceramente non sono un esperto, ma penso che oltre ai core ci siano altre possibilità di miglioramento, che non richiedono modifiche dal punto di vista del software. Alcune le hai elencate te, come l'aumento della cache, altre possono essere il miglioramento del processo produttivo (dai vecchi 65nm siamo passati a 45nm, con la Intel che vuole scendere con i prossimi i7 mobile a 32nm, anche se mi sembrano una mezza schifezza questi processori).
Questo ha permesso di ridurre i consumi di corrente e la creazione di calore, tanto che c'è gente che con il raffredamento ad aria ha overclockato il proprio 920 stabilmente sopra i 4Ghz.
Perchè puntare allora sul numero di core (che se non è implementato nel software, non ci fai nulla) e non sul processo produttivo e frequenza?
Il miglioramento del processo produttivo ha come esito principale la riduzione delle dimensioni del core, per cui, mantenendo un form factor analogo a quello attuale, se ne possono far stare di più sullo stesso die, per cui un suo esito naturale sono appunto i processori multicore. Inoltre la domanda per la parallelizzazione in effetti c'è: se il single threading è attualmente molto diffuso nelle applicazioni di piccole dimensioni, è da tanto che comunque i thread vengono impiegati all'interno dei programmi.
Se anche fossero utilizzate solo applicazioni single-threaded, i vari core verrebbero comunque sfruttati (almeno in parte) poiché i processi in esecuzione in contemporanea sono sempre tanti, e ad ogni processo corrisponde uno o più thread. L'inefficienza, da questo punto di vista, sta nel fatto che molte computazioni "pesanti" riguardano un singolo thread in un singolo processo, ma comunque molte applicazioni sono già state ottimizzate per lavorare su più thread: l'elaborazione di un video, ad esempio, può procedere in parallelo separandolo virtualmente in due tronconi separati, la compilazione di un grosso programma si può velocizzare eseguendo contemporaneamente più istanze del compilatore, ognuna delle quali si occupa di metà dei file da compilare, un videogioco si può separare (ad esempio) in un thread che si occupi del rendering video, uno dell'output audio, uno della gestione dell'IA dei nemici, ..., un server web può gestire ogni richiesta in un thread separato, idem per i DBMS e in generale per le applicazioni che da sempre devono gestire più richieste concorrenti o che sono sempre state eseguite su server multiprocessore. In generale il problema è facile da risolvere se l'elaborazione può procedere indipendentemente in tronconi separati, più difficile se si parla di algoritmi non parallelizzabili (come quelli che vengono impiegati in alcune applicazioni scientifiche).

Sulla faccenda dell'overclocking, credo che sia per ragioni di stabilità: tieni presente che l'overclocking, anche se il PC in generale va tranquillamente, può dare problemi se la CPU viene tenuta al 100% per lunghi periodi (rendering 3D/video, calcoli scientifici, ...), o può causare dei crash o far sì che la CPU dia risultati errati solo sporadicamente, per cui spesso i due eventi non vengono messi in relazione; a questo proposito ti consiglio di dare un'occhiata a questo post. Non so tu, ma io preferisco un PC perfettamente stabile piuttosto che uno più veloce del 20% ma che ogni tanto dà i numeri.
Poi il discorso sul raffredamento a liquido, non capisco perchè non si riesca a svilupparlo. Oggi costa tanto, ma ciò è dovuto anche al fatto che nessuno o quasi lo usa. E' un po' come per tante altre tecnologie, quando finalmente diventano diffuse scendono a prezzi accettabili.
Il ragionamento dei produttori è semplice: il raffreddamento ad aria costa meno (e costerà sempre meno, poiché è un sistema molto più semplice e dalla componentistica sicuramente molto più economica), la velocità delle CPU attuali va più che bene per la maggior parte degli scopi senza overclockare, non c'è motivo di usare il raffreddamento a liquido sulla stragrande maggioranza dei PC.
In effetti io uso lo stesso PC (AMD Athlon 3800+) dal 2006 e non ho motivo di cambiarlo, almeno per il momento, dato che per le cose che faccio (internet, posta elettronica, programmazione, OpenOffice, qualche vecchio gioco e poco altro) va benissimo, e un semplice upgrade della RAM a 3 GB lo ha reso in grado di far andare senza troppa fatica un paio di macchine virtuali insieme.
Visto poi che il 90% della gente che usa i PC attualmente li usa quasi soltanto per internet (più qualcosa di ufficio), si capisce bene come la tendenza attuale sia verso PC che piccoli, economici e dai bassi consumi, piuttosto che verso macchine estremamente potenti: il caso dell'Intel Atom (che nelle sue versioni più diffuse neanche supporta i 64 bit ed è decisamente indietro quanto a "trucchi" per velocizzare la pipeline) e dei netbook è emblematico.
In generale comunque prendi questi miei pareri con le pinze, visto che personalmente sono più nel software che nell'hardware.