Link alla notizia: http://www.hwupgrade.it/news/videogiochi/20784.html

Con l'avvento delle CPU multicore gli sviluppatori hanno dovuto rivedere seriamente i propri processi di sviluppo, ma adesso sembrano intravvedersi i risultati di questa transizione.

Click sul link per visualizzare la notizia.

be', era ora! è un peccato vedere giochi che impegnano al 50% i core :(

ok che oggi molto dipende dalla scheda video, ma ottimizzare i giochi (magari la fisica :D ) non sarebbe male! ;)

PS: c'è la patch per il multicore per Doom3!? io ho scaricato la 1.3, è quella?

finalmente qualcosa si muove :D

Black & White 2 già sfruttava gli eventuali 2 core

anche quake3 se e' per questo :P

esiste un elenco dei giochi ottimizzati per dualcore?

Liste di AMD e Intel? Interessante, non sapevo che esistessero.
Qualcuno mi mette il link che io non le trovo?

nemmeno io ho trovato questa lista... ho cercato con google inserendo parecchie keywords ma non si trova... :sperem:

Fate conto che Falcon 4 (1999) ai suoi tempi sfruttava i multiprocessori al 100%, con prestazioni aumentate di quasi il 50%! :eek:

Bei tempi, quando i programmatori ancora sapevano "osare" :rolleyes:

Il rischio di incompatibilità però secondo me è destinato a rimanere con buona parte dei titoli oggi disponibili: difficilmente le software house rilasceranno patch per tutti gli applicativi esistenti (sia che si tratti di giochi che di altra tipologia).

Secondo me è quanto mai esenziale la massima flessibilità possibile.
La soluzione vincente sarebbe un reverse hyperthreading, una implementazione in grado di fondere n cpu fisiche in 1 o più cpu logiche che sono la somma delle cpu fisiche.. il tutto secondo le necessità.

Per esempio: cpu con 4 core disponibili.
Ho un software, mettiamo un gioco, che richiede una grande capacità di calcolo per la fisica ma che non prevede montagne di calcoli in parallelo, e una buona capacità per l'intelligenza artificiale.
Le risorse si potrebbero assegnare così: 1 core per gestire sistema operativo e coordinazione di tutti gli aspetti che riguardano il gioco e l'interazione con le risorse del compurer. 1 core per la gestione dell'intelligenza artificiale, e 2 core uniti con il reverse HT per la gestione della fisica.

Oppure, sempre il solito gioco, ma con la fisica in cui si prevede un ampio uso del calcolo parallelo. I primi 2 core verrebbero gestiti in maniera identica a prima, mentre gli altri 2 invece di essere uniti, verrebbero sfruttati per il calcolo parallelo e quindi fatti lavorare indipendenti.

Fate conto che Falcon 4 (1999) ai suoi tempi sfruttava i multiprocessori al 100%, con prestazioni aumentate di quasi il 50%! :eek:

Bei tempi, quando i programmatori ancora sapevano "osare" :rolleyes:

Già... nonostante i primi multicore sono usciti nel 2005 ancora nel 2007 ne parliamo... :rolleyes:
Un pò lentucci direi!

Tutta fuffa...

Già... nonostante i primi multicore sono usciti nel 2005 ancora nel 2007 ne parliamo... :rolleyes:
Un pò lentucci direi!
Come al solito l'hardware anticipa di molto il software e alla fine ne esce sfruttato male e poco su Pc, con tra l'altro costi non popolari almeno nei primi mesi dall'uscita.
Io ho adottato il dual-core perchè ne beneficia il sistema e non certo per qualche sparuto esempio di gioco che se ne avvantaggia mediamente, almeno fino ad oggi.
Il futuro porterà ad avere giochi ottimizzati per il multicore in maniera seria e qualche esempio c'è già, ma prima di rendere necessario il passaggio in massa a più core sotto questo punto di vista ci vorrà ancora tempo.

è un passo dovuto quello della programmazione in multi dato che ormai i dual core (in minor numero anche quad core) sono montati su tutti i pc moderni e a prezzi molto accessibili a tutti. tuttavia credo che adesso dovrebbero smettere le software house di di pompare sempre + la grafica senza criterio dato che siamo già a livelli eccezionali (ad es oblivion) dovrebbero puntare molto sull'ottimizzazione e sullo sviluppo di aspetti che vengono sempre + lasciati in secondo piano come l' IA , lo sfruttamento del paesaggio e la TRAMA. Con le dx10 si potrebbero fare balzi in avanti stratosferici spero che nn pensino solo alla grafica ma ai giochi nel complesso

