Un po' di numeri reali.

[riko]

Quando dicevo nella norma ricordavo di quando ero più piccolo e emulavo i giochi della play o altri giochi sul pc tramite emulatori. Era dichiarato per tutti un "rendimento" pari 0.5 o anche 0.7 per alcuni...se dici che si hanno solitamente rendimenti di 0.1 evidentemente stavo parlando di cose diverse. I link di quella roba non li metto perchè sinceramente non ho voglia di cercarli e in ogni caso ogni tanto ci si potrebbe anche fidare dato che non parliamo di soldi...se dichiaravano 0.5 dichiaravano 0.5 punto.

Attenzione perchè è abbastanza diverso. Emulatori di giochi ne ho visti anche io (e su un iMac a 233 avevo un emulatore di playstation --- solo che avevo solo un gioco, barattato con un paio di scarpe usate ).
Resta abbastanza diverso usare un emulatore per una macchina. Pensa a VPC o a qemu. Guarda quanto ci gira piano sopra windows.

Idem se fai girare MacOS X su PearPC. In pratica ci vuole un Athlon iper pompato solo per non farti scemare la voglia di provarlo causa rotazione continua della beachball (a parte che è illegale sta cosa).

Non sono un esperto di CPU (il mio campo di studio non riguarda CPU et similia). Non so dirti esattamente per quale ragione emulatori di console funzionino bene ed emulatori di PC no.

La cosa che mi viene in mente è che teoricamente un processore pensato per una console può avere requisiti e capacità diversi da uno generalista (per esempio capacità di multitasking avanzato non sono richieste, d'altra parte un'unità floating point o addirittura vettoriale molto avanzata è fondamentale).

...parlano molto bene dei turion

Lo ho sentito anche io, ma non di prima mano. Inoltre con tutti i PC portatili moderni ci sono enormi incognite. Ci sono modelli simili sulla carta che poi nei fatti hanno durata di batteria l'uno quasi il doppio dell'altro, o prestazioni sensibilmente più alte.

Boz.

In effetti se ci pensi la forza di Centrino è che è un'architettura completa, non un semplice processore. Questa è la ragione per cui funziona bene, ottimizzare solo il processore è stupido. BTW anche AMD può fare Centrino, mi pare ci abbia anche vinto una causa.

[Flipper]

Ma non mi sono offeso Ridere ...so come si cerca una news...non l'ho cercata perchè ricordavo perfettamente cosa aveva detto il tipo di intel Figo

.....e io mica volevo offenderti

Ciao.

[riko]

E su EFI....
http://nak.journalspace.com/?cmd=displa ... ntryid=407

http://www.reezle.com/imgs/reezle-100001-5306.jpg

Non so, continuo a pensare che con i MacIntel Apple abbia fatto passi da gigante. All'indietro.

[ikir]

Probabilmente perchè le console emulate sono macchine generalmente con carattaristiche molto inferiori... per esempio hanno poca ram, quella che serve, invece sul computer che usi per emulare ne hai di più e probabilmente viene sfruttata.... naturalmente è solo una ipotesi.

Per esempio durante i tempi d'oro dell'Amiga, questa aveva un hardware simile (stessa cpu) rispetto al Mac, ma molto più avanzata, addirittura se emulavi un Mac ottenevi una velocità fino al 30% più veloce... 1,30 dunque...

Dipende da tante cose, ma in genre 0,5 è tanto considerando che emula un PPC e non una vecchia cpu di qualche console della nostra infanzia.

[riko]

Ah, se proprio dovete prendervi un MacIntel, abbondate con la RAM:

http://hailstonesoftware.com/articles/2 ... y-overhead

[ikir]

Conclusions are wrong. The tests compare memory usage of various programs on Intel Macs, with or without Rosetta. They say nothing about RAM usage on current powerPC machines.

Chi avrà ragione? Comunque... alla faccia...

[riko]

Ne do un po' io di numeri...

TextMate prende 11 MB.

Gli altri sono test impossibili. Per esempio io su Mail ho un archivio gigantesco ovviamente occupa più RAM. Idem... safari dipende dai plugin, da quanto è stato attivo, Quicktime dai plugin... insomma.

Dopo di che è *ovvio* che Rosetta beva più RAM. Quando esegue un po' di codice (e lo traduce) per eseguirlo la seconda volta senza doverlo ritradurre, mette in memoria la traduzione per un accesso più veloce. Quindi la cosa non sorprende.

La mia non è polemica. Solo consiglio chi dovesse prendere un Mac Intel di abbondare con la RAM *se* ha bisogno di applicazioni rosetta. Cosa che io comunque mi sento di sconsigliare, se non come unica spiaggia. (intendo dire dovere usare sw rosettato).

