6 core hanno senso?

[nelly369]

Intel ha annunciato l'uscita di un nuovo processore, il 980 x. La sua caratteristica principale è di aver sei core, che con l'Hypertrading diventano 12 threads. Appartiene alla serie core i7 extreme, con un prezzo di lancio di 999 dollari.

Quello che mi chiedo è Ma ce n'era bisogno?
A parte alcuni programmi professionali che sono stati ottimizzati per gli eventuali processori multicore, non è che siano così diffusi negli altri campi, come ad esempio nei videogiochi.

Una domanda per quelli più esperti, ma un programma ottimizzato su 4 core, come GTA IV, si distribuisce nella stessa maniera su 6 o ci sono problemi?

In altre parole un programma viene ottimizzato per qualsiasi numero di core, o specificatamente per due, tre (quelli passati della AMD), quattro e sei core?

Credo che comunque bisognerebbe che le case produttrici di processori lasciassero un po' di tempo alle softwarehouse di adeguarsi.

Che ne pensate?

[MItaly]

Originariamente inviato da nelly369
Una domanda per quelli più esperti, ma un programma ottimizzato su 4 core, come GTA IV, si distribuisce nella stessa maniera su 6 o ci sono problemi?

Tendenzialmente si distribuirà su quattro dei sei core.

Il punto attualmente è questo: attualmente aumentare il clock dei processori con lo stesso andamento di cinque anni fa sembra estremamente difficile, per cui i produttori di processori cercano altre vie per aumentare la velocità di esecuzione dei programmi. Alcune di queste possono essere l'aumento delle cache (diminuendo la necessità di accessi alla memoria la velocità può aumentare notevolmente), il miglioramento di tecnologie già impiegate da molti anni, come l'out-of-order execution e gli algoritmi per il branch prediction, e, naturalmente, la miniaturizzazione dei core e quindi l'inserimento di più core sullo stesso processore.
Ora, se delle altre tecniche citate precedentemente possono beneficiare tutti i programmi (salvo casi rari in cui il programma involontariamente "gioca contro" il branch predictor), il problema con le CPU multicore è che un'applicazione a thread singolo non ne può beneficiare, poiché essa è costituita da una sequenza di istruzioni non parallelizzabili; se anche l'algoritmo fosse parallelizzabile, il programma è ormai stato scritto e compilato per essere eseguito in un thread singolo, per cui non può essere spezzettato arbitrariamente in più thread.
Il cambiamento di mentalità che si impone nello scrivere i programmi non è banale: fino a qualche anno fa infatti i thread erano evitati se non servivano, poiché erano in una certa misura "costosi": su una macchina con meno core che thread da eseguire, il multithreading è implementato concedendo la CPU a turno a ciascun thread per un "quanto" di tempo (tipicamente attorno ai 50 ms per i sistemi desktop, sui 150 ms per i sistemi server). Quando il quanto di tempo si esaurisce entra in gioco lo scheduler del sistema operativo, che sceglie il prossimo thread da eseguire e lo fa partire.
Ora, il passaggio da un thread all'altro non è gratuito, e comporta una serie di operazioni (cambio del puntatore dello stack, ripristino dei registri, ...) che prendono del tempo. È appunto per questo motivo che non si usavano se non servivano.
Tuttavia con le CPU multicore i passaggi da un thread all'altro si riducono notevolmente di numero, e usare un singolo thread risulta essere uno spreco, visto che può essere eseguito solo su un core, mentre gli altri restano senza fare niente, per cui la tendenza attuale è programmare con più thread. Si pone però un problema: se alcune metodologie di programmazione a thread (ad esempio GUI thread-worker threads) sono consolidate, resta il fatto che molti algoritmi non sono parallelizzabili, oppure sono legati a risorse (disco, rete, ...) che sono sfruttate peggio se sono contese in continuazione da thread differenti. Non solo: la programmazione multithreading pone dei problemi non banali (le race conditions) che possono causare bug sottili ed estremamente difficili da trovare e risolvere (spesso si parla di heisenbug, bug non deterministici), e comunque le tecniche per proteggere i dati e il codice condivisi dai vari thread (mutex) possono diminuire di molto i vantaggi prestazionali che si avrebbero dall'impiego di più thread se questi continuano a cercare di accedere contemporaneamente agli stessi dati.

