di  -  mercoledì 4 gennaio 2012

Il precedente articolo sul MAME ha scatenato un po’ di polemiche che francamente non mi sarei aspettato, per cui ho deciso di affrontare alcuni argomenti che sono venuti fuori, in particolare quello prettamente tecnico che riguarda il cieco affidarsi all’evoluzione della tecnologia per giustificare il ricorso a codice sempre meno ottimizzato e/o esageratamente spostato verso la più onerosa simulazione piuttosto che alla più leggera emulazione.

Premetto intanto che l’emulazione era pre-esistente al MAME, da un bel pezzo. La prima volta che ne ho sentito parlare era ai tempi dell’Amiga, col suo emulatore Commodore 64 (per chi se lo ricorda). MAME dalla sua ha avuto il vantaggio non indifferente di aver messo assieme diversi sistemi arcade (anche da emulatori già esistenti), che all’epoca avevano ancora un enorme successo, divenendo il punto di riferimento nel panorama dell’emulazione.

E’ stato detto che l’obiettivo del team, dichiarato dallo stesso autore, è di perseguire la “preservazione” dei videogiochi originali, privilegiando l’accuratezza alla velocità di esecuzione. Una tendenza alla perfezione, quindi, senza compromessi. Ma, come già anticipato, l’emulazione perfetta, in cui il funzionamento interno del sistema viene riprodotto fedelmente, si chiama in realtà simulazione, ed è un’altra cosa.

In ogni caso gli sviluppatori hanno fatto ampio uso di High Level Emulation (HLE), e in alcuni casi proprio per questioni prestazionali (come vedremo dopo). D’altra parte l’approccio classico è quello di scrivere il prima possibile il driver per un sistema, per poi “raffinarlo” migliorando via via la qualità dell’emulazione.

Il problema del MAME è che si tratta di una progettazione a senso unico: gli “scarti” (codice HLE) vengono prima o poi abbandonati in favore dell’unica soluzione possibile per loro: quella finale, che risulta maniacalmente “aderente” all’originale.

Alcune tecniche HLE rimangono, però, in piedi proprio per garantire una buona velocità di esecuzione, perché la fedele riproduzione del funzionamento interno del sistema risulterebbe talmente avida di risorse da rendere l’emulazione (simulazione) praticamente inutilizzabile.

Un chiaro esempio lo si trova qui, dove spiega come viene implementata la gestione della TLB (Translation Lookaside Buffer), una veloce cache utilizzata dai processori originali per memorizzare gli (ultimi, generalmente) indirizzi virtuali già tradotti. In particolare:

Unfortunately, the details of TLB operation are often not fully disclosed, and even if they are, they are not quite as efficient to emulate in software.

L’ultima frase dovrebbe essere abbastanza eloquente, e giustifica l’approccio utilizzato dal MAME in questi casi, volto a privilegiare la velocità di esecuzione rispetto all’accuratezza dell’emulazione. Quindi preservazione sì, ma fino a un certo punto: la velocità d’esecuzione, checché se ne dica, rimane importante, se non si vuol vedere scorrere le immagini prodotte al ritmo di frame per minuto anziché per secondo…

Ci si potrebbe chiedere a questo punto perché non affidarsi ai progressi della tecnologia anche in questi casi. D’altra parte è il mantra che viene spesso ripetuto in queste circostanze, quando cioè si additano le nuove versioni del MAME come troppo lente per eseguire un gioco come Frogger (su un sistema che è però mille volte più “potente”).

Lo si è letto in diversi commenti, e lo stesso moderatore che ha chiuso il ticket oggetto del precedente articolo ha suggerito un aggiornamento per quello che considera un sistema troppo vecchio. Se lo dicono in tanti, anche persone che possono godere di una certezza autorevolezza, potrebbe anche essere vero, e la strada indicata quella giusta. E’ un approccio abbastanza comune, ma poco logico, che verte sulla fiducia più che su fatti concreti.

E’ vero che più passa il tempo e più potenza di calcolo abbiamo a disposizione, peraltro anche a costi ridotti, ma ciò non è sufficiente per cullarsene dimenticando come funziona un emulatore e quali esigenze deve risolvere. Questa mentalità è, anzi, particolarmente pericolosa, in quanto invoglia a prendere delle scelte sulle quali sarà poi difficile tornare indietro (se non a costi elevati).

Bisogna rendersi conto che la tecnologia ha subito un grosso stop in termini di frequenze raggiunte e di IPC: su entrambi i fronti si avanza ormai molto lentamente, e il motivo è riconducibile ai limiti intrinseci della tecnologia e della “computazione” rispettivamente.

La corsa ai Ghz, portata in pompa magna da Intel con l’arcinota famiglia dei Pentium 4, quale soluzione ai problemi prestazionali, ha condotto a un rovinoso baratro una roadmap che prevedeva già qualche anno addietro processori da ben 10Ghz. La continua riduzione della dimensione dei transistor ha, infatti, portato alla ribalta fenomeni fisici coi quali i produttori di chip hanno dovuto fare i conti, lasciando la frequenza ai piedi dei 4Ghz.

Si è preferito tornare a puntare sull’efficienza, al contrario dei P4 che non erano stati pensati allo scopo quanto per scalare in frequenza appunto. Efficienza che spesso si misura in IPC (Instructions Per Cycle), cioè mediamente quante istruzioni vengono eseguite dal microprocessore per ogni ciclo di clock.

Anche l’IPC ha dei limiti intrinseci strettamente legati alla computazione. Non è possibile, infatti, aumentare a dismisura questo valore, poiché il codice è soggetto a vincoli di dipendenza che, di fatto, renderebbe del tutto vana la possibilità di poter eseguire un numero elevato di istruzioni per ciclo di clock, a fronte di un’enorme complicazione a livello architetturale, che porterebbe comunque a frequenze meno elevate, consumi spropositati, e costi eccessivi.

