Newsgroup: it.comp.hardware.cpu
Titolo: Why Intel Sucks at PC Games?

http://www.extremetech.com/article2/0,1697,1895945,00.asp
-- 
Ciao mine
http://metropolis.blogs.com/
BMW 120d Attiva driver

> 
http://www.extremetech.com/article2/0,1697,1895945,00.asp
ciao, in pratica i programmatori del gioco non ne hanno
ottimizzato la compilazione: ma questo non va a loro
svantaggio comunque ?
ciao
luke

 
http://www.extremetech.com/article2/0,1697,1895945,00.asp
E' l'architettura P4 (pipeline da 31 stages) ad essere un disastro
nell'eseguire giochi. Dothan (Pentium M), con pipeline a 12 stages e cache
L2 da 2MB, per fare un esempio, è invece eccezionalmente efficiente,
rimanendo in casa Intel.


Se il gioco va gia sufficientemente veloce, dal loro punto
di vista e' *inutile* sprecare tempo e soldi extra
per incrementare ulteriormente le prestazioni.
In passato quando tutto dipendeva dalla potenza della cpu
e questa non era tanto potente (rispetto agli standard attuali)
si ottimizzava a manetta, ma ora non piu.
Nei giochi attuali conta molto la scheda video che si usa
perche si prende in carico parecchie delle operazioni
che in passato toccavano alla cpu, inoltre la complessita'
dei giochi commerciali e' aumentata, per questo molti usano
game engine invece di scrivere/riscrivere tutto da zero.
Oltre a questo molti dei giochi attuali vengono sviluppati
con scadenze abbastanza rigorose (es: i giochi associati ai film
e le classiche "uscite prefestive"), con budget belli grossi
in cui ad avere l'ultima parola non e' piu chi sviluppa
solo il codice.
Questo succedeva anche in passato, ma era limitato ai
giochi tipo platform oppure shoot 'em up associati ai film
(anche li, per quel tipo di giochi la potenza di calcolo
  era piu che sufficiente in relazione all'hardware disponibile
  e quindi non li si ottimizzava piu di tanto), ora questo
trend si e' propagato anche ai giochi 3D ed RTS che *in passato*
si mangiavano vive le cpu.
L. Micheletto

 si mangiavano vive le cpu.
Negli RTS è sempre contata molto anche la quantità di ram.  
Comunque anche nei nuovi (aoe3) la cpu è spremuta per bene.
Un amico con 3,2NW e 6800Ultra mi dice che aoe3 gli fa salire la T cpu
piu di un call of duty o un quke4...

 per incrementare ulteriormente le prestazioni.
Si però, correggimi se sbaglio, dall'articolo sembrerebbe che non vengano 
nemmeno usati i classici flag di ottimizzazione tipo /O2 e simili....


 simili....
Nell'articolo parlano delle ottimizzazioni per SSE ed SSE2, di quelle
per le CMOV e quelle di scheduling ottimizzato per le pipeline
dei P4.
Comunque non e' infrequente che se le prestazioni sono gia
ritenute sufficientemente elevate e le scadenze di consegna siano
pericolosamente vicine, ci si limiti a disattivare la generazione
delle informazioni di debug lasciando tutto il resto tale e quale
(per evitare che attivando qualche ottimizzazioni
  non si scateni qualche bug latente).
L. Micheletto

 L. Micheletto


Gianluca Andrini ha scritto:

come gia scritto nell'articolo originale, magari sarebbe ininfluente 
visto che molti giochi sono sviluppati partendo da motori di rendering e 
librerie varie già pronte e quindi ottimizzare solo il core sarebbe inutile

 ha scritto nel messaggio
news:dne6if$8eq$1...@domitilla.aioe.org...

Se il core è efficiente, ottimizzare più o meno per il core specifico cambia
poco. Il k8 è più veloce del P4 semplicemente perchè è migliore, non perchè
non si ottimizza il software per il P4. Certo, si può guadagnare magari un
5% effettivo di velocità, ma quando si dista oltre il 30% in certe
condizioni c'è poco da fare per colmare il gap.

 :
|| Se il gioco va gia sufficientemente veloce, dal loro punto
|| di vista e' *inutile* sprecare tempo e soldi extra
|| per incrementare ulteriormente le prestazioni.
hai ragione, non so di quanto possa influire quel
flag, però è così banale che anche per un 5%
io l'avrei preso in considerazione
grazie
luke

 :
|| Lorenzo Micheletto wrote:
||| Comunque non e' infrequente che se le prestazioni sono gia
||| ritenute sufficientemente elevate e le scadenze di consegna siano
||| pericolosamente vicine, ci si limiti a disattivare la generazione
||| delle informazioni di debug lasciando tutto il resto tale e quale
||| (per evitare che attivando qualche ottimizzazioni
|||  non si scateni qualche bug latente).
||
|| Hai ragione, a questo non avevo in effetti pensato :-)
beh, potevano abilitarli prima 'sti flag, no ;)
bye
luke


Il punto e' che se attivi "prima" quel flag ed "elimini"
uno 0.5% di potenziali acquirenti (perche a quel punto
la loro "vecchia" cpu non supporta le istruzioni utilizzate
oppure non e' piu sufficientemente performante)
e' una gran paccata di $$$.
Se invece lo attivi "poi" (dopo aver debuggato a fondo
una versione "per macchine vecchie") rischi che il riordino
del codice introduca qualche fastidioso bug di arrotondamento
e quindi dovresti fare un altro giro di test e debug
(altra paccata di soldi, la gente non lavora
  gratis ed i rivenditori aspettano).
Visto che a decidere in questioni di soldi non sono
i programmatori, a quel punto puoi immaginare che succede ...
Oltre a questo capita che per lo sviluppo di un gioco si
utilizzi un game engine o librerie sviluppate da altri
anche qualche annetto prima e visto che funzionano sufficientemente
bene non le si tocca assolutamente (tutto lavoro risparmiato).
L. Micheletto


Certe flag di ottimizzazione del codice rendono piu complicato
il debug, altre magari non sono manco supportate ad alto livello
dal debugger e ti tocca guardare il codice assembly senza
la comodita del corrispettivo sorgente C.
L. Micheletto

 :
|| Oltre a questo capita che per lo sviluppo di un gioco si
|| utilizzi un game engine o librerie sviluppate da altri
|| anche qualche annetto prima e visto che funzionano sufficientemente
|| bene non le si tocca assolutamente (tutto lavoro risparmiato).
||
|| L. Micheletto
chiaro come sempre
grazie
luke