è un passo dovuto quello della programmazione in multi dato che ormai i dual core (in minor numero anche quad core) sono montati su tutti i pc moderni e a prezzi molto accessibili a tutti. tuttavia credo che adesso dovrebbero smettere le software house di di pompare sempre + la grafica senza criterio dato che siamo già a livelli eccezionali (ad es oblivion) dovrebbero puntare molto sull'ottimizzazione e sullo sviluppo di aspetti che vengono sempre + lasciati in secondo piano come l' IA , lo sfruttamento del paesaggio e la TRAMA. Con le dx10 si potrebbero fare balzi in avanti stratosferici spero che nn pensino solo alla grafica ma ai giochi nel complesso
Questo è ciò che mi auguro da tempo.
Come dici tu la grafica è sempre più pompata, e ciò non è male, anzi, ma se la paragoniamo all'ottimizzazione sempre più trascurata, ne esce fuori un quadro un pò deteriorato e approssimativo.
Stalker è un esempio lampante, un buon gioco con buona grafica ma scarsa ottimizzazione dopo un ritardo di anni dai tempi previsti, direi che non c'è da essere proprio ottimisti, bisogna essere più oculati in certe scelte e sui nostri pc l'hardware per quanto costoso sia, rischia di essere sempre più svalutato nel breve periodo a questo punto.

...tuttavia credo che adesso dovrebbero smettere le software house di di pompare sempre + la grafica senza criterio dato che siamo già a livelli eccezionali (ad es oblivion) dovrebbero puntare molto sull'ottimizzazione e sullo sviluppo di aspetti che vengono sempre + lasciati in secondo piano come l' IA , lo sfruttamento del paesaggio e la TRAMA...

Infatti non a caso ho citato Falcon 4: in quel caso i sistemi biporcessore brillavano nella gestione di una campagna dinamica senza rivali ancora oggi (esiste ancora un folto gruppo di appassionati che continua a sviluppare il codice originale).
Quando è stata l'ultima volta che avete visto un gioco per PC dotato di una campagna dinamica degna di tale nome?
Oggi un gioco di grido dura si e no una ventina di ore, e poi viene messo sullo scaffale per sopraggiunto torpore. :muro:

Con i giochi attuali anche i sistemi a processore singolo passano gran parte del a grattarsi perchè il lavoro da svolgere è solo grafico.
Questo perchè il 90% dei giochi nasce multipiattaforma e deve adattarsi anche ad un consolle.

be', era ora! è un peccato vedere giochi che impegnano al 50% i core :(

ok che oggi molto dipende dalla scheda video, ma ottimizzare i giochi (magari la fisica :D ) non sarebbe male! ;)

PS: c'è la patch per il multicore per Doom3!? io ho scaricato la 1.3, è quella?

il comando per abilitare il supporto multicore in doom 3 e quake 4 mi pare sia r_usesmp 1, ma almeno su q4 spesso causa crash vari del gioco...

anche quake3 se e' per questo :P
credo che ti stia sbagliando, q3 ha sempre supportato un unico core

Quake3 supportava il biprocessore (non multicore, cambia poco ma all'epoca c'era una certa penuria di multicore in ambito gamer :D )

Qualcuno sa se è uscita la patch per multicore per Super Mario Bros?
Ho provato a mettere 2 8800 in sli nel nes e ora viaggia davvero...

Già... nonostante i primi multicore sono usciti nel 2005 ancora nel 2007 ne parliamo... :rolleyes:
Un pò lentucci direi!

e nonostante Intel abbia introdotto l'Hyperthreading nell' ormai lontano 2002...certo, non erano dual core veri, ma le prestazioni aumentavano almeno di un 30% con applicazioni in grado di sfruttare l'HT: i P4 anche dopo l'uscita dei primi A64 (e praticamente fino all'uscita dei dual core) sono stati la CPU di riferimento con quelle applicazioni di encoding e rendering che si avvantaggiavano delle soluzioni multi-CPU...di tempo per adeguarsi i programmatori di VG ne hanno avuto anche troppo (e tra l'altro il ritardo è ancora più inspiegabile considerando che la base installata di CPU con HT già nel 2004 era praticamente sterminata: almeno 3 CPU su 4 vendute erano Intel P4 con HT)

