Videogiochi: arriva la generazione multicore

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

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)

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!

Presto fatto:
[code]
#include <openmp.h>

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

return 0;
}
[/code]

Che bello, un pezzo di codice C/OpenMP che non fa nulla in un numero di thread equivalente al numero di core disponibili.
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

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 (?)

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.