Transmeta introduceert Efficeon TM8000-processors

Transmeta heeft 14 oktober de Efficeon TM8600 en TM8620-processor officieel geïntroduceerd en de officiële specificaties bekendgemaakt, na al eerder de aankondigingen de wereld ingestuurd te hebben. Zoals al eerder bekend was, kan deze processor acht instructies per klokcyclus verwerken en is de architectuur gebaseerd op 256-bit oftewel het is een Very Long Instruction Word-processor. Daarnaast gaat de processor ook alle extra multimedia-instructies ondersteunen, zoals MMX, SSE en SSE2 en is er de beschikking over een 1MB L2-cache.

Naast deze ondersteuning heeft het bedrijf ook eigen software ontwikkeld om de processor beter te laten presteren: de tweede generatie van Code Morphing Software. Deze software draagt bij aan een efficiënter energiegebruik en een verbeterde reactiesnelheid met betrekking tot het verwerken van de verschillende instructies. Dit kunnen zowel RISC zijn als x86-instructies zijn. Dit alles laat de Efficeon een maximale kloksnelheid van 1,1GHz bereiken, terwijl er slechts zeven Watt aan energie zal worden gebruikt en ook nog zonder fan.

Wat ook al duidelijk was geworden is dat de Efficeon HyperTransport gaat gebruiken. Nog onbekend was welk geheugen in combinatie met deze processor toegepast kan worden. Dat is minimaal DDR266 tot maximaal DDR400 SDRAM geworden, met ECC-ondersteuning als optie. Daarnaast maakt de toepassing van een geïntegreerde northbridge het mogelijk om goedkoper en kleiner te produceren. Zo meet de oppervlakte van de Efficeon TM8820 21mm², terwijl de nVidia nForce3 Go 120-southbridge ook klein van stuk is: 22mm². De standaard Efficeon TM8600 zal 29mm² aan oppervlakte meten, dankzij ondermeer het 130nm-productieproces.

Transmeta hoopt dat deze energiezuinige processor zijn weg zal gaan vinden in handhelds, pc's en servers. Verder zal de Efficeon dankzij zijn specificaties en prestaties een grote concurrent van de Intel Pentium-M kunnen worden. Deze concurrentie met de Pentium-M zal verder in 2004 worden uitgebreid met de introductie van een 2GHz-processor in 2004. Hoewel deze dan wel 25Watt zal gaan gebruiken, maar de grootte zal waarschijnlijk niet toenemen omdat er dan op 90nm worden gebakken. Voor 2005 legt Transmeta de lat wat betreft het productieprocédé wat hoger, of liever gezegd wat kleiner, aangezien de roadmap dan van een 65nm Efficeon-processor spreekt. In eerste instantie zal de 130nm Efficeon worden geproduceerd door TSMC, waarna medio 2004 Fuji dus de 90nm 2GHz-processors gaat produceren.

Reacties (38)

[Muyz]

Wat ik me afvraag is het volgende: waarom doelt Transmeta met dit soort processoren niet op de mensen die thuis een home theatre PC maken? VIA heeft (oa) voor dit soort gebruik de C3 beschikbaar voor hun Mini-ITX borden. Op dit formaat borden zou je bv. ook een Transmeta kunnen plaatsen.

Met name het VLIW karakter, de ondersteuning van multi-media instructies en de geringe dissipatie van de Transmeta maken deze processor hiervoor IMHO uitermate geschikt.

[pietje63]

Die markt is vrij klein.. Alleen tweakers maken hun eigen htpc (of mensen die hun eigen htpc maken zijn tweakers...) en dat zijn er niet zoveel.

Deze cpu zal wel een mooi begin zijn voor een off-the-box (kant en klare) home theater pc.

verder...

al eerder bekend was, kan deze processor acht instructies per klokcyclus verwerken en is de architectuur gebaseerd op 256-bit oftewel het is een Very Long Instruction Word-processor
Kan iemand dit uitleggen? Is dit dezelfde 256 bit als dat AMD net 64 bit aan het introduceren is?