Se soltanto negli ultimi anni abbiamo visto CPU (x86, in particolare) dotate di decoder in grado di decodificare fino a 4 istruzioni per ciclo di clock anziché 16 (tanto per sparare un numero a caso), è proprio perché decodificare tante istruzioni “subito”, che verranno poi eseguite chissà quando, non è una scelta molto intelligente, in quanto il decoder è uno dei componenti più costosi e critici (come abbiamo già discusso tempo fa proprio un queste pagine).

Con frequenze e IPC aventi una crescita limitata o sostanzialmente bloccata, i produttori di CPU hanno preferito puntare tutto sull’elaborazione parallela, prima con tecnologie come Hyperthreading (nate principalmente per sfruttare il più possibile le unità di calcolo che sono troppo spesso lasciate inoperative) e poi con core completi (che non condividono risorse con altre parti, se non per il bus e/o le cache L2/L3).

Un approccio, questo, che mal si sposa con l’emulazione, specialmente se dev’essere accurata, poiché si tratta di un processo strettamente sequenziale che sfrutta generalmente un solo core / processo / thread per l’emulazione della macchina vera e propria, facendo eventualmente uso di qualche altro thread per la sincronizzazione dell’I/O (grafica, audio, input) col sistema operativo (ma si tratta pur sempre di ben poca roba).

Lo possiamo leggere meglio nella pagina che è stata scritta per descrivere in che modo viene portata a compimento l’esecuzione in un sistema che deve emulare più CPU (o, in generale, dei “device“, come ad esempio dei coprocessori dedicati).

In soldoni, ciò significa che frequenza e IPC diventano i parametri fondamentali coi quali confrontarsi quando si parla di emulazione; parametri che sono purtroppo intrinsecamente limitati, e per i quali ormai i progressi della tecnologia non promettono più scalate all’inseguimento della famosa legge di Moore.

Si potrebbe pensare di sfruttare i numerosi core, in modo da assegnare a ciascuno di essi uno specifico processore da emulare. E’ un’idea che affiora in maniera piuttosto naturale, ma che non è applicabile concretamente. Bisogna considerare che già adesso prendere un algoritmo e “parallelizzarlo” presenta notevoli problematiche da risolvere. Intanto per la natura stesso del problema, che potrebbe non essere “parallelizzabile”. E poi per la sincronizzazione dei vari core che bisogna coordinare al fine di ottenere il risultato desiderato, cosa tutt’altro che semplice e scontata.

Scendendo nello specifico, l’emulazione di più core deve prevedere già di per sé la sincronizzazione dei vari componenti (in base alla particolare architettura del sistema) che non è cosa semplice (e, soprattutto, performante) da realizzare con un solo core/processo, e a cui si aggiungerebbero i problemi di sincronizzazione dei core fisici che se ne dovrebbero occupare. Ecco spiegato il motivo per cui il MAME emula un dispositivo alla volta, cedendo la CPU per un tot di tempo a ognuno di essi.

A conti fatti avere un PC con tanti core non serve praticamente a nulla, e poiché la direzione della tecnologia è quella di avere CPU sempre più potenti, ma perché dotate di molti core, si capisce bene che aggrapparsi all’avanzamento tecnologico per soddisfare i requisiti prestazionali sempre più elevati di progetti come il MAME, diventa sempre più un vicolo cieco in cui ci si infila senza, però, poterne più uscire.

Perché nel momento in cui alzi l’asticella e si pretendono sistemi più avanzati per avere un’emulazione (o simulazione), di fatto ci si è gettati la zappa sui piedi. Con buona pace delle “buone” intenzioni con cui vengono elargiti, spesso in buona fede, questi “consigli”.

