Meer details over derde generatie Chinese Godson-cpu vrijgegeven

Chinese onderzoekers leggen de laatste hand aan de Godson-3, een quadcoreprocessor die op 1GHz loopt. In 2009 zou er ook een variant met acht kernen gereed moeten zijn; voor 2010 staat de Godson-supercomputer op de rol.

De quadcore-versie van de Godson-3 komt over enkele maanden uit, claimt Zhiwei Xu, leider van het Chinese Institute of Computing Technology. Xu gaf meer uitleg over de architectuur van de Godson bij de Hot Chips-conferentie, die afgelopen week aan de Stanford University werd gehouden.

De quadcore en de octocore worden beide op 65nm gebakken en krijgen beide een kloksnelheid van 1GHz. Bij het ontwerp van de Godson-3 is vooral gelet op het energieverbruik: de quadcore verbruikt 10W, terwijl de octocore 20W verstookt. De Godson-3 is gebouwd rond de Mips64-architectuur, waaraan nog tweehonderd instructies zijn toegevoegd voor de compatibiliteit met x86-machinetaal en voor de versnelling van multimedia-rekenwerk.

Hoewel de Godson-3, ook bekend onder de naam Loongson, nog dit jaar zijn intrede zal maken, is onduidelijk wanneer de massaproductie zal aanvangen. Wel liet Xu doorschemeren dat hij in 2010 een petaflops-supercomputer op basis van de cpu gereed wil hebben.

De Godson-1, die in 2002 het levenslicht zag, was nog een 32bit-cpu. Begin 2005 verscheen de tweede generatie van de Chinese chip, die van 64bit-ondersteuning voorzien was. Volgend jaar moet de Godson-2H klaar zijn en volgens Xu wordt hierbij de functionaliteit van gpu, cpu en north- en southbridge gecombineerd op een enkele chip.

Reacties (34)

[TheSiemNL]

Damn, ze gaan wel snel. Straks zitten ze nog eerder op 45nm dan AMD.

Nu nog goede moederbordjes en je hebt een low voltage servertje in huis. Ben benieuwd wanneer de eerste commerciele exemplaren komen.

[Reactie gewijzigd door TheSiemNL op 5 augustus 2024 05:54]

[martijnvanegdom]

Voorlopig nog niet in de rest van de wereld.. Naar ik meen hebben ze helemaal geen licentie voor x86 en Mips64

[kidde]

Naar ik meen hebben ze helemaal geen licentie voor x86 en Mips64

STMicroelectronics wel, en dat is de maker en distributeur van Loongson's voor Westerse landen. Zie

http://www.st.com/stonlin...roprocessors/loongson.htm

[Verwijderd]

Deze chips worden steeds MIPS processoren genoemd. Dat is niet helemaal juist. Om problemen te vermijden zijn een aantal instructies vervangen door de chinezen. MIPS software werkt er wel op maar het is niet 100% MIPS.

Ik vermoed, maar ken nog geen details, dat ze met de x86 iets soortgelijks gedaan hebben. De Longsoon lijn is helemaal geen x86 processor. Windows erop kun je dan ook vergeten maar ik kan me zo voorstellen dat het misschien erg handig is om x86 instructies te hebben voor emulatoren o.i.d.

In elk geval kun je de municators gewoon kopen in de VS en de EU en dat zou zeker niet het geval zijn als er inbruik werd gemaakt op IP van Intel.

[psychicist]

De processoren hebben inderdaad een eigen microarchitectuur die meer op die van een Alpha processor lijkt, maar om de ontwikkeling en beschikbaarheid van software te versnellen is ervoor gekozen om een MIPS frontend aan te bieden.

De meeste patenten daarop zijn in de tussentijd verlopen, alleen de unaligned instructies worden niet ondersteund. Alle software die ik tot nu heb gecompileerd is compatibel met MIPS III (32-bit en 64-bit) en dat levert geen problemen op.

Om het maximale uit de processor te halen is het verstandig om GCC 4.4 of de PGI (Portland Group) compiler te gebruiken, die beide de extra instructies in Loongson 2E/2F ondersteunen. Dat zal ik binnenkort zelf ook doen, waarbij het me interessant lijkt om te weten te komen hoeveel beter de processor nog kan presteren met de juiste optimalisaties.