E' ora che inizino a sfruttare i dualcore, ma soprattutto i giochi ancora in programmazione dovrebbero prevedere gia' i multicore ( 4-8 core )
Ho un X2 3800+ da quasi 1 anno e mezzo, sarebbe ora di sfruttarlo a dovere.... ( come gestione AI e fisica, visto che tanto la grafica viene fatta da VGA ben piu' potenti )

il comando per abilitare il supporto multicore in doom 3 e quake 4 mi pare sia r_usesmp 1, ma almeno su q4 spesso causa crash vari del gioco...
A me q4 col comando per il multicore vola, da 100fps son passato a 136, un bel 36% in più, considerando che è uno dei pochi titoli a supportarlo non è male (magari con una sv diversa dalla 6600gt non avrei colli di bottiglia :)
Al contrario cod2, altro gioco che tramite patch dovrebbe ottenere ottimizzazioni, gira meglio se la setto su off :asd:
credo che ti stia sbagliando, q3 ha sempre supportato un unico core
Io sapevo che sin dall'uscita sopportasse anche i sistemi multi cpu, ma non ho mai provato

forse il problema dell'ottimizzazione dual-multi core è un problema di compilatori-linguaggio da una parte e istruzioni dall'altra...

mi spiego... le i386 sono un genere di istruzione pensato per l'esecuzione in sequenza con l'ausilio eventuale di una FPU per i calcoli in virgola mobile... anche in anni e secoli di sviluppo informatico, il nostro codice si basa su quelle istruzioni. con le pipeline multiple, le istruzioni dedicate (sse, mmx e quant'altro) e con tecniche hardware come la previsione di salto o simili, i produttori di cpu han tentato di metterci una pezza ma gli attuali compilatori devon combattere proprio con questo tipo di problema, cioè una serie di istruzioni pensate per essere eseguite in sequenza.
il PPC e altri processori RISC come gli Alpha e altri ormai morti e sepolti partivano da un concetto diverso, le istruzioni erano più semplici e potevano esser eseguite anche in un "quasi" parallelismo ma ovviamente essendo soluzioni di nicchia non hanno avuto un seguito...
se pensate che una vecchia Silicon degli anni 90 in elaborazione video ancora adesso darebbe il fumo a una bella serie di processori moderni, potete avere un'idea di come l'hardware attuale potrebbe rendere se venisse cambiata mentalità...

ma il mondo è di microsoft e a microsoft non interessa riscrivere un compilatore e poi un nuovo sistema operativo... potrebbe succedere che qualcuno ci riesca meglio di loro e loro perdano il monopolio

per l'ottimizzazione dei giochi invece il discorso di programmazione è ancora diverso anche se legato:
il processore ha dei limiti, ma il vero anello mancante è una generazione di compilatori e un linguaggio di programmazione che possano rappresentare facilmente il multiprocessing... provate in C o in C++ o in C# a convincere la cpu a eseguire contemporaneamente 2 o + tread... in molti casi è quasi impossibile (dipende sopratutto dalle estensioni supportate dal compilatore e da come sono implementate)

ma è anche un fattore mentale dei programmatori... noi umani siamo portati a pensare sequenzialmente non in parallelo e quindi non riusciamo a "vedere" la strada multitread

per il resto quoto a pieno chi parla di giocabilità, AI, fisica ecc... a che serve una physis se ho un quadcore che lavora al 20-30% delle sue possibilità?

Scusa willy mi sembri molto preparato io sono un profano:

-Ma non si potrebbe davvero "unire" i vari core per farli lavorare come uno solo in sequenza inveece che in parallelo?

-Ma i PowerPC possono "spalmare" automaticamente sui vari core anche un calcolo derivato da C nato per essere in sequenza? (vedi kernel SMP di unix e linux)

-SE si, oltre ai vecchi MAC e alle PS3 con linux, un plebeo come me dove può trovare powerPC a buon prezzo?

Grazie mille!

Già... nonostante i primi multicore sono usciti nel 2005 ancora nel 2007 ne parliamo... :rolleyes:
Un pò lentucci direi!

Come possono essere lentucci se oggi come oggi sviluppare un titolo per PC ci vogliono mediamente 5 anni?

credo che ti stia sbagliando, q3 ha sempre supportato un unico core

Quake 3 invece ha sempre supportato l'SMP. E visto ciò, mi meraviglio di come oggi non abbiano fatto gli ultimi titoli "pronti" per i multicore.

forse il problema dell'ottimizzazione dual-multi core è un problema di compilatori-linguaggio da una parte e istruzioni dall'altra...

mi spiego... le i386 sono un genere di istruzione pensato per l'esecuzione in sequenza con l'ausilio eventuale di una FPU per i calcoli in virgola mobile... anche in anni e secoli di sviluppo informatico, il nostro codice si basa su quelle istruzioni. con le pipeline multiple, le istruzioni dedicate (sse, mmx e quant'altro) e con tecniche hardware come la previsione di salto o simili, i produttori di cpu han tentato di metterci una pezza ma gli attuali compilatori devon combattere proprio con questo tipo di problema, cioè una serie di istruzioni pensate per essere eseguite in sequenza.
il PPC e altri processori RISC come gli Alpha e altri ormai morti e sepolti partivano da un concetto diverso, le istruzioni erano più semplici e potevano esser eseguite anche in un "quasi" parallelismo ma ovviamente essendo soluzioni di nicchia non hanno avuto un seguito...
se pensate che una vecchia Silicon degli anni 90 in elaborazione video ancora adesso darebbe il fumo a una bella serie di processori moderni, potete avere un'idea di come l'hardware attuale potrebbe rendere se venisse cambiata mentalità...

ma il mondo è di microsoft e a microsoft non interessa riscrivere un compilatore e poi un nuovo sistema operativo... potrebbe succedere che qualcuno ci riesca meglio di loro e loro perdano il monopolio

Non si tratta di un problema di compilatori... il compilatore da solo non può capire se l'algoritmo si presta bene al multithreading e riscriverlo di conseguenza, è l'algoritmo stesso che deve essere scritto fin dall'inizio col multithreading in testa. Poi lasciamo stare la Microsoft, ci sono tonnellate di aziende che offrono compilatori, Intel inclusa.

il processore ha dei limiti, ma il vero anello mancante è una generazione di compilatori e un linguaggio di programmazione che possano rappresentare facilmente il multiprocessing... provate in C o in C++ o in C# a convincere la cpu a eseguire contemporaneamente 2 o + tread... in molti casi è quasi impossibile (dipende sopratutto dalle estensioni supportate dal compilatore e da come sono implementate)

Che sia difficile o impossibile esprimere certi problemi con una soluzione "parallela" è un conto (ed è verissimo), ma non diamo la colpa ai linguaggi di programmazione moderni (o ai compilatori) che offrono tutti gli strumenti necessari. Ovvio che per il programmatore è un lavoraccio ma non direi "quasi impossibile".

ma è anche un fattore mentale dei programmatori... noi umani siamo portati a pensare sequenzialmente non in parallelo e quindi non riusciamo a "vedere" la strada multitread

Questo sicuramente.

forse il problema dell'ottimizzazione dual-multi core è un problema di compilatori-linguaggio da una parte e istruzioni dall'altra...

mi spiego... le i386 sono un genere di istruzione pensato per l'esecuzione in sequenza con l'ausilio eventuale di una FPU per i calcoli in virgola mobile... anche in anni e secoli di sviluppo informatico, il nostro codice si basa su quelle istruzioni. con le pipeline multiple, le istruzioni dedicate (sse, mmx e quant'altro) e con tecniche hardware come la previsione di salto o simili, i produttori di cpu han tentato di metterci una pezza ma gli attuali compilatori devon combattere proprio con questo tipo di problema, cioè una serie di istruzioni pensate per essere eseguite in sequenza.
il PPC e altri processori RISC come gli Alpha e altri ormai morti e sepolti partivano da un concetto diverso, le istruzioni erano più semplici e potevano esser eseguite anche in un "quasi" parallelismo ma ovviamente essendo soluzioni di nicchia non hanno avuto un seguito...


Mi sembra sei rimasto parecchi anni indietro:
http://www.openmp.org
http://www-unix.mcs.anl.gov/mpi/


se pensate che una vecchia Silicon degli anni 90 in elaborazione video ancora adesso darebbe il fumo a una bella serie di processori moderni, potete avere un'idea di come l'hardware attuale potrebbe rendere se venisse cambiata mentalità...


E questo chi te l'ha detto? Negli anni 90 non ci stavano nemmeno i formati video che ci sono adesso. I super computer di allora oggi sono una frazione di potenza dei comuni PC da supermercato da 900€.


ma il mondo è di microsoft e a microsoft non interessa riscrivere un compilatore e poi un nuovo sistema operativo... potrebbe succedere che qualcuno ci riesca meglio di loro e loro perdano il monopolio


Magari fosse cosi semplice. Il monopolio mica ce l'hanno perchè hanno il miglior SO. Già da adesso.


per l'ottimizzazione dei giochi invece il discorso di programmazione è ancora diverso anche se legato:
il processore ha dei limiti, ma il vero anello mancante è una generazione di compilatori e un linguaggio di programmazione che possano rappresentare facilmente il multiprocessing...


OpenMP, MPI... Questi cosa sono?


provate in C o in C++ o in C# a convincere la cpu a eseguire contemporaneamente 2 o + tread... in molti casi è quasi impossibile (dipende sopratutto dalle estensioni supportate dal compilatore e da come sono implementate)


Presto fatto:

#include <openmp.h>

int main(int argc, char ** argv)
{
#pragma omp parallel for
for (;;) {}

return 0;
}


Che bello, un pezzo di codice C/OpenMP che non fa nulla in un numero di thread equivalente al numero di core disponibili. :asd:
E funziona sotto Windows / Linux alla stessa maniera, nativamente e con Microsoft C++ Compiler, Intel C++ Compiler e GCC 4.2
Pezzi di codice serilalizzato con banali direttive pragma. In C# è ancora piu' banale, visto che i thread fanno parte delle API standard del linguaggio e vengono gestiti per la maggior parte dal framework senza troppi complimenti.


per il resto quoto a pieno chi parla di giocabilità, AI, fisica ecc... a che serve una physis se ho un quadcore che lavora al 20-30% delle sue possibilità?

Ma chi ha mai detto che ste CPU servono per i giochi? :)
Questi discorsi sono banali. Io non ho mai visto nessuno comprare una Lamborghini Gallardo e lamentarsi di aver preso una macchina non adatta per fare gite in campagna.

Scusa willy mi sembri molto preparato io sono un profano:

-Ma non si potrebbe davvero "unire" i vari core per farli lavorare come uno solo in sequenza inveece che in parallelo?


E perchè mai dovremmo tornare al passato quando invece l'elaborazione parallela l'abbiamo sempre cercata di ottenere anche quando non avevamo l'hardware (thread, processi, preemption, hyper-threading, ecc. ecc.?


-Ma i PowerPC possono "spalmare" automaticamente sui vari core anche un calcolo derivato da C nato per essere in sequenza? (vedi kernel SMP di unix e linux)


Un kernel SMP non fa quello che dici, semplicemente è in grado di schedulare risorse su piu' CPU in caso di necessità. Questo non significa che codice non SMP si comporti come se lo fosse. Un kernel SMP su una macchina SMP in presenza di codice seriale, lo esegue comunque su una sola CPU. Inoltre i PowerPC non possono fare quello che dici, la sincronizzazione tra compiti paralleli dipende troppo dalla logica che si porta dietro e richiede programmazione manuale. Nulla che sia appannaggio di "semplici" CPU.


-SE si, oltre ai vecchi MAC e alle PS3 con linux, un plebeo come me dove può trovare powerPC a buon prezzo?


Su ebay, per esempio. Sono ferraglia come altri, nulla di trascendentale. Il buon prezzo è dato dal fatto che non sono altro che pezzi di rottami.

Fate conto che Falcon 4 (1999) ai suoi tempi sfruttava i multiprocessori al 100%, con prestazioni aumentate di quasi il 50%! :eek:

Bei tempi, quando i programmatori ancora sapevano "osare" :rolleyes:
I programmatori veri osano e sperimentano sempre.
Il problema sono le leggi di mercato che imbrigliano il loro spirito creativo limitandolo per fare profitto a qualunque costo.
E cmq programmare in multi-threading in maniera decente richiede imho un cambio di mentalità quasi pari al passaggio procedurale/OO.
Servono degli strumenti che aiutino i programmatori, ma soprattutto i programmatori devono iniziare a ragionare in un altro modo.
E non parliamo del debugging con gli strumenti oggi a disposizione per i programmi multi-threaded ke è meglio...vah :muro:

La soluzione vincente sarebbe un reverse hyperthreading, una implementazione in grado di fondere n cpu fisiche in 1 o più cpu logiche che sono la somma delle cpu fisiche.. il tutto secondo le necessità.

Per esempio: cpu con 4 core disponibili.
Ho un software, mettiamo un gioco, che richiede una grande capacità di calcolo per la fisica ma che non prevede montagne di calcoli in parallelo, e una buona capacità per l'intelligenza artificiale.
Le risorse si potrebbero assegnare così: 1 core per gestire sistema operativo e coordinazione di tutti gli aspetti che riguardano il gioco e l'interazione con le risorse del compurer. 1 core per la gestione dell'intelligenza artificiale, e 2 core uniti con il reverse HT per la gestione della fisica.

Oppure, sempre il solito gioco, ma con la fisica in cui si prevede un ampio uso del calcolo parallelo. I primi 2 core verrebbero gestiti in maniera identica a prima, mentre gli altri 2 invece di essere uniti, verrebbero sfruttati per il calcolo parallelo e quindi fatti lavorare indipendenti.
Assolutamente impossibile.
E cmq strumenti che automaticamente e totalmente sgravino i programmatori dai casini del multi-threadingnon esisteranno per un bel pezzo...
A meno che i famosi cervelli positronici di asimov prendano luce..
ma mi pare un eventualità...km dire... piuttosto remota :p
E questo per un semplicissimo, ma incredibilmente pericoloso concetto: le dipendenze :p

il comando per abilitare il supporto multicore in doom 3 e quake 4 mi pare sia r_usesmp 1, ma almeno su q4 spesso causa crash vari del gioco...


credo che ti stia sbagliando, q3 ha sempre supportato un unico core

No.
a quanto ne so esiste un'opzione che abilita il multi-threading nel motore di q3 arena.
Sempre se non ricordo male ovviamente... ma di solito è MOLTO difficile ke mi sbagli :p

e nonostante Intel abbia introdotto l'Hyperthreading nell' ormai lontano 2002...certo, non erano dual core veri, ma le prestazioni aumentavano almeno di un 30% con applicazioni in grado di sfruttare l'HT: i P4 anche dopo l'uscita dei primi A64 (e praticamente fino all'uscita dei dual core) sono stati la CPU di riferimento con quelle applicazioni di encoding e rendering che si avvantaggiavano delle soluzioni multi-CPU...di tempo per adeguarsi i programmatori di VG ne hanno avuto anche troppo (e tra l'altro il ritardo è ancora più inspiegabile considerando che la base installata di CPU con HT già nel 2004 era praticamente sterminata: almeno 3 CPU su 4 vendute erano Intel P4 con HT)
Ma anche no.
Vogliamo ricordare quanto tempo ci ha messo il mercato a passare dal codice procedurale al codice OO?
E, come ho già detto prima, fare debugging x i bug in multi-threading con gli strumenti attuali (o almeno con gli strumenti che conosco) è un vero e proprio bagno di sangue.
Dalla mia esperienza si parla di tempi dalle 3 alle 10 volte maggiori (quando il bug è particolarmente rognoso e subdolo).

forse il problema dell'ottimizzazione dual-multi core è un problema di compilatori-linguaggio da una parte e istruzioni dall'altra...

mi spiego... le i386 sono un genere di istruzione pensato per l'esecuzione in sequenza con l'ausilio eventuale di una FPU per i calcoli in virgola mobile... anche in anni e secoli di sviluppo informatico, il nostro codice si basa su quelle istruzioni. con le pipeline multiple, le istruzioni dedicate (sse, mmx e quant'altro) e con tecniche hardware come la previsione di salto o simili, i produttori di cpu han tentato di metterci una pezza ma gli attuali compilatori devon combattere proprio con questo tipo di problema, cioè una serie di istruzioni pensate per essere eseguite in sequenza.
il PPC e altri processori RISC come gli Alpha e altri ormai morti e sepolti partivano da un concetto diverso, le istruzioni erano più semplici e potevano esser eseguite anche in un "quasi" parallelismo ma ovviamente essendo soluzioni di nicchia non hanno avuto un seguito...
se pensate che una vecchia Silicon degli anni 90 in elaborazione video ancora adesso darebbe il fumo a una bella serie di processori moderni, potete avere un'idea di come l'hardware attuale potrebbe rendere se venisse cambiata mentalità...

ma il mondo è di microsoft e a microsoft non interessa riscrivere un compilatore e poi un nuovo sistema operativo... potrebbe succedere che qualcuno ci riesca meglio di loro e loro perdano il monopolio

per l'ottimizzazione dei giochi invece il discorso di programmazione è ancora diverso anche se legato:
il processore ha dei limiti, ma il vero anello mancante è una generazione di compilatori e un linguaggio di programmazione che possano rappresentare facilmente il multiprocessing... provate in C o in C++ o in C# a convincere la cpu a eseguire contemporaneamente 2 o + tread... in molti casi è quasi impossibile (dipende sopratutto dalle estensioni supportate dal compilatore e da come sono implementate)

ma è anche un fattore mentale dei programmatori... noi umani siamo portati a pensare sequenzialmente non in parallelo e quindi non riusciamo a "vedere" la strada multitread

per il resto quoto a pieno chi parla di giocabilità, AI, fisica ecc... a che serve una physis se ho un quadcore che lavora al 20-30% delle sue possibilità?
Ma anche no.
ripeto.
i compilatori e gli altri strumenti automatici potranno aiutare nel multi-threading quando avremo potenze computazionali quasi paragonabili a quelle di un cervello umano.
Fino ad allora toccherà al nostro cervello trovare ed effettuare le eventuali ottimizzazioni.
E vi assicuro che non è un compito x nulla banale.
Fattibile è fattibilissimo.... ma a fronte di un esborso di ore/uomo notevole.

Scusa willy mi sembri molto preparato io sono un profano:

-Ma non si potrebbe davvero "unire" i vari core per farli lavorare come uno solo in sequenza inveece che in parallelo?

Assolutamente no.
A meno ovviamente di non avere un algoritmo di predizione e gestione delle dipendenze che riesca a gestire il tutto usando meno risorse computazionali di quelle necessarie per eseguire il problema senza ottimizzazioni multi-threaded.
Ovvero all'atto pratico ad oggi è impossibile.
Un domani spero proprio ke si trovi una soluzione decente :p

-Ma i PowerPC possono "spalmare" automaticamente sui vari core anche un calcolo derivato da C nato per essere in sequenza? (vedi kernel SMP di unix e linux)

Nessun processore ad oggi esistente può farlo.
Può accadere che i processori di oggi facciano delle ottimizzazioni eseguendo dei calcoli fuori sequenza al posto di star fermi in attesa di caricamento di dati dalla memoria..
ma è BEN diverso rispetto all'ottimizzare un flusso di codice in algoritmi paralleli che devono girare in thread diversi con una ben precisa sincronizzazione :D

-SE si, oltre ai vecchi MAC e alle PS3 con linux, un plebeo come me dove può trovare powerPC a buon prezzo?

Grazie mille!
secondo te ci sarà qualche motivo se anche la apple ha abbandonato i G5 in favore dei processori intel.... o no? :p

Presto fatto:

#include <openmp.h>

int main(int argc, char ** argv)
{
#pragma omp parallel for
for (;;) {}

return 0;
}


Che bello, un pezzo di codice C/OpenMP che non fa nulla in un numero di thread equivalente al numero di core disponibili. :asd:
E funziona sotto Windows / Linux alla stessa maniera, nativamente e con Microsoft C++ Compiler, Intel C++ Compiler e GCC 4.2
Pezzi di codice serilalizzato con banali direttive pragma. In C# è ancora piu' banale, visto che i thread fanno parte delle API standard del linguaggio e vengono gestiti per la maggior parte dal framework senza troppi complimenti.

funzionare funziona..
vallo però a sincronizzare e soprattutto a debuggare...
fin quando ti limiti a 10 righe di codice è una cavolata..
ma quando si parla di progetti di centinaia di migliaia di righe di codice...
bhè... tanti auguri e figli maschi :D

beh...speriamo di riuscire ad avere giochi ke si adattino ai nuovi processori...e sfruttino a pieno la loro potenza di calcolo...x giochi sempre migliori...

funzionare funziona..
vallo però a sincronizzare e soprattutto a debuggare...
fin quando ti limiti a 10 righe di codice è una cavolata..
ma quando si parla di progetti di centinaia di migliaia di righe di codice...
bhè... tanti auguri e figli maschi :D

Ti pongo allora una domanda: le modalità di sincronizzazione sono direttamente proporzionali al numero di core disponibili o rimane sempre la stessa come nel caso di un programma multithread singolo core? ;)

Ti pongo allora una domanda: le modalità di sincronizzazione sono direttamente proporzionali al numero di core disponibili o rimane sempre la stessa come nel caso di un programma multithread singolo core? ;)

azzardo: la seconda che hai detto (?) :stordita:

Per altro, una domanda forse stupida:
Programmando in java il parallelismo è demandato alla programmazione o alla macchina virtuale?

azzardo: la seconda che hai detto (?) :stordita:

Per altro, una domanda forse stupida:
Programmando in java il parallelismo è demandato alla programmazione o alla macchina virtuale?

La difficoltà della sincronizzazione non dipendono dal numero di core ma dal numero di thread.
E soprattutto dipendono dal'architettura dell'applicazione, quindi non è possibile fare un discorso generale.
Ad esempio ci potrebbero essere dei programmi sccritti per girare con due soli thread con + problemi di dipendenze e di sincronizzazione di altri tipi di programmi scritti per essere sfruttati su N-thread.
Un esempio tipico sono i software di rendering 3d la cui struttura degli algoritmi si presta molto bene sia alla suddivisione per il multi-threading che addirittura per il grid computing.
Ma lo stesso certo non si può dire per tutti i software esistenti.

Alla domanda numero 2 la risposta è no.
Un programma per essere parallelizzato deve essere pensato in maniera da essere multi-threaded.
Da Java 5 in poi cmq sotto il package java.util.concurrent ci sono una marea di classi che aiutano molto il programmatore ad alto livello...molto ma MOLTO meglio rispetto ai costrutti a basso livello che era necessario utilizzare prima.
Ma lo stesso le fasi di gestione delle dipendenze, sincronizzazione, profiling, trasformazione delle parti critiche dell'algoritmo in multi-threading e soprattutto debugging, sono demandate al programmatore.

La difficoltà della sincronizzazione non dipendono dal numero di core ma dal numero di thread.
E soprattutto dipendono dal'architettura dell'applicazione, quindi non è possibile fare un discorso generale.
Ad esempio ci potrebbero essere dei programmi sccritti per girare con due soli thread con + problemi di dipendenze e di sincronizzazione di altri tipi di programmi scritti per essere sfruttati su N-thread.
Un esempio tipico sono i software di rendering 3d la cui struttura degli algoritmi si presta molto bene sia alla suddivisione per il multi-threading che addirittura per il grid computing.
Ma lo stesso certo non si può dire per tutti i software esistenti.

Alla domanda numero 2 la risposta è no.
Un programma per essere parallelizzato deve essere pensato in maniera da essere multi-threaded.
Da Java 5 in poi cmq sotto il package java.util.concurrent ci sono una marea di classi che aiutano molto il programmatore ad alto livello...molto ma MOLTO meglio rispetto ai costrutti a basso livello che era necessario utilizzare prima.
Ma lo stesso le fasi di gestione delle dipendenze, sincronizzazione, profiling, trasformazione delle parti critiche dell'algoritmo in multi-threading e soprattutto debugging, sono demandate al programmatore.

Ah, ecco
Pensavo di essere io a non aver trovato il tastone con scritto "Rendilo Parallelo" in eclipse ....
invece mi pare d'aver capito che in sostanza tocca continuare a spaccarsi la testa :cry: (oddio, io sono ancora ben lontano dall'aver bisogno di implementare un vero parallelismo, ma la cosa m'ingrifa)

Ah, ecco
Pensavo di essere io a non aver trovato il tastone con scritto "Rendilo Parallelo" in eclipse ....
invece mi pare d'aver capito che in sostanza tocca continuare a spaccarsi la testa :cry: (oddio, io sono ancora ben lontano dall'aver bisogno di implementare un vero parallelismo, ma la cosa m'ingrifa)

In Java sostanzialmente il multithreading è gestito da entrambi (programmazione e VM) rispetto a soluzioni molto a piu' basso livello come ad esempio i Posix Threads. La parola chiave synchronized, i blocchi , le operazioni atomiche piu' tutte le utility incluse nel package java.util.concurrent rendono la programmazione multi thread sostanzialmente piu' semplice che l'usare i thread nativi nudi e crudi. Per esempio, sempre in Java (visto che parliamo di Java) i sincronizzatori e gli esecutori sono supporti importantissimi che in altre realtà differenti da Java devono essere implementati "a mano". Senza parlare delle collection concorrenti... Comunque rimane sempre una parte gestita dalla programmazione. Gestito dalla VM perchè in fondo il modo di fare programmazione multithread in Java è comunque un'astrazione di piu' alto livello dei thread nativi della macchina su cui eseguiamo il programma. Infatti un programma Java multithread utilizza alla fine i Posix Threads nel caso di sistemi Unix e i Win32 Threads nel caso di Windows.

In Java sostanzialmente il multithreading è gestito da entrambi (programmazione e VM) rispetto a soluzioni molto a piu' basso livello come ad esempio i Posix Threads. La parola chiave synchronized, i blocchi , le operazioni atomiche piu' tutte le utility incluse nel package java.util.concurrent rendono la programmazione multi thread sostanzialmente piu' semplice che l'usare i thread nativi nudi e crudi. Per esempio, sempre in Java (visto che parliamo di Java) i sincronizzatori e gli esecutori sono supporti importantissimi che in altre realtà differenti da Java devono essere implementati "a mano". Senza parlare delle collection concorrenti... Comunque rimane sempre una parte gestita dalla programmazione. Gestito dalla VM perchè in fondo il modo di fare programmazione multithread in Java è comunque un'astrazione di piu' alto livello dei thread nativi della macchina su cui eseguiamo il programma. Infatti un programma Java multithread utilizza alla fine i Posix Threads nel caso di sistemi Unix e i Win32 Threads nel caso di Windows.
Si è ovvio che è gestito tutto a livello di vm.
Già a far partire un banalissimo "hello world" la VM instanzia 10 thread: uno per il programma e 9 di sistema (GC, dispatcher...ecc...).
Questi thread però comprendono anche l'agente necessario a monitorare la virtual machine e penso che 4 o 5 siano dedicati ad esso.
Cmq alla fine tocca al programmatore usare a fondo gli strumenti messi a disposizione per rendere il suo programma multi-threaded.
La VM aiuta solo in rare occasioni (ad esempio il thread del dispatcher dell'AWT è separato dal main thread) ma cmq occorre lanciare i componenti grafici che richiedono delle elaborazioni pesanti o sono I/O bounded in un thread diverso.
In Java 6 è stato anche introdotto un altro strumento per aiutare il programmatore nella gestione dei thread dedicati ad oggetti di GUI: SwingWorker.
Cmq ricordiamo che i giochi non sono certo fatti in java, e con i costrutti base del c++ gestire i thread è molto + incasinato senza alcuna libreria per la gestione dei thread :p