[ikir]

Si si hai fatto benissimo a postarlo. Be quando e se prenderò un MacIntel..... 2GB eh eh eh

[AmigaCori]

RISC vs. CISC...negli annali dell'inforamtica era come una Romanisti vs. Laziali

Comunque a proposito di abbandonare l'instruction-set di 30 anni fa, ho letto piu' volte che il problema, come ha già detto qualcuno era piu' "ideologico" che pratico...cioè, il fatto di dover vendere macchine che potenzialmente non possano far girare word processor di 20 anni fa..intimoriva alcune grandi aziende che avrebbero poi dovuto comprare queste nuove CPU.

l'incompatibilità, è il mostro nero dell'informatica, per cui si sacrificano idee geniali e rivoluzioni...perchè chi ha investito fir di milioni didolaroni in hardware, poi non vuol spendere altri fiorn di milioni in nuovo software, aggiornamento del personale e tutt'altro che debba essere cambiato.

Meglio lento perchè poco effciente che veloce ma incompatibile.

Sempre riguardo a CISC e RISC, ho letto che nella storia c'è sempre stato un alternarsi tra i due sistemi, a seconda della tecnologia realizzativa delle memorie e processori, era piu' vantaggioso un tipo di instruction-set invece dell'altro...era tutto molto relativo.

Se non sbaglio, in generale memoria lenta e velocità del processore non critica, preferiva il CISC perchè si fanno meno accessi alla memoria....ora, con tutto veloce, si preferisce il RISC, o meglio il misto RISC-CISC, cioè dove si può volare si vò in RISC, per le cose piu' complesse si usa il RISC, diciamo che in CISC si eseguoino quelle istruzioini che capitano molto spesso...il tutto è visto come un processore nel processore dove le istruzioni CISC rappresentano il processore piu' interno.

Veh, l'ho messa molto sul semplificato, la cosa è molto complessa e scegliere tra le due è diventato ormai troppo complesso, anche perchè si hanno svantsggi e cantaggi in entrambi gli approcci alla programmazione.

In emebedded, si prefersice il CISC perchè molte istruizioni possono essere realizzate via hardware, per esempio la decodifica fi stream audio/video, si realizza in hardware, quindi con delle istruzioni CISC si possono gestire piu' facilmente e velocemente operazioni complesse.

Il paragone tra desktop ed emebbed, come anche le console, è imroponibile.

Si possono realizzare a livello hardware cose che con un pc + software richiedrebbero un immenso dispendio di risorse.

Per esempio ul lettore dvd da tsvoo, nella decodifica mpeg, ha un chip dedicato, lavora a pochi Mhz, un pc sotto il mezzo Ghz farebbe fatica a far andare bene un film in DVD, appunto perchè è pensto come general purpouse e quindi la decodifica la fa in software.

Comunque....viav il 68k!!!

[riko]

Se non sbaglio, in generale memoria lenta e velocità del processore non critica, preferiva il CISC perchè si fanno meno accessi alla memoria....ora, con tutto veloce, si preferisce il RISC, o meglio il misto RISC-CISC, cioè dove si può volare si vò in RISC, per le cose piu' complesse si usa il RISC, diciamo che in CISC si eseguoino quelle istruzioini che capitano molto spesso...il tutto è visto come un processore nel processore dove le istruzioni CISC rappresentano il processore piu' interno.

In primo luogo sei troppo schematico sul CISC/RISC. Sono modelli teorici, non sono modelli reali. Anche processori grosso modo RISC come i PPC hanno istruzioni "complesse" e non atomiche (che sarebbero per dire tipiche del modello RISC). RISC praticamente puro c'è solo ARM.

Dopo di che avviene esattamente il contrario di quello che hai scritto. I cuori di molti processori "CISC" sono RISC. D'altra parte se ci pensi la cosa è logica. Per scompattare hai tutta l'informazione, per compattare devi attendere, quindi si porrebbe un problema di tipo codici e teoria dell'informazione, le istruzioni dovrebbero essere compattate in modo da non dovere attendere troppo etc etc...

Veh, l'ho messa molto sul semplificato, la cosa è molto complessa e scegliere tra le due è diventato ormai troppo complesso, anche perchè si hanno svantsggi e cantaggi in entrambi gli approcci alla programmazione.

