SSE3 anche nei processori Transmeta

Ma ma pensavo che ma ma fossero usati quasi esclusivamente in dispositivi supercompatti come Pda e cellulari !! Per che socket sono ? Quanto costano ? Dove si trovano ?? Bellissimi !!!

il bello di questi processori transmeta e che sicuramente non hanno fatto nessuna modifica hardware per usare le sse3, essendoci uno strato software sopra l'hardware che fa i calcoli bruti....

Io direi piuttosto che è la cosa brutta
Hanno prestazioni indecenti (o meglio decenti solo per uso d'ufficio o per tablet). I consumi però sono irrisori e quindi vanno benissimo per sistemi altamente integrati dove le prestazioni non sono il primo target. Ad esempio a me piacerebbe veramente un sacco una cpu del genere o un Via Epia per utilizzarlo come server da lasciare acceso 24 ore su 24. Consumi bassi, poco calore, poca spesa.

Ma su che socket?

O sono solo per soluzioni tipo Embedded?
Confesso la mia ignoranza

dovrebbero abbassare i prezzi

l'implementazione dei crusoe è troppo costosa, anche sui portatili (I centrino ULV costano meno e sono molto più performanti). è vero che raggiungono le 5 (cinque) ore di autonomia, ma sono un mercato di stranicchia. oltretutto credo che transmeta non abbia sufficienti partner per cominciare la produzione destinata a OEM (mobo+cpu, un po' quello che tutti aspettano, qui la concorrenze del Via epia è troppo forte)

x luckye

Devo ricordarmi di premere "refresh" prima di postare un commento

effettivamente li ho visti solo su sub-note e sui sistemi ultraportatili..
comunque sono degli ottimi processori, se si conta il fatto che consumano davvero pochissimo..
un'altra delle particolarita' HW interessante del TM8800 e il suo clock variabile a seconda del'occupazione della cpu, simile allo speedstep di intel od al powernow! di AMD (ora diventato cool'n quiet), solo che nel transmeta il cambio del clock varia a cicli di 100 volte al secondo, con un'efficenza tale che non e' nemmeno pensabile dagli altri processori...
il risultato e' che il transmeta, a riposo, consuma qualche decimo di watt!
il fatto che sia un processore con core logico misto (HW/software) non dovrebbe incidere piu' di tanto rispetto ad un processore X86 odierno, questo perche' un processore odierno traduce comunque le ISA in LISA (Long Instruction Set Architecture), il quale perde drasticamente se viene confrontato ad un chip con algoritmo dedicato ad uno specifico compito (un decodificatore, ad esempio), anche se mette in grado di svolgere un piu' ampio spettro di applicazioni.
il vantaggio e' appunto avere un software integrato nel processore che ricompila il codice (in questo caso a 256bit);
il problema e' la parte puramente HW: se e' poco snella (e registri a 256bit non sono tanto pratici), ed inefficente (pipeline mostruosamente lunghe), non si puo' dar colpa al concetto di core software di essere inefficente..
Un'altro vantaggio si otterra con i multi core (che trasmeta aveva gia' annunciato), in quanto il core software farebbe apparire questi core logici come un mono processore; e non e' un vantaggio da poco..
oltretutto e' un software, e puo' essere pian piano aggiornato e migliorato (come ora) senza dovre rifare il disegno del chip..
oppure potrebbe emulare un PPC o qualsiasi altro tipo di codice (in modo drasticamente lento, daccordo, ma puo' farlo); infatti credo che transmeta sia gia' con X86-64bit.
in pratica questo processore e' stato proggettato per essere un efficentissima cpu X86 in rapporto al consumo espresso, cosa che non si puo' affatto dire di tante altre cpu, come il C3 VIA, che consuma poco, ma che ad efficenza tra' istruzioni svolte e consumo, fa' proprio pena..
Per me questi trasmeta sono delle bellissime CPU (hanno soprattutto il vantaggio d'integrare gran parte dei pezzi per costruire un computer); peccato per le potenze espresse, che non ci sono..
Un domani le CPU saranno concettualmente tutte piu' o meno cosi'...
Comunque sarei curioso nel sapere quali prestazioni avrebbe con codice nativo..

comunque c'e' chi produce sistemi (SBC) con cpu transmeta:
http://www.boser.com.tw/products/sbc/hs2602.htm

Le differenze però sono sostanziali: i processori attuali eseguono la fase di decodifica e arrangiamento delle istruzioni mascherandoli nei primi stadi di pipeline, e quindi permettono di raggiungere prestazioni molto elevate, mentre per questi processori c'è sempre una fase di compilazione JIT, che porta via tempo, oltre a quella di profiling e "aggiustamento" del codice generato, che avviene nelle successive esecuzioni del medesimo.

I 256 bit si riferiscono esclusivamente all'opcode VLIW generato.

Vedi sopra: i registri non sono a 256. Dovrebbero essere a 32 bit, se la memoria non m'inganna.

Beh, qui il problema delle prestazioni è legato a due cose: il fatto che il processore sia un VLIW (con un bundle molto "lungo" e il motivo per cui viene impiegato.
Il primo caso comporta una notevole inefficienza per quanto riguarda lo spazio occupato e ciò che accade quando non è possibile sfruttare tutto il bundle per eseguire quanto più codice (viene "buttato a mare" dello spazio, ma soprattutto delle istruzioni da eseguire).
Per il secondo caso c'è da dire che eseguire codice x86 "tradotto" non è certamente il massimo: già di codice per sua natura è abbastanza "frastagliato" e difficile da parallelizzare, e in questo modo lo diventa ancora di più. Quindi sarà più difficile trarre vantaggio dalle 8 istruzioni eseguibili in un colpo solo.

Comunque, l'adozione di qualunque set di istruzioni SIMD, come le SSE3 in questo, si rivela invece estremamente vantaggioso, proprio perché è nell'esecuzione di questo tipo di codice che questi processori riescono a rendere al meglio, in quanto decisamente parallelizzabile e "lineare".
A ciò aggiungiamo pure che si tende sempre di più a ottimizzare il codice con le SIMD (in particolare il codice critico), per cui globalmente le prestazioni di questi processori dovrebbero essere discrete, a fronte di consumi veramente ridotti...

Non penso che andrà così: mi sembra estremamente difficile da realizzare.

Indubbiamente, ma rimangono le considerazioni di cui sopra, che sono legate all'hardware e non al software...

Già da tempo Transmeta supporta questo set di istruzioni: da prima che Opteron fosse commercializzato, in quanto fu fatto un accordo con AMD, a cui interessava particolarmente, ai tempi, poter debuggare la sua architettura x86-64, valutare le prestazioni e aiutare i programmatori nello sviluppo di software per questa nuova architettura.

Molto più elevate, ovviamente. Ma il problema è che non interessa a nessuno una nuova architettura che si pone in un mercato già abbastanza inflazionato, e soprattutto dominato da x86.

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...