In sintesi: la programmazione multithreaded è una faccenda complicata, ma attualmente per migliorare le prestazioni dei processori la strada maestra è quella di aumentare il numero di core, dato che aumentare la frequenza operativa dei processori mantenendo i sistemi di raffreddamento e i prezzi correnti sembra essere praticamente infattibile, per cui bisogna adeguarsi.

[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!

Ovviamente anche su windows si può compilare i propri programmi ma è pratica molto meno comune...

[nelly369]

Ti adoro
Visto che ai miei topic non scrive quasi mai nessuno (tranne lucalicc ogni tanto), avere una risposta e per di più così complessa è un evento rarissimo ed apprezzato.

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?

L'ho visto fare più segnatamente sulla schede video, le quali da centrali termiche (praticamente con quello che scaldavano e consumavano ti ci potevi scaldare casa) sono diventate qualcosa di accettabile.

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.

[nelly369]

@aleritty: non avevo visto la tua risposta.
D'accordo se uno è in grado di compilare i programmi, può ottimizzarli, ma non credo che, ancor prima di essere una pratica, sia un'abilità tanto diffusa. Io non ne sono capace manco a parole. So a malapena cosa vuol dire "compilare" (no, non l'ho cercato su wikipedia ).

[aleritty]

Originariamente inviato da nelly369
@aleritty: non avevo visto la tua risposta.
D'accordo se uno è in grado di compilare i programmi, può ottimizzarli, ma non credo che, ancor prima di essere una pratica, sia un'abilità tanto diffusa. Io non ne sono capace manco a parole. So a malapena cosa vuol dire "compilare" (no, non l'ho cercato su wikipedia ).

Non è niente di così assurdo eh... si parte di base con il semplice comando "make" fino ad arrivare a specificare tutti i vari parametri! A seconda di Comunque ad esempio su gentoo (un "tipo" di GNU/Linux) specifichi una volta i parametri della tua macchina e lui fa tutto da solo e ti trovi un sistema operativo interamente compilato ed ottimizzato per la tua macchina! Praticamente la differenza tra un vestito su misura di sartoria ed uno comprato sul mercato...

Ovviamente però il programma deve essere progettato bene perchè altrimenti viene comunque utilizzato un solo processore...
Il vantaggio però è che in questo caso se il sistema operativo è compilato "multi-core" avrai comunque più velocità perchè viene dedicato un processore praticamente intero al programma e l'OS e gli altri programmi usano gli altri.
Quindi anche se aumentano i core noi nel mondo linux scrolliamo le spalle e ci prendiamo i vantaggi... Inoltre se il processore fosse per utilizzi server allora il numero di core è importantissimo!

[MItaly]

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.

[MItaly]

Dimenticavo un pezzo...

Originariamente inviato da nelly369
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?

Tendenzialmente è la disponibilità di hardware a fare sì che il software si adegui, non il contrario: se Intel avesse detto "iniziate a rendere le vostre applicazioni multithreaded che tra un po' facciamo dei processori multicore per ambito consumer" nessuno avrebbe fatto niente dando la priorità ad altro, salvo forse chi aveva dei progetti che ne potevano davvero beneficiare (ma che probabilmente saranno già stati ottimizzati in quella maniera per l'esecuzione su macchine multiprocessore).
Ora che le CPU multicore sono le più diffuse sui sistemi desktop e laptop i produttori di software si trovano di fronte ad un fatto compiuto: per sfruttarle al massimo devono scrivere software multithreaded. Avendo poi a disposizione hardware reale, possono misurare i miglioramenti di prestazioni "sul campo" invece che sulla teoria, cosa fondamentale, dato che andando solo di teoria nelle ottimizzazioni si rischia spesso di fare più danni che altro.

Per finire, ti segnalo un articolo (rivolto in realtà ad un pubblico di sviluppatori) di qualche anno fa, ma che a mio avviso spiega piuttosto bene la questione.

[nelly369]

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.

Azz... beccato. La tua logica non fa una piega ed anche il discorso che l'hardware spinge il software ad adeguarsi è corretto. Inoltre, sì, è vero la maggior parte delle persone usa il computer per navigare, sentire musica, scrivere, cose che un netbook a 300 euro basta e avanza, ed è così che si spiega il successo di questi "piccoletti" (anche se per giocare questi cosi fanno letteralmente schifo, eccezion fatta del caso in cui si giochi a roba precedente al 1998 ).

Vabbè visto che qui non me ne passate una , allora secondo voi quale sarà il limite fisico di core che si riuscirà a superare?
E' un pronostico, non una scienza esatta, è come chi diceva che sopra i 4Ghz le frequenze non sarebbero andate e ci ha preso, quindi esprimetevi liberamente.
Per me più di dieci non ci saranno (e siamo già a sei), perchè diventerebbero troppi da gestire. Per voi?

@MItaly: grazie degli articoli che hai postato, sono stati molto interessanti, specialmente quello sugli "scapocciamenti" della cpu in overclock. Non lo sapevo che esistessero, pensavo che l'unico problema con l'overclock fosse il maggior calore sprigionato. Se ci pensi, tale accadimento rende il tutto più umano, è come se il computer sotto una pressione duratura nel tempo ed eccezionalmente alta desse i numeri, ancor prima di fondere.

[MItaly]

Originariamente inviato da nelly369
Vabbè visto che qui non me ne passate una , allora secondo voi quale sarà il limite fisico di core che si riuscirà a superare?
E' un pronostico, non una scienza esatta, è come chi diceva che sopra i 4Ghz le frequenze non sarebbero andate e ci ha preso, quindi esprimetevi liberamente.
Per me più di dieci non ci saranno (e siamo già a sei), perchè diventerebbero troppi da gestire. Per voi?

Credo anch'io che non supereranno (almeno nei prossimi 10 anni) l'ordine di grandezza di 10 (quindi diciamo 6-60): per quanto la gestione da parte del sistema operativo non dovrebbe dare problemi (Linux è stato patchato da qualche mese per poter gestire 1024 CPU ), credo che sia difficile scrivere del software per PC desktop che faccia un uso così marcato della concorrenza.
Sono dell'idea che invece che sulla potenza pura i produttori punteranno sul rendere più "furbi" i processori (migliore branch prediction, microcode più efficiente, probabilmente nuove architetture sottostanti alla "facciata" x86) e più parchi in termini di assorbimento di corrente e di calore dissipato.
Mi interesserebbe poi sapere come si assesteranno le CPU ARM nei prossimi 10-20 anni: attualmente sui dispositivi embedded e handheld predominano, sarebbe interessante sapere se ci sarà effettivamente la migrazione di molti netbook a piattaforma ARM, e se magari la ARM, una volta conquistato (almeno in parte) il mercato netbook, forte dell'esistenza di sistemi operativi ben collaudati per la sua piattaforma cercherà di sfornare qualcosa di interessante anche per l'ambito desktop. Ciò sarebbe particolarmente interessante poiché gli ARM non dovrebbero portarsi dietro nessun problema di compatibilità con il vecchio codice, per cui potrebbero uscirsene con un design nuovo e pulito.

@MItaly: grazie degli articoli che hai postato, sono stati molto interessanti, specialmente quello sugli "scapocciamenti" della cpu in overclock. Non lo sapevo che esistessero, pensavo che l'unico problema con l'overclock fosse il maggior calore sprigionato. Se ci pensi, tale accadimento rende il tutto più umano, è come se il computer sotto una pressione duratura nel tempo ed eccezionalmente alta desse i numeri, ancor prima di fondere.

Mi aveva lasciato un po' così anche a me, come programmatore l'idea che anche un banalissimo xor eax, eax possa fallire mi rende inquieto.