Verder pakken ze het wel slim aan, alle technieken (mmx, sse(2)) inkopen en daardoor zelf vrij lage R&D kosten hebben. Een cache grootte van 1MB vergt ook lage R&D kosten (maar hogere kosten per cpu) en zorgt ook voor een redelijk snelheids winst.
Door beide zijn er lage investeringskosten wat voordelig is bij een cpu waarvan er waarschijnlijk (in verhouding tot de cpu generaties van intel/amd) erg weinig worden verkocht.

[Muyz]

Nee, deze 256 bits zijn niet geheel hetzelfde als de 64-bits technologie van AMD/Intel.

Met VLIW wordt bedoeld dat de 256 bits instructie feitelijk acht instructies bevat van ieder 32 bits (in die zin is het dus een 32-bits CPU). Deze acht instructies kunnen parallel door de processor worden uitgevoerd.

De 64-bits technologie van AMD/Intel betekent dat een instructie-woord 64 bits bevat. Je kunt dan ineens meer bits opslaan, laden, optellen, etc. omdat je in 64 bits nu eenmaal meer kunt opslaan dan in de huidige 32 bits. Er zit in tegenstelling tot een VLIW processor echter maar een instructie in die 64 bits.

Een belangrijke consequentie van het toepassen van een VLIW architectuur, zoals TransMeta dat nu doet, is dat je compiler moeilijker wordt. Je hebt nl. per clockcyclus acht instructies om te vullen. Dit is niet altijd mogelijk doordat je maar een beperkte hoeveelheid logica in je processor hebt. Door het slim verschuiven van instructies kun je bv. de bezettingsgraad van je processor optimaliseren.

[Squee]

Nog om even wat toe te voegen aan het verhaaltje van Muyz:

De instruction words van 256 bits bestaan dus uit 8 32 bits RISC achtige instructies, welke gescheduled worden door de codemorphing software, die dus de x86 instructies vertaald en scheduled in deze VLIW instruction words.

Het idee van de Transmeta processoren is juist de simpele logica, door het gebruikt van de code morphing software is er geen geavanceerde register renaming, reordering en scheduling hardware meer nodig in de processor.

[Roflmao]

Wat ik me afvraag hoe deze processors zich vergelijken met met de huidige intel en amd processors, misschien zijn ze helemaal niet bedoeld om te concurreren met intel of amd, maar toch, ik wil het gewoon weten

Edit:
spelfouten

[imagica]

Transmeta hoopt dat deze energiezuinige processor zijn weg zal gaan vinden in handhelds, pc's en servers.

Hiermee geeft het aan een concurent/alternatief te worden voor Intel/AMD aangezien deze processor dankzij de 2e generatie Code Morphing software ook x86 instructies en ook de MMX/SSE/SSE2 multimedia instructies (volledig?) ondersteund.

[Beaves]

De eerste Transmeta CPU's ondersteunden de x86 architectuur ook volledig (mits er natuurlijk de juiste code werd "geladen", als men RISC heeft geladen zal x86 natuurlijk niet werken).

Het enige verschil is dat Transmeta een vernieuwe code morphing engine heeft gebruikt bij deze nieuwe serie CPU's die dus hun werk sneller doen. Dat is een van de grootste verbeteringen aangezien de vorige engine nou niet echt uitblonk in snelheid.

Dat was ook niet verassend, het was de eerste CPU van Transmeta en als ik het zo lees hebben de de engine flink verbeterd met als gevolg dat de perfomance flink gestegen kan zijn. In ieder geval wordt deze CPU als er geen rare dingen gebeuren een geduchte tegenstander.

De Pentium-M en de Dothan zullen sneller zijn, maar die verbruiken dan ook bijna 5x zoveel energie (de huidige Banias). Dat houd in dat de Efficeon uitstekend geschikt zullen zijn voor de mensen die geen Pentium-M kwa snelheid nodig hebben maar liever 3x zo lang met de accu doen. (Managers die veel onderweg zijn bijvoorbeeld hebben geen 1,7GHz CPU nodig).

Nu alleen afwachten welke OEM's met Transmeta in zee gaan, zonder OEM's heeft Transmeta weinig kans.