SiCortex heeft bovendien het Pathscale compiler team overgenomen, dat SGI's MIPSPro compiler heeft doorontwikkeld. Wellicht valt er uit die hoek ook nog iets interessants te vernemen.

[Reactie gewijzigd door psychicist op 5 augustus 2024 05:54]

[ThE_ED]

Hoe beïnvloedt het toevoegen van "nog tweehonderd instructies" de werking van de cpu eigenlijk? Is dat niet een beetje onvoordelig eigenlijk, voor de prestaties? Leuk dat ie nu ook x86 architectuur ondersteund wel, maar je had er ook iets anders mee kunnen doen, of juist weglaten... Mijn proc architectuur kennis is niet geweldig om te kunnen zeggen wat dit doet voor de prestaties.

[GENETX]

Een instructie is een handeling. Zie het een beetje als rekenen. Als jij de volgende som ziet:

2 x 2 =

Dan weet jij dat je moet gaan vermenigvuldigen, zie je een +-teken staan dan weet je dat je moet optellen.

Een CPU doet eigenlijk hetzelfde. Door middel van een commando gaat de CPU optellen, aftrekken, vermenigvuldigen en dergelijke.

Als een CPU bijvoorbeeld niet zou kunnen vermenigvuldigen dan gaan juist de prestaties achteruit, dan zal deze een loopje moeten doorlopen om bijvoorbeeld 3 x 4 uit te rekenen. Dat wordt dan een loopje als:

y:= 0;
for x:= 1 to 4 do y:= y + 3;

Dat zorgt er voor dat je in plaats van alleen het commando vermenigvuldigen het optel commando een aantal keren moet uitvoeren. En nog dieper, de antwoorden zullen ook weer naar de juiste registers worden verplaatst. Dat komt er op neer dat je al snel een stuk of 8 instructies verder bent, als het niet meer is.

Als je dan bedenkt dat een CPU elke kloktik een instructie verwerkt dan snap je dat die methode langer gaat duren. Over het algemeen zijn meer instructies dus beter aangezien ze in vooral complexe gevallen sneller het antwoord kunnen berekenen omdat die instrucite er is. Daardoor heb je dan geen algoritme van veel instructies nodig om aan het antwoord te komen.

Een RISC (Reduced Instruction Set Computer) processor kent minder instructie. Daardoor is de chip minder complex, kleiner en zuiniger. Echter is deze over het algemeen ook minder krachtig. Dergelijke chips zijn prima voor embedded spul en voor in mobieltjes. Deze moeten zuinig zijn en hebben niet zoveel rekenkracht nodig. Complexe berekeningen worden al helemaal niet gedaan.

[Reactie gewijzigd door GENETX op 5 augustus 2024 05:54]

[Verwijderd]

Meer instructies zorgt wel voor meer en complexere hardware (in de vorm van hard-wired control of een microstore). Vooral een (grote) microstore is duur op de chip en kan de werking van de processor trager maken.

Je laatste paragraaf is niet helemaal waar. Een RISC hoeft niet perse minder krachtig te zijn dan een CISC. Bovendien is een RISC processor makkelijker te pipelinen, wat ook weer voordelen op kan leveren

[Jaco69]

Over het algemeen is een RISC processor zelfs krachtiger dan een CISC processor. Het klinkt onlogisch maar vaak is zelfs de intructieset krachtiger.

[GENETX]

Dat zou ik zo niet weten, ik denk dat het er van afhangt waar je hem voor gebruikt. Ik denk dat simpele bewerkingen inderdaad wel eens sneller kunnen zijn dan op een CISC. Maar ik denk toch dat een CISC voor complexe berekeningen beter is.

[0rbit]

Neem bijvoorbeeld de bekendste RISC processor de ARM. Juist door de beperkte instructieset en truukjes die branching voorkomen (bijvoorbeeld bij for-loops) heeft het ding een enorme kracht per transistor en per kloktik. Ook kan het ding bijvoorbeeld bitshiften en addities in slechts 1 instructie doen. Als je het normeert per transistor (of per watt) dan is de ARM een van de meest krachtige CPUs die er bestaan.