32 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Uebmaestro
     scrive: 

    Cesare, ancora una volta i miei complimenti per un approfondimento davvero interessante. Alcuni dei punti ch esponi li avevo letti nel blog del PSCX2 (guarda caso), l’emulatore PS2 per PC:
    http://pcsx2.net/blog.php

    Nel post “Threading VU1″ anche loro descrivono le problematiche che stanno affrontando nel cercare di parallelizzare i thread; un’ulteriore lettura che consiglio a tutti gli interessati all’argomento.

  • # 2
    jpage89
     scrive: 

    Ottimo articolo.
    Personalmente penso che una buona revisione del codice, con modifiche al sottosistema, per usare al meglio le nuove capacità dei processori odierni, possa solo portare cose buone.
    Il progetto ormai ha raggiunto una mole tale da avere lo stesso problema del kernel linux: tocchi da una parte, si danneggia inspiegabilmente un’altra.
    Quindi sarei propenso ad un periodo di “stop”: non credo ci siano così “millanta” macchine ancora da aggiungere (non è mica il MESS…)
    Senza contare che dovrebbero davvero aprirsi a rivedere l’architettura: non ho la più pallida idea di come si programmi così a basso livello, ma che non ci possa far nulla ne dubito fortemente.

    PS: su emulazione/simulazione prendete tutti una cantonata, almeno stando a wikipedia:
    http://it.wikipedia.org/wiki/Emulatore#.22Emulatori.22.2C_.22Simulatori.22_e_.22Virtual_Machine.22

    Non mi pare che i ragazzi di MAME abbiano reimplementato pac-man, ma solo la macchina su cui gira..

  • # 3
    Yakkuz
     scrive: 

    Okey. Ho aspettato il pezzo. Il dubbio resta.

    Capisco perfettamente il punto (e lo avevo ben chiaro prima).

    Ma resta il fatto che l’ultima versione del Mame è un applicativo del 2011 , un Tbird è un architettura vetusta di quasi 10 anni fa.

    Capisco “in prospettiva” a cosa può portare “alzare l’asticella” , però c’è ancora un margine tremendamente elevato.

    Sarei curioso di sapere se su un core palomino 1500+ Frogger da lo stesso problema.

    Insomma probabilmente hanno valutato che l’utenza che vorrebbe far girare il MAME su tali CPU sia abbastanza ristretta, vista la facilità e il costo irrisorio con cui si trovano CPU VECCHIE ma ben più potenti.

    Ho come l’impressione che la persona che ha aperto il ticket sia solo amareggiata dal fatto che nel cabinato che s’è costruito ora, per usare l’ultima versione, deve cambiare CPU.

  • # 4
    Antonio Barba
     scrive: 

    @jpage89: quella pagina di Wikipedia contiene una quantità disarmante di inesattezze ed errori :D
    Fidati della definizione data da Cesare, che è quella corretta :-)

    Un simulatore reimplementa i componenti di un sistema, a livello elettronico, ed il sistema completo funzionerà come “effetto collaterale” della simulazione. Un simulatore perfetto è quello che simula il circuito elettronico originale. Esistono molti simulatori ma servono per studiare il sistema nella scala dei microsecondi, non per eseguire codice in realtime. Vengono usati infatti dagli ingegneri per verificare la correttezza di qualcosa che non hanno ancora costruito.

    Un emulatore, invece, si cura solo di replicare il funzionamento di alto livello, tralasciando l’implementazione. Un emulatore ha come unico fine l’esecuzione corretta del software, e si pone come obiettivo la compatibilità “ad occhio” e le performances, piuttosto che l’accuratezza.

  • # 5
    jpage89
     scrive: 

    @Antonio grazie per la delucidazione ;)

  • # 6
    Antonio Barba
     scrive: 

    @jpage89: prego, figurati :-)
    Giusto per darti qualche spunto di approfondimento, questo programma http://www.cadence.com/products/orcad/pspice_simulation/pages/default.aspx viene usato in tutto il mondo per simulare sistemi complessi e sapere se funzioneranno prima ancora di costruirli. Se replichi il circuito di una console da gioco, usando questo software, potrai avere una simulazione perfetta della stessa. Però l’accuratezza è a livello elettronico (cioè simula ogni singolo transistor, condensatore, resistore, ecc…), quindi non è possibile simulare in real time, ma bisogna limitarsi a simulare pochi millisecondi, giusto per verificare che i segnali elettrici generati da vari punti del sistema siano corretti.
    Questo qui è un altro simulatore http://visual6502.org/JSSim/ che simula il 6502 (CPU del Vic-20, C64, Apple 1-2, Atari 2600, ecc…) a livello di transistor. Non è accurato come il PSpice, ma sufficiente per replicare il funzionamento della CPU. Inutile dire che è molto lento e che per simulare una singola istruzione impiega diversi secondi.
    Esiste anche una versione in C, che è 1000 volte più veloce, e riesce a simulare la CPU ad un decimo della velocità originale, usando un moderno computer di classe Intel Core 2. :-)
    Questi sono i veri simulatori!

  • # 7
    Giacomo
     scrive: 

    @ Antonio
    ma non sono proprio i simulatori che cercano di replicare “a occhio” il funzionamento di qualcosa?
    Esempio classico, vedo e rivedo il cabinato di Pacman in azione e cerco di ricreare il funzionamento esteriore di quanto ho visto, però se non sono mai arrivato al 255° livello sul cabinato non so che si verificherà il famoso bug che sul simulatore non si verificherà, sull’emulatore, se abbastanza accurato, sì.

  • # 8
    Cesare Di Mauro (Autore del post)
     scrive: 

    No, è l’emulazione che cerca di riprodurre il “look & feel” di un sistema, senza però ricorrere alla simulazione accurata di tutte le sue componenti. Anzi, a volte è possibile ricorrere a dei trucchetti sporchi. Ad esempio intercettando sezioni di codice “critiche”, e sostituendole pari pari con versioni “ad hoc”, che fanno sostanzialmente la stessa cosa, ma in maniera magari molto diversa quanto più veloce. ;)

    @Uebmaestro: molto interessante la lettura di quel post. Soprattutto perché non credevo che fosse possibile introdurre forme di parallelismo nell’emulazione della PS2, proprio per le problematiche di sincronizzazione che ho esposto anche in quest’articolo.

    C’è da dire che è fortunata anche la situazione dei giochi per PS2, che sulla carta potrebbero fare quello che vogliono con le varie componenti hardware di questa console, rendendo vana ogni forma di HLE che è stata messa in atto in quest’emulatore.

    A mio avviso per risolvere alcuni problemi in questi rari casi si potrebbe tenere traccia dei giochi (o loro porzioni) che creano problemi in modo da disabilitare alcune parti multi-threading, oppure, in alternativa, mettere a disposizione code-path specifici che eliminano alla radice il problema (producendo gli stessi risultati, ovviamente).

    Tanto l’obiettivo del PCSX2 è l’emulazione (puntando sulla velocità), non la simulazione. ;)

    @jpage89: purtroppo quella pagina sulla wikipedia italiano è a dir poco scandalosa. In questi casi fra un’informazione sbagliata e una assente, preferirei di gran lunga quest’ultima: almeno non si propagano errori, creando e/o alimentando le classiche leggende metropolitane.

    Per il resto se il MAME fosse dotato di una buona suite di unit-testing potrebbero anche riscriverlo da capo a piedi senza per questo rischiare che toccando una parte di codice non ne funzioni più un’altra. Più un progetto è grosso, e più lo unit-testing risulta fondamentale quale strumento di garanzia della qualità e manutenibilità del codice.

    @Yakkuz: non centra nulla il fatto che il Thunderbird sia un’architettura di 10 anni fa, mentre l’ultimo codice del MAME è di qualche giorno fa. Ciò che conta sono le risorse e le “potenze” in gioco.

    Fra il cabinato di Frogger e il PC col Thunderbind ci sono 3 ordine di grandezza di differenza a favore di quest’ultimo, a prescindere dal codice scritto affinché il secondo emuli il primo. Questo è un dato di fatto che rimarrà tale anche fra altri 10 anni.

    Riguardo al margine di cui parli, proprio per quanto scritto nell’articolo non ci sono più margini “tremendamente elevati”.

    Considerato che dal Thunderbird a oggi sono passati 10 anni, la tecnologia ha avuto un progresso enorme. Infatti l’Athlon Thunderbird è costituito da circa 37 milioni di transistor, mentre le CPU attuali sono arrivate a toccare i 2 miliardi. Si tratta di quasi 2 ordini di grandezza di differenza, ma non mi sembra che le prestazioni dei processori siano migliorate di 50 volte, soprattutto tenendo conto delle esigenze tipiche dell’emulazione.

    Giusto per essere chiari, non è che un gioco che 10 anni fa girasse a 1 fps, con la stessa versione del MAME fatta girare su una CPU moderna adesso giri a 50 fps. Tutto ciò proprio per quanto detto nell’articolo: non si è assistito a un comparabile miglioramento di frequenza e IPC che, per bene che vada, a naso saranno complessivamente migliorate di circa 5 volte.

    Concludendo, penso che chi ha aperto il ticket abbia decisamente ragione di lamentarsi della direzione intrapresa da questo progetto.

  • # 9
    Antonio Barba
     scrive: 

    @Giacomo: ho già dato la risposta (che era contenuta nell’articolo e poi ulteriormente ribadita nei commenti anche da Cesare), inutile ripetere le stesse cose all’infinito :D

    Anzi, se qualcuno volesse prendersi la briga di correggere quella pagina farebbe anche un favore a Wikipedia!

  • # 10
    makrov
     scrive: 

    continuo a considerare quello di frogger un “non problema” in quanto il MAME si prefigge di salvare questi software dall’obsolescenza dell’hardware (leggasi rottura dell’ultima piastra dell’ultimo cabinato di quel tipo prodotto) e ottimizzare quindi il mame per hardware che sarà ancora soggetto ad obsolescenza ha poco senso, gia adesso i sistemi thunderbird funzionanti in circolazione sono pochi, col tempo saranno sempre di meno fino a sparire per penuria di parti di ricambio, e tra altri 10 anni probabilmente il mame o il mess sarà costretto ad emulare (simulare) un sistema x86 16-32bit come il vecchio thunderbird in questione.
    io ricordo che qualche anno fa per far partire sul mame le rom del cps-3 capcom http://junkerhq.net/xrgb/index.php/CPS-3 bisognava scaricare delle grosse tabelle di decriptazione di svariati GB, necessità che è svanita con il crack del sistema di protezione del cps-3 e succesiva implementazione nel mame, infatti come detto nell’articolo il mame prima abbozza il driver per far partire una determinata rom, e poi lo raffina, in questo caso eliminando le necessarie tabelle per una maggior aderenza alla macchina originale, anche a discapito delle prestazioni.
    pretendere che frogger parta su un 486 o un thunderbird è abbastanza futile nel 2011 e sarà totalmente ridicolo tra 10 anni, soprattutto perchè l’aumento della capacità computazionale è si bloccata ma per specifici limiti delle architetture CISC e in particolare x86, tra 10 anni la maggior parte dei sistemi monterà processori RISC (in realtà il sorpasso è gia avvenuto se si pensa ai dispositivi mobile/console, anche se arm con le thumb non è considerabile come un RISC puro) che hanno IPC superiori e complessità/numero di transistor di molte volte inferiore
    il mame per sopravvivere come progetto (e di conseguenza far sopravvivere i sistemi che si prefigge di emulare/simulare) deve adattarsi alle nuove macchine e non puntare su un ottimizzazione maniacale (sarebbe tempo perso per un progetto che si prefigge di durare per decenni e decenni)
    probabilmente i processori del futuro saranno piu simili al Crusoe http://en.wikipedia.org/wiki/Transmeta in pratica dei RISC in grado di eseguire (potenzialmente) qualsiasi ISA caricando un diverso code-morphing software rendendo i porting tra architetture diverse un ricordo distante
    se poi lo scopo è convertire il proprio muletto a macchina da gioco e giocare con il mame niente da dire, ma è come tentare di far girare win8 beta su un thunderbird.

  • # 11
    zafferano
     scrive: 

    Scusatemi, ma vorrei dire la mia su simulazione ed emulazione.

    I concetti di simulazione ed emulazione, sono completamente differenti fra loro, ed inoltre sono generali, cioe’ non legati all’informatica.

    La simulazione e’ la ripetizione degli aspetti SENSORIALI prodotti da un dato sistema.

    L’emulazione e’ la ripetizione degli aspetti FUNZIONALI di un dato sistema.

    Facciamo alcuni esempi di simulazione ed emulazione.

    Supponiamo di essere dentro una scatola dove ci vengono proiettati: immagini, suoni, vibrazioni, come se fosse un treno; allora questa scatola SIMULA il treno, MA NON LO EMULA cioe’, noi non veniamo trasportati come con il treno.

    Ora pensiamo ad un distributore di lattine di aranciata. Questo puo’ essere pensato come EMULATORE di un barista (infatti compie la stessa funzione; fornisce bevande in cambio di danaro), MA NON LO SIMULA, cioe’ non ci appare come un barista vero.

    In altri casi abbiamo, sia gradi di simulazione, sia gradi di emulazione; ad esempio il robot.

  • # 12
    Cesare Di Mauro (Autore del post)
     scrive: 

    In informatica i due termini hanno assunto un significato diverso. Di seguito alcuni link che ne parlano:

    http://en.wikipedia.org/wiki/Emulator
    http://en.wikipedia.org/wiki/Computer_simulation
    http://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference
    http://mamedev.org/devwiki/index.php/FAQ:About#Is_MAME_a_simulator_or_an_emulator.3F

    Personalmente condivido l’opinione espressa su stack overflow, che spiega bene i termini della questione.

    Anche il link dello stesso sito del MAME lo trovo abbastanza corretto, anche se rinominerei quello che loro chiamano “Logical level” in Emulation level, e introdurrei uno “State level” subito dopo il “Signal level” per identificare la simulazione dello stato interno di un sistema (ad esempio il funzionamento della pipeline di un processore, della cache, del TLB, ecc.) che porta, quindi, a una simulazione molto più accurata rispetto a quella offerta del MAME.

    Spesso si chiama anche “cycle-exact”, per identificare una simulazione di ciò che avviene in un sistema ciclo di clock per ciclo di clock. In ambito industriale è molto diffusa perché consente di raccogliere anche statistiche di utilizzo delle varie componenti del sistema (ad esempio quanti cache miss ci sono stati, quante volte un branch è stato “preso” e quante volte no, ecc.).

    @makrov: Frogger, che rimane pur sempre un caso concreto, è stato citato quale esempio di una situazione in cui versa il MAME, dove un sistema di 10 anni fa non riesce a emulare a piena velocità uno di quasi 30 anni fa, con diversi ordini di grandezza che li separano a livello prestazionale. Tra l’altro MAME e MESS emulano già da un pezzo l’architettura x86 (anche a 32 bit).

    Sono assolutamente contrario alla tesi che i limiti architetturali sono dovuti al paradigma CISC e che, al contrario, quello RISC sarebbe non dico esente, ma messo meglio a livello prestazionale. La storia dimostra l’esatto contrario: i CISC sono stati dati per morti già negli anni ’80, e si prospettava un futuro basato sui “migliori” RISC.

    La realtà è che non soltanto i CISC non sono morti, ma hanno sostanzialmente seppellito i RISC, e questo non soltanto a causa del codice “legacy” x86 che circola, ma proprio in termini puramente prestazionali. Non è un caso che la TOP 500 dei supercomputer sia stata per tantissimo tempo terra felice ed esclusiva dei RISC, mentre nell’ultima decade la maggior parte dei sistemi è basata sulla “Cenerentola” architettura x86.

    Ma a parte questo, a livello di prestazioni sul singolo core/processo/thread gli x86 non hanno praticamente rivali (a costo di un maggior uso di transistor, senza dubbio, ma qui stiamo parlando soltanto di prestazioni e non del costo per arrivarci), e l’hanno dimostrato ampiamente.

    L’IPC, inoltre, non lo si può usare come metro di giudizio per architetture (ISA) completamente diverse. Quel che fa un’istruzione x86 in un solo ciclo di clock, ad altre architetture RISC richiede l’esecuzione di più istruzioni (tra l’altro dipendenti). I CISC sono da sempre stati più “efficienti” in termini di “lavoro” svolto.

    Ciò detto, i limiti intrinseci della tecnologia non lasciano scampo a nessuno: CISC e RISC, in misura più o meno simile, ne sono direttamente coinvolti. Ed è con questa realtà che il MAME deve fare i conti, come spiegato nell’articolo.

    Infine il futuro non è certo rappresentato da soluzioni quali Transmeta che, sebbene sulla carta presentassero vantaggi notevoli, nel mondo reale hanno dimostrato che il gioco non valeva la candela, e proprio a livello prestazionale (sui consumi si può anche discutere).

    Tant’è che il progetto è morto da un pezzo ormai, e non c’è nessun accenno di rinascita.

  • # 13
    Yakkuz
     scrive: 

    @ Cesare

    Ripeto, capisco pienamente la tua critica in prospettiva.

    Mi rendo conto anche del tuo discorso in generale, ovvero che un TB 1.2Ghz ha COMUNQUE uno sfacelo di bruta potenza calcolo paragonata all’architettura sulla quale dovrebbe girare frogger.

    Io faccio un discorso pratico.. Un TB 1.2 è, essendo preciso un processore su socket A del 2000, quindi poco meno di DODICI anni fa (a a memoria mi sembrava di meno), non solo è fuori produzione la CPU, ma pure, schede mamme, SDRAM e video AGP.. (erano pochissime le schede che supportavano DDR1, anche essa non semplice da trovare).
    In questo caso, se dal punto di vista prettamente teorico è inconcepibile che una macchina del genere non riesca a far girare degnamente frogger, dal punto di vista pratico-economico, non è un problema, anzi, probabilmente farsi o sostituire un componente di un muletto con quella CPU costa molto di più perchè se non è da considerarsi HW d’epoca, poco ci manca.

    Insomma, sarei stato pienamente d’accordo con te e mi sarei preoccupato se “l’asticella” fosse stata alzata a livello di una CPU, magari sempre socket A, quindi “stravecchia”, ma, chessò, sui 2Ghz, che resta comunque un single core “usabile” oggi e quindi che ha una certa diffusione.

    Resta la curiosità di sapere se su un atom o un’altra CPU da 1.2 ghz di concezione moderna, Frogger presenti lo stesso problema.

    OT: Proprio ieri sera a casa di un amico abbiamo cambiato la piastra di un cabinato, da Tb 800Mhz a Sempron 2600+ :)

  • # 14
    zafferano
     scrive: 

    “Cesare Di Mauro: In informatica i due termini hanno assunto un significato diverso. Di seguito alcuni link che ne parlano:

    http://en.wikipedia.org/wiki/Emulator
    http://en.wikipedia.org/wiki/Computer_simulation
    http://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference
    http://mamedev.org/devwiki/index.php/FAQ:About#Is_MAME_a_simulator_or_an_emulator.3F

    Personalmente condivido l’opinione espressa su stack overflow, che spiega bene i termini della questione…….”

    Strano. Io queste definizioni le ho incontrate, anni fa, proprio nel testo di informatica con cui preparavo l’esame.
    Evidentemente nel corso del tempo si sono eccessivamente “specializzate”, tanto che, ora, sembra esserci una grande confusione (anche da parte degli “esperti”).

    Comunque se facciamo mente locale abbiamo:
    emulatore MAME = software che riproduce le funzionalita’ degli hardwares dove giravano i vecchi videogiochi.

  • # 15
    Antonio Barba
     scrive: 

    @Yakkuz: Atom NON è una CPU di concezione moderna. Puoi considerarlo come un 486 straordinariamente overcloccato :-D
    Ok, ho esagerato un po’, ma la questione è che si tratta di una CPU con pipeline in-order molto molto semplice, più una unità FPU (questa sì moderna e prestante) che però non c’azzecca niente con gli algoritmi usati nell’emulazione.
    Un TB del 2000 è circa il doppio più veloce di un Atom del 2011 a parità di clock.

  • # 16
    makrov
     scrive: 

    che un TB sia il doppio piu veloce di un atom ci credo poco, anche perchè la cache l1 e l2 sono a favore dell’atom per non parlare del brandwitch del bus dati e delle istruzioni x86_64, inoltre la differenza tra in-order e out-of-order diventa molto meno marcata quando si hanno davanti pipeline molto corte e non credo proprio che un atom abbia una pipeline da 30 stadi come i prescott
    per il resto la battaglia cisc vs risc la vedo ancora aperta, infatti dai P4 willamette tutti gli x86 funzionano internamente su microcode dopo che il decoder ha scomposto e riordinato le istruzioni x86, qualsiasi processore moderno internamente è un risc, il prossimo salto prestazionale lo si avrà quando si abbandonerà un ISA vecchia e poco efficiente come x86 per qualcosa di nuovo senza dover abbandonare la retrocompatibilità
    cmq mi risulta che i supercomputer siano x86 solo per questioni economiche e di facilità di programmazione, ormai il grosso dei calcoli viene fatto in GPGPU mentre per x86 i compilatori sono ormai una garanzia di affidabilità, cosa che non si puo dire per una architettura creata ex novo

    infine è divertente vedere come il tormentone “ci gira Crysis?” sa diventato “ci gira Frogger?”

  • # 17
    Antonio Barba
     scrive: 

    @markov: ovviamente mi riferivo alle prestazioni “teoriche” del solo core. Le cache e la Ram ovviamente giocano un ruolo importantissimo nelle prestazioni reali.
    Comunque Atom ha una pipeline da 16 stadi se non erro, quindi abbastanza lunghetta.
    Stando ai fatti reali, le migliori prestazioni le hanno le CPU con ISA CISC ed implementazione RISC. Infatti questo porta entrambi i vantaggi delle due filosofie: potenza di calcolo del CISC + semplicità di implementazione del RISC. Un processore puramente RISC o puramente CISC si porta dietro vari problemi che sono molto ben documentati in letteratura, e anche qui su Appunti Digitali se n’è parlato parecchio.
    Per il discorso dei supercomputer, a dire il vero, gli x86 usati sono parecchio costosi (Xeon e Opteron) ma consentono di avere molti più MIPS per socket rispetto ad altri processori RISC usati nello stesso campo (tipicamente POWER6, UltraSPARC e MIPS). Nel mercato dei supercomputer, infatti, conta abbastanza poco il costo delle CPU, piuttosto conta il costo del sistema nella sua totalità (edificio, sorveglianza, impianto elettrico e di raffreddamento inclusi).

  • # 18
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Yakkuz: il nocciolo della questione non è il Thunderbird, ma il concetto di affidarsi alla tecnologia che è del tutto sbagliato. Perché Frogger avrebbe bisogno necessariamente di una CPU moderna per girare fluidamente? Lo stesso Atom che hai citato, come ha detto Antonio, viene fatto a pezzi da un Thunderbird: ti pare normale? Eppure è un processore moderno…

    Alzare l’asticella soltanto perché l’hardware (in teoria) ce lo permette o ce lo permetterà porta dritti alla fossa. Se con Frogger ci sono già questi problemi su un Thunderbird, immagina di applicare la stessa idea di “raffinatezza / precisione” con giochi/sistemi più complessi: è facile arrivare al punto che nemmeno un processore di futura generazione potrebbe riuscire a farli girare fluidamente, perché le risorse richieste sarebbero troppe.

    Il MAME che emula la PS2? Chissà quando (e SE) ci riuscirà… ;)

    @zafferano: non so cosa diceva quel testo. Posso dirti che quando stavo finendo la mia tesi di laurea, nel 2004, il mio responsabile provò il decoder JPEG 2000 sul simulatore dell’architettura che si usava all’epoca all’STMicroelectronics (l’LX), dal quale estrasse alcune informazioni sul carico di lavoro sulle singole unità del “processore”.

    Comunque se cerchi “processor simulator” troverai parecchio materiale. I simulatori sono strumenti consolidati nell’industry.

    @makrov: veramente la cache L1 è nettamente a favore del Thunderbird. La L2 meno, ma considera che AMD ne implementa una di tipo esclusivo (non è replicato ciò che si trova nella cache L1), quindi è come se fosse di 384KB.

    Senza dubbio la banda di memoria è inferiore (ma la latenza delle DDR è nettamente inferiore rispetto alle DDR2 e, peggio ancora, le DDR3 usate negli Atom), e manca l’ISA a 64 bit, ma bisogna vedere se e quanto incidono questi elementi.

    Di sicuro l’architettura aggressivamente out-of-order del Thunderbird surclassa quella in-order dell’Atom, e inoltre ha una pipeline più corta (quindi ancora meno soggetta a penalizzazioni a causa di branch misprediction, roba parecchio frequente nell’emulazione).

    Pertanto sono della stessa idea di Antonio: trovo possibile che il primo abbia prestazioni doppie rispetto al secondo, a parità di clock.

    Il fatto che gli x86 internamente abbiano dei RISC non implica che questo modello sia il migliore. Infatti ci sono processori RISC come i POWER (nonché i famosi G5 che dal POWER4 derivano) di IBM che… internamente utilizzano un RISC ancora più semplice per l’esecuzione vera e proprio.

    Questo vuol dire soltanto che in questo particolare ambito (l’esecuzione “finale” / “vera”) il modello RISC garantisce migliori risultati, a prescindere dalla macrofamiglia (CISC, RISC) dell’ISA originale.

    Inoltre se si tiene cara la retrocompatibilità, allora l’x86 come architettura non può essere abbandonata. Ciò non toglie che in futuro possa evolversi togliendo di mezzo alcuni problemi di decodifica delle istruzioni, similmente con l’arrivo di AMD64, che è sostanzialmente una nuova ISA (dove, però, sono state rimosse un po’ di istruzioni e parti legacy).

    Riguardo alla TOP500, è vero che i costi sono importanti, ma senza le prestazioni non si entrerebbe in questa classifica. Inoltre le soluzioni dotate di GPGPU sono arrivate soltanto negli ultimi tempi, quando nella TOP500 gli x86 già dominavano…

    Per quanto mi riguarda, il tormentone sarà: il MAME riuscirà a emulare la PS2 fluidamente prima o poi? 8-)

    @Antonio: concordo. ;)

  • # 19
    Yakkuz
     scrive: 

    Okey, se la questione è prettamente teorica e in prospettiva futura, posso trovarmi d’accordo che sarà una strada poco praticabile e poco proficua.

    Però bisognerà vedere, insomma, qui si parla di un driver per una piattaforma particolare che non è “ottimizzato” per far girare Frogger con una determinata fascia di CPU…

    Da qui a fare un processo alle intenzioni però ce ne passa. Insomma, vedremo. E’ chiaro che se utilizzeranno questo approccio a tolleranza zero, ci ritrovermo nella situazione in cui si necessiterà di una macchina di fascia alta per poter lanciare fluidamente i titoli, o peggio ancora ci si troverà nella situazione di “non avere” abbastanza potenza di calcolo.
    In questo caso si, potrebbe essere un suicidio.

    Il mio dubbio sull’atom (o su un altra CPU simile ma di generazione differente) è proprio per cercare di capire se è un problema prettamente di Frequenza ed IPC (ed in questo caso dovrebbe andare quasi peggio su atom di pari frequenza) oppure semplicemente hanno sfruttato istruzioni non presenti negli Atholn Tbird.

  • # 20
    makrov
     scrive: 

    ok vedendo qualche benchmark per comparare il thunderbird 1.2Ghz con un atom si puo dire che effettivamente il thunderbird va un 50% meglio in single thread http://www.complang.tuwien.ac.at/franz/latex-bench http://new.haveland.com/povbench/graph.php (non so quanto siano affidabili ma danno un idea)
    cmq frogger gracchia anche sulla wii (usando un porting di sdlmame nativo)
    morale della favola: il nuovo driver di frogger fa schifo e atom è meno potente di una cpu di 10-12 anni fa!

  • # 21
    max
     scrive: 

    Ottimo articolo e ancora migliore la discussione che si è venuta a creare ;) Per quanto riguarda i concetti di emulazione/simulazione direi che in questo caso è d’obbligo vedere cosa intendesse lo stesso creatore del mame, Nicola Salmoria, nella sua tesi sul mame
    http://web.archive.org/web/20030413045859/http://www.mame.net/tesi.pdf
    Come si può leggere il problema deriva da come interpreti la parola simulazione:
    2 (estens.) imitare: simulare il canto degli uccelli
    3 (scient.) riprodurre artificialmente le condizioni in cui si svolge un
    processo o un fenomeno, per studiarne e verificarne gli effetti

    Quindi direi che alla fine tutti hanno ragione, per quanto riguarda il concetto di simulazione, se invece si considera il campo informatico le cose cambiano un po’. Io sono d’accordo con la definizione di Nicola, anche per gli studi che ho fatto a riguardo. In ogni caso secondo me il mame resta un emulatore vero e proprio, perchè se arrivi al 255 livello in pacman, crasha esattamente come l’originale. Questo perchè il mame non SIMULA il comportamento di pacman(non pretende di essere come lui), ma lo EMULA(è esattamente come lui)…

  • # 22
    Jojo
     scrive: 

    Game & Watch : mi sembra un caso pertinente, anche se non è M.A.M.E.

    http://www.madrigaldesign.it/sim_it/intro.php

    Che ne pensate delle definizioni date dall’ autore ? Grazie e scusate per l’intrusione “on the fly” …

    p.s.: grazie agli Autori per gli ottimi articoli ,e ,successivi ” pruriti cerebrali ” che ingenerano ;)

  • # 23
    max
     scrive: 

    Grazie del link e sono assolutamente d’accordo anche con questo

    – Un emulatore riproduce l’HARDWARE di un sistema;
    – un simulatore tenta di riprodurre il SOFTWARE o il comportamento di quel sistema.
    In realtà l’emulazione giunge ad un grado di accuratezza maggiore rispetto alla simulazione…
    …ma la simulazione è molto più divertente per i programmatori che la realizzano!

    I simulatori possono essere considerati una sorta di “cloni” dei sistemi originari: un programmatore studia un certo un software e poi cerca di rendere il suo simulatore il più possibile simile all’originale.

  • # 24
    Antonio Barba
     scrive: 

    @makrov: spulciando il link che hai postato, non mi pare che la differenza sia del 50%, ma di 80-85% abbondante, infatti leggo questo:

    – Athlon (Thunderbird) 800, Abit KT7, PC100-333, RedHat 5.1 2.49
    – Intel Atom N330, 1.6GHz, 512K L2 Zotac ION A, Knoppix 6.1 32bit 2.323

    Nonostante la SDRAM PC100, il TB a 800MHz va quasi uguale all’Atom 1.6GHz con DDR2. E’ evidente che la mia stima del “doppio” è più che confermata specie se prendiamo un TB con DDR1 :)

  • # 25
    makrov
     scrive: 

    gia, non pensavo che atom si comportarse così da cani rispetto a vecchie architetture con vecchi processi produttivi, va praticamente uguale alla vecchia netbrust del willamette a parità di clock

    cmq il thunderbird ad 1.2Ghz sta poco sotto
    – Athlon (Thunderbird) 1200, VIA KT133, PC100 SDRAM, RedHat 6.2 1.91
    – Celeron (Tualatin) 1200, VIA 694T, PC133 SDRAM, RedHat 7.1 1.79
    – Athlon (Thunderbird) 1200C, VIA KT133A, PC133 SDRAM, RedHat7.1 1.68
    dall’atom c’è uno scarto di 0.6 circa quindi ad occhio gli ho dato un 50% di prestazione in piu, tutto qui, con povray mi sembra xò che la differenza sia molto piu marcata
    ad occhio direi che quelli che doppiano le prestazioni degli atom sono
    – AMD Athlon XP2500+, 1830MHz, 512 KB L2, Knoppix 3.2, teTex2.0.2 1.13
    – Pentium M 1.5GHz (IBM R51), Debian 3.1 1.112
    cmq devo sempre provare frogger su un atom, se nn vedo non credo :P

  • # 26
    Cesare Di Mauro (Autore del post)
     scrive: 

    Se guardi i valori dei Thunderbird 1.2Ghz che hai riportato, noterai la notevole differenza che c’è già soltanto in termini di FSB & memoria (100/100 contro 133/133, con tutto il resto invariato).

    Come diceva Antonio, non usano nemmeno le DDR, ma le sole SDRAM (comunque servirebbe un FSB più elevato per supportarle).

    Atom è un’architettura che non è nata per competere sul piano prestazionale, al contrario di Thunderbird.

    @max: fino a quando Nicola parlava di simulatori citando SPICE e il suo funzionamento, mi trovavo perfettamente d’accordo, perché è esattamente quello che ho riportato finora.

    Anche prima, quando ha preso i termini dal vocabolario: emulare -> imitare, simulare -> riprodurre artificialmente.

    Dopo ha cominciato a disquisire sui termini arrivando sostanzialmente a ribaltare il significato dei due termini.

    Per cui rimango nella mia posizione.

    @Jojo. Idem come sopra. ;)

  • # 27
    homero
     scrive: 

    chi ha avuto la possibilità di lavorare con processori xilix ha potuto programmare hardware ad hoc per svolgere compiti precisi….oggi il general purporse invece che il limite della frequenza sono il freno tecnologico attuale….
    basta quardare un po’ fuori dal semito pre comprendere come andare avanti e che i mhz sono una piccola parte del problema…

  • # 28
    Cesare Di Mauro (Autore del post)
     scrive: 

    Infatti c’è anche l’IPC. :D

    Comunque, concretamente cosa proporresti per risolvere il problema dell’emulazione / simulazione? Non parlo di soluzioni dedicate come un FPGA o ASIC o roba simile, che sono troppo specifiche.

    MAME, UAE, ePSXe, Frodo, ecc., sono pensati per girare su diverse piattaforme (hardware + s.o.), senza ricorrere a roba simile.

  • # 29
    Antonio Barba (TheKaneB)
     scrive: 

    anch’io vedo nell’hardware specifico la soluzione ai problemi di prestazioni negli emulatori.

    Magari una qualche sorta di CPU dotata di istruzioni studiate appositamente per l’emulazione, ad esempio con la possibilità di caricare delle tabelle di opcode in una memoria iterna, eliminando quindi un bel pezzo del main loop dal software e facendo gestire molta più roba alla CPU.

    In questo modo si potrebbe, ad esempio, fare una cosa del genere per accelerare l’emulazione di una CPU a 8 bit:

    – preparo una tabella di opcode con 256 entries
    – ogni entry corrisponde ad un puntatore a funzione, oppure un codice di errore (per scatenare un fallback via software per gestire istruzioni speciali)
    – carico la tabella in una memoria interna della CPU, dedicata allo scopo
    – con una specifica istruzione, carico un “chunk” di codice (qualche KB) che viene così interpretato dalla CPU stessa (ogni istruzione di 1 byte indirizza un particolare entry della tabella, che esegue una call sull’indirizzo contenuto)
    – In caso di istruzioni multibyte, o roba complessa da gestire, prevedere un meccanismo di fallback, magari tramite una exception/software interrupt, che richiama il software di emulazione vero e proprio (analogamente a quanto avviene con certe FPU che non implementano tutte le funzioni, oppure quello che avviene nelle CPU ARM con gli opcode Java non implementati in Jazelle).

    Certo, studiare una sezione della CPU specifica per questa operazione di emulazione può sembrare inutile, ma probabilmente potrebbe essere usata anche da linguaggi di alto livello che compilano in bytecode (Java, Python, ecc…), quindi non sarebbe una funzione “inutile” in senso assoluto. Chiaramente un JIT compiler sarebbe la soluzione perfetta, ma richiede una complessità notevole lato software, mentre un’accelerazione lato CPU consentirebbe di programmare nuovi emulatori/interpreti in modo veramente veloce e prestante.

  • # 30
    Cesare Di Mauro (Autore del post)
     scrive: 

    E’ una cosa a cui penso da tempo, complice anche gli studi su Jazelle & Thumb-EE che ho pubblicato qualche tempo fa qui, ma allo stesso modo di queste tecnologie ciò richiederebbe codice specifico, e quindi una sostanziale riscrittura dell’emulatore che sia in grado si sfruttare queste particolari funzionalità (infatti Thumb-EE non viene sfruttato su Android proprio per questo motivo).

    Perché non esiste, e sarebbe mostruosamente difficile da concepire e realizzare, un compilatore che dalla sola analisi del sorgente sia in grado di accorgersi che quello è il main-loop di un emulatore/macchina virtuale (tanto sono la stessa cosa) e generare codice che sfrutti quelle estensioni della CPU.

    Come minimo servirebbe qualche #pragma sparsa nel codice cosicché sia il programmatore a indicare queste porzioni di codice e come sfruttarle.

    Il futuro, comunque, è rappresentato dai JIT. E’ tecnologia molto consolidata, e già disponibile. Anche il MAME, infatti, la usa (altrimenti i giochi basati su MIPS, ad esempio, girerebbero modello moviolone di Biscardi).

  • # 31
    Antonio Barba (TheKaneB)
     scrive: 

    beh se ci fossero tali istruzioni speciali, si potrebbe perdere un po’ di tempo a scrivere una libreria generica con parti in assembly e interfaccia pubblica in C, da utilizzare per sviluppare il main loop di una VM. Non sarebbe una cosa semplicissima, ma la parte difficile la programmi una volta sola e poi te la scordi.

    Fare un JIT impiega molto più tempo, però da prestazioni superiori se fatto bene. Insomma, ci sono pro e contro da valutare, ed inoltre il JIT possiamo usarlo oggi, mentre la mia proposta è solo teoria,

  • # 32
    Cesare Di Mauro (Autore del post)
     scrive: 

    A me piace di più un emulatore classico, per cui l’idea sicuramente mi attizza parecchio.

    C’è da dire che oggi sono diverse le soluzioni JIT già pronte, ma anche questi potrebbero essere a loro volta ottimizzati con istruzioni speciali per ottimizzarne l’esecuzione.

    Le idee non mancano sicuramente per sperimentare. Il tempo, purtroppo, è quello con cui bisogna fare i conti. -_-

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.