[Roflmao]

Je snapt het een beetje verkeerd, ik bedoel real-life benchmarks, office, internet, games, 3d rendering enz.

[Verwijderd]

Kan deze proc nou zonder fan werken?
Plaatsing in handheld lijkt me trouwens iets te veel van het goede denk dat er tablet pc bedoelt moet worden.

Is de nieuwe Code Morphing Software nu ook voordelig voor de huidige gebruikers van de andere processoren of staat dat los van elkaar?

[bazs2000]

Deze processor wordt niet heet en daarom volstaat alleen een heatsink. Dit is meteen één van de grote voordelen van deze processor omdat de warmteproductie en het stoomverbruik tegenwoordig toch wel een probleem begint te worden. Grote servers mogen dan in speciale ruimtes staan met een goede airco maar dat is niet overal het geval. Dan is dit weer erg handig.

Een handheld moet het daarentegen weer doen met een beperkte hoeveelheid energie, als je dergelijke rekenkracht wilt hebben dan is een Intel of AMD of zelfs Cyrix geen goed idee omdat deze toch nog teveel energie tot zich nemen en bovendien behoorlijk warm worden.

[Verwijderd]

Hele mooie prcoessor.
Een erg laag energie verbruik met zoals ik het hier zie een redelijk hoge verwerkingssnelheid.
Ik hoop spoedig enige benchmarks te zien waarbij het verschil met andere processor is te zien.

[gp500]

ik sta Er ook zo even naar te kijken.
Een moois staaltje werk van transmeta.

zeker die ddr266-400 had ik zo 123 niet verwacht.

Nu nog eens benchmarks.

[Nimrod|IA]

De processor zal alleen een alternatief worden als de prijs laag genoeg zal zijn.
De c3 is een succes gewoon omdat ie zo goedkoop is.
De eerst generatie transmeta processors was gewoon te duur voor de preformance die ze leverde.
een cpu op 600 Mhz leverde de snelheid die onder een Celeron 400 Mhz was.

[eggieman]

Voor iedereen die zich zit te verspekken aan de 256 bits ...
Die 256 bit zegt niet wat iedereen hier denkt.
Die 256 is de grootte van de blokjes waar de echte core mee werkt. Elke x86 instructie kun je schrijven als een assembly code bijv:

ADD eax, [esi]
Dit wordt door bijv Masm vertaalt naar een bitcode die je processor zo kan uitvoeren.
Deze codes kunnen nogal complex zijn de code hier telt de data op het adres aangeven door register esi op bij het register eax. Hierbij moet er dus uit het geheugen gelezen worden en worden opgeteld.
Elke processor tegenwoordig zet x86 om in andere code. Bij iNTEL heet dit microcode, bij AMD zijn dit macro-optcodes.
De efficeon vertaalt de x86 naar 256 bits opdrachten. Hier kunnen dus meerdere opdrachten in zitten. Net zoals een AMD 3 macro-opt tegelijk kan uitvoeren. AMD vermeldt alleen het aantal pipelines. Transmeta de maximale troughput. Het voordeel is dat de transmeta er misschien wel regelmatig 4 opdrachten in weet te proppen. Maar bij de grootte SSE2 opdrachten (met een 128bits getal) ben je meer dan de helft al kwijt. Verder heb je altijd dat er een bepaalde "alignment" in moet zitten, er zullen dus lang niet altijd veel opdrachten tegelijk in de 256 bits zitten.

Een vergelijking met het datapad van AMD64, daar zitten 3 paralelle ALU's in die elk dus dus al een 64 bits data pad hebben en daar bij nog eens een commando pad heeft, waarvan de breedte geheim is (De concurentie hoeft niet te weten hoe je alles intern codeert) maar die moet enkele bytes breed zijn zit je alles bij elkaar ook wel 256.

Maar volgens mij is dit echt wel een leuk processortje, maar ben wel benieuwd hoe hij presteert. Er is op de site van Transmeta nog geen echt diepgaande info te vinden.

[Verwijderd]

mooi, concurrentie is altijd nice .

Zijn er eigenlijk ook via c3 laptops?