[Verwijderd]

@Mr_A
Bitshift in 1 operatie is idd mogelijk, als je bv 1 bit positie shift. Echter als je 2 bitposities wilt shiften zul je die operatie 2 keer moeten doen. Ook kun je een direkte 2 positie shift inbouwen, echter dan heb je ineens 2 keer zoveel transistoren. Dan heb je ook nog een 3 bit positie shift, 4 bit posities, etc. Maw je kunt het extreem snel maken, maar je CPU core wordt wel veel groter. De Motorola 68K heeft een bit shift van maximaal 8 bits; als je bijv 11 bit posities wilt shiften moet je eerst 8 shiften, dan nog een keer, 3 bits.

Optellen kan pertinent niet in 1 operatie, omdat elke bit afhangt van de carry van de vorige kolom. De optel operatie begint aan de rechterkant van de 32 bits en cascade langzamerhand naar de linkerkant. Helaas, iets simpels als optellen is traag. Wel kun je nog je 32 bits opbreken in segmenten, en de operatie op de segmenten tegelijkertijd doen. Daardoor is de cascade minder diep en is het sneller. De segmenten die afhangen van een carry (allemaal behalve degene aan de rechterkant) worden dubbel opgeteld, tegelijkertijd; een keer aannemende de carry=0, en een keer aannemende de carry=1, Als het vorige segment klaar is weet je de carry en wordt van het opvolgende segment het resultaat worden genomen dat gebaseerd is op de juiste aanname van de carry.
Dankzij de verdubbeling in het aantal transistoren, een verdubbeling van het verbruik, en de hogere complexiteit kan optellen beduidend sneller worden, zo'n 25%-100% schat ik.

Vermenigvuldigen is een kwestie van shiften en optellen. Als je wilt vermenigvuldigen met 10 bijv, dan breek je dat op in factoren die 2 tot de macht x zijn. 10 breek je op in 8 (2^3) en 2 (2^1). Voor elke factor neem je originele getal, dan shift je het links met x bits. De shift is een deel van de daadwerkelijke vermenigvuldiging. Nadat alle factoren zijn geshift, tel je de faktoren bij elkaar op. Dit is relatief snel, maar hangt af van een efficiente shift (wat veel transistoren kost) en een efficiente opteller die relatief veel stroom trekt.

Delen kan niet worden gedaan met een truukje, en is traag. Ik heb geen idee waarom vroeger de Cyrix en AMD CPUs altijd trager waren dan Intel met delen, ben niet zover gegaan met de studie!

[Reactie gewijzigd door Verwijderd op 5 augustus 2024 05:54]

[dgompie]