Tanto è vero che alla fine anche i produttori CISC si stanno muovendo verso RISC, o facendo lavorare internamente il processore come un RISC (in pratica spezzano le istruzioni complesse in istruzioni semplici, o se vuoi metterla in modo ancora più estremo creando un processore RISC che emula un CISC), oppure ottimizzano abbestia un set ridotto di istruzioni che in pratica sono usate più di frequente. Le altre "esistono", ma non sono convenienti.

In emebedded, si prefersice il CISC perchè molte istruizioni possono essere realizzate via hardware, per esempio la decodifica fi stream audio/video, si realizza in hardware, quindi con delle istruzioni CISC si possono gestire piu' facilmente e velocemente operazioni complesse.

ARM tiene circa il 75% del mercato embedded.

Per esempio ul lettore dvd da tsvoo, nella decodifica mpeg, ha un chip dedicato, lavora a pochi Mhz, un pc sotto il mezzo Ghz farebbe fatica a far andare bene un film in DVD, appunto perchè è pensto come general purpouse e quindi la decodifica la fa in software.

Non vedo perchè leghi avere chip dedicati con essere un processore CISC.

[AmigaCori]

Dopo di che avviene esattamente il contrario di quello che hai scritto. I cuori di molti processori "CISC" sono RISC. D'altra parte se ci pensi la cosa è logica. Per scompattare hai tutta l'informazione, per compattare devi attendere, quindi si porrebbe un problema di tipo codici e teoria dell'informazione, le istruzioni dovrebbero essere compattate in modo da non dovere attendere troppo etc etc...

Si, hai ragione, ho sbagliato io a scrivere, ovviamente le istruzioni complesse, le CISC, vengono frammentate in istruzioni piu' semplici, le RISC.

Non ho avuto la pazienza di rileggermi tutto il mio post, mi scuso per l'errore.

o se vuoi metterla in modo ancora più estremo creando un processore RISC che emula un CISC),

beh, si è quello che intendevo dire nel mio primo post quando consideravo il RISC il processore nel processore CISC (anche se ripeto, ho invertito nella prima parte del post la dicitura CISC con RISC.)

Non vedo perchè leghi avere chip dedicati con essere un processore CISC.

Ok, il legame nasce dal fatto che un processore embedded e' costruito in maniera ottimizzata per alcuni compiti ben precisi e particolari, mentre un processore da PC no.

Mettiamo che esista una singola istruzione CISC a livello software che permetta di speculare da destra a sinistra una immagine.

Questa istruzione ovviamente sarà molto complessa per un PC, cioè richiederà o lo spezzettamento in RISC oppure una lunga serie di operazioni per eseguire la singola istruzione CSIC.

Ci vorrà un hardware che sia all'altezza della situazione.

Mettiamo che io con dei circuiti hardware realizzi la stessa istruzione ma a alivello hard e non soft, cioè quando il programma chiama quell'operazione, si attiva un circuito dedicato del processore o del sistema emebedded che esegue l'operazione di speculazione dell'immagine.

Essendo il livello hardware piu' veloce di quello software (cioè un AND fatto con dei transistors è piu' veloce di uno fatto con un'istruzione) dovrò avere meno risorse di sistema: meno memoria, meno cicli di clock, meno raffreddamento, meno potenza, quindi il sistema costerà di meno e potrò realizzare un lettore dvd da tavolo con pochi sodi.

Perchè istruzioni CISC e non RISC?, perchè se devo fare un circuito hardware dedicato, lo faccio per cose critiche e complesse; visto che per definizioni le istruzioni CISC sono piu' complesse delle RISC, allora lego il sistema embedded al processore CISC.
Non volevo dire che un processore emebdded è CISC, ma che la suo interno avrà "cablate" delle istruzioni che, in un processore PC, sarebbero considerate molto complesse da eseguire, quindi CISC.

[guruman]

Sarà che inizio a pensare da ingegnere ma un rendimento pari a 0,5 (anzi anche meno visto che i mac intel sono più veloci) non mi pare assolutamente eccezionale ma solo nella norma.

Essere nella norma rispetto a cosa? Prima di rosetta, era considerato bene un emulatore che se la cavasse con un fattore *10* (ovvero un rendimento del 10%, per come la dicevi tu).

Di meglio non si sapeva fare. Se non in casi speciali (macchine molto potenti o appositamente studiate per virtualizzare et similia -- leggi i mainframe ).

Quindi come emulatore è assolutamente eccezionale. A meno che tu non riesca a trovare di meglio, ma io non sono a conoscenza [ a parte quelli sul cui codice rosetta è basato che saranno immagino comparabili, postai qua il link dei produttori ].