[Verwijderd]

C3 ?

Dat is geen Transmeta.. dat is van VIA (Cyrix III)

[hardwareaddict]

Deze Efficeon processor lijkt de droom van elke wetenschapper die geinteresseerd is zijn software snel uit te laten voeren. 8 instructies per clock is voor vector programma's natuurlijk geniaal.

Wat we niet weten is hoeveel instructie 1 daadwerkelijke x86 instructie naar vertaald wordt.

Ook weten we niet kosten van branch mispredicties etcetera.

Dus het is nog onduidelijk hoeveel Gflops dit potentieel kan halen.

Mogelijk is dat meer als de itanium2 en dat tegen een sterk lagere prijs. Voor complexe wetenschappelijke software gaat deze efficeon sneller zijn als de itanium2 en dat al op voorhand.

De reden is vrij simpel. De instructiecache van de itanium2 is veel en veel te klein. Efficeon heeft 128KB en de I2 heeft maar iets van rond de 32KB.

Veel en veel te weinig voor de I2. Typisch intel. Dure onderdelen op een processor daar wordt niet in geinvesteerd want 'we willen hem spotgoedkoop bakken'. Met een 4x grotere L1 instructiecache en een 2x grotere datacache als de itanium2, gaat de efficeon natuurlijk wetenschappelijk gezien de itanium2 volledig wegvegen (op voorwaarde dat er genoeg floating point execution units zijn op de efficeon).

Echter, bij een processor is het niet alleen handig dat je processor snel is, hij moet ook gebruikt worden door highend fabrikanten.

In dat opzicht zullen we dus weinig horen van transmeta.

Voor normaal gebruik heeft de efficeon een veel kleiner stroomverbruik als de P4, maar
net als de P4 practisch ook tering traag voor meer als de helft van de software, heeft ook deze Efficeon dezelfde nadelen, zo niet nog meer als de P4.

O wee als de pipeline gaat stallen en o wee als die x86 decoder niet goed werkt.

Desalniettemin een prachtige processor. Nu moeten ze hem nog wat hoger zien te klokken.

[Tjark]

Krijgen we straks naast nano-itx ook een pico-itx

[Dries Arnolds]

Demmit, waar is mn pc gebleven

[boner]

waty mij nou benieuwt is of er ook een native mode is. Dus niet een mode waarin een intel wordt geemuleerd maar eentje waarvoor je een echte VLIW proc hebt.

Als je dat doet en daar een UNIX variant voor maakt zal dat wel eens schneller kunnen zijn dan welk server systeem ook dat je zo kunt kopen.

[eggieman]

Als ik het een beetje begrijp moet hij die Code Morphing laden wil hij x86 ' tje spelen. En als je wil kan hij ook risc laden en dan native uitvoeren. Misschien dat hij dan ook idd die vliw native kan uitvoeren. Moet echter nog blijken dan hij dan sneller is. Voordelen zijn natuurlijk dat de meuk niet meer vertaalt hoeft te worden, maar een aantal nadelen :
1. Waarschijnlijk is deze code veel maar dan ook veel groter (veel "lucht" door alignment, niet te paralliseren onderdelen) Dus een veel grotere druk op de geheugenbus.
2. om multitasken sneller te maken zal er ook wel iets als register renaming in zitten, zulke dingen moeten dan opeens op software niveau worden geregeld. Dat kan nooit sneller zijn.
3. de cache wordt veel minder zinnig. Omdat de herschrijfregels tot VLIW niet telkens het zelfde zullen zijn.

[Squee]

Als ik het een beetje begrijp moet hij die Code Morphing laden wil hij x86 ' tje spelen. En als je wil kan hij ook risc laden en dan native uitvoeren. Misschien dat hij dan ook idd die vliw native kan uitvoeren. Moet echter nog blijken dat hij dan sneller is. Voordelen zijn natuurlijk dat de meuk niet meer vertaalt hoeft te worden, maar een aantal nadelen :
1. Waarschijnlijk is deze code veel maar dan ook veel groter (veel "lucht" door alignment, niet te paralliseren onderdelen) Dus een veel grotere druk op de geheugenbus.

