SSE3 anche nei processori Transmeta

SSE3 anche nei processori Transmeta

Transmeta implementerà il supporto SSE3 in una nuova versione di Efficeon TM8800 che uscirà entro la fine dell'anno

di pubblicata il , alle 16:17 nel canale Processori
 

Transmeta, seguendo le orme di AMD, dovrebbe lanciare una versione del processore Efficeon TM8800 prima della fine dell'anno, incrementando anche la frequenza operativa del medesimo che dovrebbe essere portata a 2GHz.

Con questa scelta Transmeta intende aggungere altre istruzioni x86 ai propri chip in maniera più semplice di quanto fatto da AMD. Efficeon emula x86 ISA in software codificato per il proprio core nativo VLIW a 256-bit. Aggiungere il supporto SSE3 si traduce in una modifica del livello di emulazione.

I processori Transmeta non sono molto popolari tra il pubblico, nonostante le caratteristiche comuneuq interessanti: Efficeon TM8800 è prodotto a 90 nanometri e vanta memory controller DDR400 integrato, interfaccia AGP4x, bus HyperTransport a 400MHz e 1MB di cache L2. Attualmente è disponibile con frequenze operative fino a 1,60GHz e supporta la modalità DEP (Data Execution Protection) sotto Windows XP.

Fonte: Tech Report

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

20 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
luckye07 Ottobre 2004, 16:52 #1
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 !!!
Crisa...07 Ottobre 2004, 16:56 #2
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....
DjLode07 Ottobre 2004, 17:25 #3
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.
Motosauro07 Ottobre 2004, 17:55 #4

Ma su che socket?

O sono solo per soluzioni tipo Embedded?
Confesso la mia ignoranza
Kanon07 Ottobre 2004, 17:57 #5

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)
Motosauro07 Ottobre 2004, 17:58 #6

x luckye

Devo ricordarmi di premere "refresh" prima di postare un commento
lucusta08 Ottobre 2004, 16:37 #7
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..
lucusta08 Ottobre 2004, 16:40 #8
comunque c'e' chi produce sistemi (SBC) con cpu transmeta:
http://www.boser.com.tw/products/sbc/hs2602.htm
cdimauro09 Ottobre 2004, 06:23 #9
Originariamente inviato da lucusta
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.

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.
il vantaggio e' appunto avere un software integrato nel processore che ricompila il codice (in questo caso a 256bit);

I 256 bit si riferiscono esclusivamente all'opcode VLIW generato.
il problema e' la parte puramente HW: se e' poco snella (e registri a 256bit non sono tanto pratici),

Vedi sopra: i registri non sono a 256. Dovrebbero essere a 32 bit, se la memoria non m'inganna.
ed inefficente (pipeline mostruosamente lunghe), non si puo' dar colpa al concetto di core software di essere inefficente..

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

Non penso che andrà così: mi sembra estremamente difficile da realizzare.
oltretutto e' un software, e puo' essere pian piano aggiornato e migliorato (come ora) senza dovre rifare il disegno del chip..

Indubbiamente, ma rimangono le considerazioni di cui sopra, che sono legate all'hardware e non al software...
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.

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.
Comunque sarei curioso nel sapere quali prestazioni avrebbe con codice nativo..

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à.
xeal11 Ottobre 2004, 00:58 #10
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...

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^