Precies, als er evenveel geld was gegooid op het ontwerp van de ARM voor Desktops, dan weet ik bijna zeker dat ie minimaal zo krachtig en veel zuiniger dan de huidige x86 chips zou zijn. Ik vond het ding ook prima in Assembler te programmeren (toch zeker als je Z80 gewend was

[Patriot]

Dat zijn gewoon instructies die uitgevoerd kunnen worden door de processor, als je software wil installeren die die instructies gebruikt moeten deze natuurlijk wel ondersteund worden. Als de processor niet x86-compatible is zal veel software niet draaien.

[Verwijderd]

Aan de formele MIPS architectuur worden alleen nieuwe instructies toegevoegd wanneer die aantoonbaar minimaal 1% performanceverbetering opleveren in een normaal programma. Het doel hiervan is om de architectuur eenvoudig te houden, wat precies het sterke punt van MIPS is. Zelf lukraak wat instructies toevoegen (zeker als het er 200 zijn) is dom en lijdt vrijwel zeker tot een suboptimale CPU.

[psychicist]

MIPS64 zal geen enkel probleem zijn, want ST Microelectronics, dat de processoren produceert, heeft in 2007 een 5-jarige licentie genomen op deze instructieset. X86 zal meer problemen opleveren, maar naar ik meen wordt deze instructieset niet direct ondersteund, waarbij de nieuwe instructies voor het versnellen van het binaire translatieproces dienen.

[Verwijderd]

Voorlopig nog niet in de rest van de wereld.

Wie is de rest van de wereld?

Ze hebben zo wie zo minimaal 1,2 miljard potentiële consumenten. Waarschijnlijk zijn er wel meer landen die bij de juiste prijs het ontbreken van de licentie door de vingers zien.

[Verwijderd]

Ik lees niks over het snel overschakelen op een kleiner procédé jij wel? Alleen dat het huidige ontwerp op 65nm is. De CPU is nog vrij simpel in vergelijking tot een volwaardige x86 CPU dus iets met appels en peren?

[Verwijderd]

Vrij simpel ? Die chips zetten een prestatie per watt neer waar de Atom's en VIA's niet eens in de buurt kunnen komen. Het 800 Mhz model leverde je ongeveer de kracht van een P4 - 2,4 Ghz bij een verbruik < 10 watt.

De kostprijs van de municator PC's (ex scherm) is zo laag dat je het met een OLPC kunt vergelijken maar je kunt er een volwaardige linux distro moeiteloos op draaien.

Noem dat maar simpel

[Kul]

Heb je hier een bron voor?
Het klinkt ongelofelijk (goed) namelijk..

[psychicist]

Je kunt ervan uitgaan dat de processor klok voor klok ongeveer zo goed presteert als een Intel Pentium III of AMD Athlon. Hoe de prestaties van een Loongson 2F op 800 MHz zich verhouden ten opzichte van een Intel Pentium IV op 2.4 GHz weet ik niet, want laatstgenoemde processor heb ik nooit gehad.

De ondersteuning van GCC en andere compilers voor Loongson processoren was tot dit jaar echter nog niet optimaal, waardoor de huidige code in de meeste gevallen gecompileerd wordt voor een MIPS I processor uit 1987 of een MIPS III uit 1994.

Bovendien heeft Loongson 2F als voordeel dat de northbridge, PCI-X bus en geheugencontroller in de processor zitten ten opzichte van de Loongson 2E processor die in mijn huidige syteem zit. Daarvan zijn dus ook nog substantiële prestatieverbeteringen te verwachten.

[Praetextatus]

Waar jantje Vlaam waarschijnlijk op doelt is dat elke Godson type een korte doorlooptijd heeft. Dus in plaats van rustig te ontwikkelen en 15-20 jaar erover te doen doen zij het in een paar jaar. Of reverse engineering of andere truuken worden gebruikt laat ik even buiten beschouwing. Feit blijft dat zij opzelfde productie grootte zitten als AMD. Ook de snelheidstoename in mhz-en is vrij hoog ook al zegt dat niet veel over de prestaties. Hoe simpel of hightech de cpu is kan jij of ik nog niet oordelen omdat we er geen tests van hebben gezien

Wel meen ik ergens gelezen te hebben dat deze vergelijkbaar waren met p3s en ook dat linux er doodnormaal op draaide. Alleen heb even geen source bij de hand daar het een tijd geleden is dat ik t heb gelezen.

Dus ze zijn inderdaad vrij snel in vergelijking met AMD en Intel en als de verhoudingen zo blijven liggen dan zal er binnen niet al te lange tijd (5-10 jaar?) een 3e groote speler meedoen met AMD en Intel

Kan ik alleen maar toejuichen

edit/ typos

[Reactie gewijzigd door Praetextatus op 5 augustus 2024 05:54]

[johnbetonschaar]

Waar jantje Vlaam waarschijnlijk op doelt is dat elke Godson type een korte doorlooptijd heeft. Dus in plaats van rustig te ontwikkelen en 15-20 jaar erover te doen doen zij het in een paar jaar. Of reverse engineering of andere truuken worden gebruikt laat ik even buiten beschouwing.

Die chips die ze daar in China ontwerpen worden gewoon gebakken met dezelfde machines als die gebruikt worden door Intel, AMD en welke andere chipfabrikant ook. Dat ze in China zelf processorontwerpen maken wil niet direct zeggen dat ze ook de complete productietechonologie opnieuw aan het uitvinden zijn. Waarschijnlijk sturen ze die designs gewoon naar TSMC ofzoiets, en liggen ze naast de chips van de concurrentie op de productielijn. Dus het zal zeker niet zo zijn dat er een Godson IV op 32nm gaat komen voordat de rest van de wereld op die technologie kan produceren.

[Reactie gewijzigd door johnbetonschaar op 5 augustus 2024 05:54]

[Praetextatus]

Kun jij dan aangeven waarom AMD zo n moeite heeft met 45 nm productie procede en lopen ze ongeveer een jaar achter op Intel ?
Volgens mij is t niet zo zwart wit als jij t nu zo zegt. Het shrinken van een cpu is blijkbaar niet zo makkelijk, anders was AMD nu net zo ver als Intel.

[GENETX]

Het is niet alleen het shrinken van een CPU, het zit hem meer in het beschikbaar hebben van de juiste apparatuur en productietechnologie met genoeg yields. Intel heeft gewoon meer geld om onderzoek te doen naar een nieuw procédé dan IBM/AMD. Die hebben nu pas 45nm op orde zodat de fabriek ook daadwerkelijk genoeg werkende 45nm CPU's utipoept.

Dit probleem is er niet wanneer je dit laat doen door een bedrijf als TSMC, die heeft die apparatuur op een bepaald moment gewoon beschikbaar. Je moet dan alleen nog je ontwerp er voor klaar hebben en de productie kan starten. Mede daardoor zitten de ATI kaarten ook op een ander procédé als de AMD Processoren, AMD kan de videokaarten namelijk niet in eigen huis fabriceren.

[Praetextatus]

Precies en dit staaft ook de bewering dat de Chinezen toch wel relatief snel zijn met eigen CPU ontwerpen. Het kost geld en energie om onderzoe te doen en dat hebben ze ook gedaan.

[Verwijderd]

Mede daardoor zitten de ATI kaarten ook op een ander procédé als de AMD Processoren, AMD kan de videokaarten namelijk niet in eigen huis fabriceren.

Het is niet dat AMD het niet kan. Maar het is meer dat ze het niet willen. Doordat ze het een ander bedrijf laten doen hebben ze zelf minder risico. Als AMD niet in de licentie van de x86 hadden staan dat ze maar maximaal 20% extern mogen laten produceren hadden ze op dit gebied ook meer outsourced.

[MrSnowflake]

Compatibiliteit met x86 wil dat zeggen dat mijn x86 linux die ik 'toevallig' op een cdtje heb liggen zomaar op deze Godson-3 kan installeren? Zou wel leuk zijn!

Ik dacht trouwens dat ze x86 niet wouden ondersteunen om niet afhankelijk te zijn van het buitenland? (wat dus wel niet helemaal te uitvoering werd gebracht met hun MIPS architecturr, maar dat te zijde).

[killercow]

Daar is geen x86 compatibliteit voor nodig hoor, linux doet t ook prima op mips en 50 andere archs oid.

Door verschillende x86 instructies wel te ondersteunen weet je iig dat er na een port van x86 software naar Mips software niet hele vreemde dingen gaan gebeuren omdat je een cruciale multimedia instructie mist.

[imp4ct]

't Jah China is een land dat een beetje in "overontwikkeling" zit als je het mij vraagt. En dat ze zelf hun CPU's maken wijst er alleen meer en meer op dat ze niet afhankelijk willen zijn van andere spelers.

'k Vraag me alleen af of hun expertise in deze sector groot genoeg is om het op te nemen tegen Intel of AMD, hoewel het me niet zou verbazen dat China wetenschappers gewoon weghaalt als het ze acht nodig te hebben.

[GENETX]

Ooh de kennis zullen ze absoluut hebben. Een CPU namaken is bijna net zo moeilijk als aan een beginnen. Je zult toch de kennis nodig hebben om problemen in je eigen kopie er uit te halen.

[AntiPasta]

Compatibiliteit met X86-instructies? Dat zou wel een primeur zijn! Ik vraag me af hoe ze dat hebben opgelost met een totaal afwijkend instructieformaat.

[Nafets]

Das geen primeur hoor de Transmeta procs deden dat ook
door code morphing http://en.wikipedia.org/wiki/Code_morphing

[Reactie gewijzigd door Nafets op 5 augustus 2024 05:54]

[jeroentb]

Mogen deze chips de westerse markt wel op ?
Ik neem namelijk aan dat voor patenten niet wordt betaald, dus zal de westerse markt ze niet accepteren toch ?