Waarom zou de code in VLIW minder goed paralelliseerbaar zijn dan de x86 code die vertaald wordt? Dat hangt compleet af van je compiler dan, ipv de CMS.

2. om multitasken sneller te maken zal er ook wel iets als register renaming in zitten, zulke dingen moeten dan opeens op software niveau worden geregeld. Dat kan nooit sneller zijn.

Ja maar dat wordt nu ook in software gedaan (CMS), dus het zal toch ook niet langzamer zijn Overigens ga ik er van uit dat de Efficeon wel shadow registers heeft, aangezien de Crusoe dat ook had. Deze werden daarin gebruikt om na een x86-exception de processor weer in de oude staat te brengen.

3. de cache wordt veel minder zinnig. Omdat de herschrijfregels tot VLIW niet telkens het zelfde zullen zijn.

Ja, maar hij wordt ook weer juist een boel zinniger! De hele CMS zit niet meer in de cache, dus je hebt een boel meer cache vrij voor je "echte" software. Dit lijkt me juist een voordel ipv een nadeel!

Iets wat ook nog een probleem is als je native wil gaan draaien, is dat er een goeie compiler voor deze processor moet komen. Bij een VLIW moet namelijk alles gescheduled worden in software, wat dan normaal door CMS gedaan wordt, maar als je native draaid schuif je deze complexiteit dus terug naar de compiler.

[Verwijderd]

Het terugschuiven van complexiteit naar de compiler lijkt vooralsnog een beetje het probleem (Itanium presteert ook niet zo 'wereldschokkend', en das toch wel zo'n beetje hetzelfde concept)

Overigens is er nog een nadeel van het in VLIW native mode draaien : je bent je run-time optimalisaties kwijt als je alles vooraf als static VLIW compiled. Meestal is dat wel sneller, maar als de runtime optimalisaties echt goed zijn...

[eggieman]

Ja, maar hij wordt ook weer juist een boel zinniger! De hele CMS zit niet meer in de cache, dus je hebt een boel meer cache vrij voor je "echte" software. Dit lijkt me juist een voordel ipv een nadeel!

Ik weet heel zeker dat dat niet in de standaard cache zit maar meteen op de processor. Het is geen programma! Het zijn herschrijf regels, net als de Athlon en P4 x86 vertalen naar interne code. Ik weet dat de Pentiums op een gegeven moment ook een herschrijfbaar gedeelte van zo'n "tabel" hadden. Omdat ze iets als de bekende Pentium-bug op de processor konden opvangen.

Het nadeel is de enorme hoeveelheid NOP's die je mee cached...

[Squee]

Ik weet heel zeker dat dat niet in de standaard cache zit maar meteen op de processor. Het is geen programma! Het zijn herschrijf regels, net als de Athlon en P4 x86 vertalen naar interne code. Ik weet dat de Pentiums op een gegeven moment ook een herschrijfbaar gedeelte van zo'n "tabel" hadden. Omdat ze iets als de bekende Pentium-bug op de processor konden opvangen.

Het nadeel is de enorme hoeveelheid NOP's die je mee cached...

Ik weet heel zeker dat het wel in de standaard cache zit, want ik heb toevallig laatst een research paper/case study over de Transmeta Crusoe geschreven, en ben er van overtuigd dat ze het bij de Efficeon niet anders aangepakt zullen hebben
Het is dus juist wel degelijk een programma wat gewoon op dr proc draaid, iets heel anders dan hoe de Athlon/P4 etc de x86 instructies (met hardware) in micro-ops vertalen!
Die Code Morphing software is dermate groot en complex, dat het iets van 2 MB geheugen in beslag nam. In totaal werd de eerste 16 MB van het main memory coor CMS gereserveerd, namelijk de eerste 2 MB om het CMS zelf in te zetten, en de rest werd gebruikt als translatie cache, voor het cachen van vertaalde stukken x86 code.
De CMS wordt als de processor opstart vanuit een (compressed) image uit ROM gelezen....

[roelio]

Ik ben vast blind, maar wat is het verschil tussen de 8600/8620 en de 8820 ?