Quote:
La cosa interessante che, invece, non ho ancora visto, è usare questi processori per emulare processori diversi a seconda delle esigenze. Es.: m'interessa lavorare con Mac OS X, allora faccio emulare un PowerPC a questo processore e fatto il boot dalla partizione Mac. Poi m'interessa Windows o Linux, allora resetto e faccio emulare un x86. Ecc. ecc. Il tutto a discreta velocità.
|
E' un'idea davvero interessante, ne deriverebbe una flessibilità notevole che potrebbe diventare il punto di forza di questi processori, oltre ai bassi consumi. L'interesse accresciuto per queste soluzioni potrebbe portare nuove risorse (economiche) e un più rapido miglioramento degli emulatori.
In questo caso specifico, come vedresti una soluzione simile a quella di Itanium per migliorare la velocità dell'emulazione dei 32 bit? Si potrebbe cercare di ottimizzare in background il codice prodotto dal jit per le applicazioni più "critiche"/più usate da un utente e per i kernel degli os, per poi salvarlo su hd, anche se comporterebbe un utilizzo maggiore di memoria; le prestazioni aumenterebbero, no? E se per risparmiare spazio su disco si applicasse una qualche compressione (anche opzionale), con un algoritmo "sbilanciato" a favore della velocità di decompressione (nella sola ram)? Non potrebbe essere un buon compromesso, i tempi necessari alla compilazione jit e al profiling successivo non potrebbero ridursi anche notevolmente? Mi sorge però il dubbio che dopo la decompressione potrebbe essere necessaria un'analisi del codice per la corretta allocazione effettiva del programma... anche se forse si potrebbe integrare nell'algoritmo di decompressione, analizzando le istruzioni appena decompresse e cercare di predisporre la memoria in maniera opportuna per accogliere il programma; oppure in fase di compressione si potrebbero conservare informazioni relative alle pagine da creare e alla natura, per agevolare l'analisi jit...
Qualitativamente, come pensi che inciderebbe sulle prestazioni, rispetto alla compilazione on the fly? Ovviamente, partendo direttamente dal codice rilocabile non compresso sarebbe tutto più velocce...