Uhm, mi permetto di precisare questa cosa qui. Vi sono due approcci all'emulazione della CPU: quello classico (statico o interpretive) ed uno "nuovo" ma non troppo, diventato praticabile grazie alla diminuzione dei costi della RAM (JIT o dinamico).
Gli emulatori statici "traducono" istruzione per istruzione il codice eseguibile non nativo. Per questo sono lenti, perche' devono eseguire una traduzione per ogni opcode, e devono gestire un'emulazione anche dei flag della CPU per poter effettuare i salti condizionati. Si tratta in pratica di interpreti (interpretive, appunto).
Gli emulatori JIT, o dinamici, "traducono" il codice al momento del caricamento (introducendo un ritardo, tanto piu' impercettibile, tanto piu' potenti sono le CPU in gioco, che ormai traducono mega di codice in decimi di secondo...), e da li in poi eseguono il risultato della traduzione come se fosse codice nativo (perche' e' codice nativo....). Naturalmente le ottimizzazioni effettuate al volo sono molto minori di quelle attuate da un compilatore e questo, unito ad un approccio "prudente" per garantire la massima compatibilita' - non vengono prese tutte le scorciatoie possibili, insomma - giustifica comunque una certa perdita di prestazioni. Dovendo tenere in memoria le aprti di codice tradotto per futuri riutilizzi, ed essendo il risultato delle traduzioni in genere meno compatto, ecco spiegato il motivo delle richieste di RAM degli emulatori JIT (che, a proposito, significa Just in Time).

Premessa questa pappardella, prestazioni pari al 5-10% del codice nativo sono normali per emulatori interpretive, prestazioni pari al 40-60% del codice nativo sono normali per emulatori JIT. Rosetta e' un emulatore JIT, pertanto e' giusto affermare che quelle sono le prestazioni attese. Cio' che e' importante piuttosto, e' la robustezza, e non ho dubbio che Apple ci stia lavorando da molto.
Tutto cio' mi e' noto per via della mia passione amighista: noi abbiamo 4 emulatori JIT di 68k (UAE x86, Amithlon, Trance di MorphOS e Petunia di AmigaOS4), oltre a una pletora di emulatori interpretive (tutte le altre versioni di UAE, il vecchio emulatore di MorphOS, quello di AmigaOS4...). Per fare un confronto si pensi all'emulatore 68k che c'era sul Mac all'epoca della migrazione su PPC, che era interpretive, e aveva prestazioni quasi infime. Oggi MorphOS su un vecchio 603e a 175MHz emula un 68040 a 80-100MHz. Qualche benchmark (sia con codice 68k che codice PPC, sia eseguiti su 68k che su PPC che su x86 con Amithlon): http://xoomer.virgilio.it/tuxcam/bench/result.html
Emulare un 68k e' solo relativamente piu' semplice, e Rosetta e' un emulatore JIT di PPC: prima o poi anche questo doveva arrivare. Anche gli autori di PearPC ci stanno lavorando, ee se finiranno il lavoro, PearPC fara' un salto prestazionale di 6-10 volte in un botto. Dove potrebbero esserci problemi prestazionali potrebbe essere il codice Altivec.

Comunque mi pare di aver capito che "OpenPegasos" (è questo il nome? spero si sia capito) è ancora basato su PPC. Idem per le mobo amiga.

Si, con la precisazione che Open Pegasos e' il nome che hanno dato alla pubblicazione degli schematici del PegasosII, che e' basato su 7447 (G4) a 1GHz. Sono disponibili dall'inizio 2006 (al momento solo a clienti "corporate", presto si spera anche ai comuni mortali) le schede CPU con 7447A a 1.4GHz e 7448 a 1.7GHz. Sempre da adesso si possono ordinare schede Blade con due CPU G4, mentre, per restare nel mercato desktop, Genesi mira a introdurre entro il Q2 2006 la Open Server Workstation basata su due 970MP (G5 dual core).
Certo, se resta solo Genesi nel mercato desktop, la vedo dura per la sopravvivenza di quello stesso mercato, a meno di un sorprendente (quanto improbabile) successo di questi design...

Saluti,
Andrea

[riko]

Dove potrebbero esserci problemi prestazionali potrebbe essere il codice Altivec.

Questo è chiaramente pesante da fare, specie senza perdita di prestazioni.

Certo, se resta solo Genesi nel mercato desktop, la vedo dura per la sopravvivenza di quello stesso mercato, a meno di un sorprendente (quanto improbabile) successo di questi design...

Oppure se c'è molto successo del cosiddetto trusted computing. Molti potrebbero cercare un'alternativa Linux + hw "libero". E quindi...
Non so quanti però potrebbero essere.