Multiprocessorer. DEL2 TEKNIK Nr november BRANSCHTIDNINGEN FÖR NORDENS ELEKTRONIKER. förändringar

Transkript

1 DEL2 TEKNIK Nr november BRANSCHTIDNINGEN FÖR NORDENS ELEKTRONIKER Ny sektion: Mjukvara Sid 45 Stora INLEDAREN förändringar Den som inte fick nog av multiprocessorer i förra numret kanske kan få det nu. Vi tar en ordentlig titt bakåt och försöker få det att hänga ihop med vad som kan tänkas hända framåt. Och varför är det då så intressant med multiprocessorer just nu? Ämnet har funnits på kartan de senaste tjugo åren, men den stora skillnaden är att det är allvar nu. Det handlar inte längre om akademiska diskussioner och smala tillämpningar. Nu tar faktiskt datorvärlden steget över till multiprocessorer. Och det gäller alla. Effekterna kommer att bli stora. När alla program är multiprocessoranpassade blir det plötsligt mycket lättare att göra stora arkitekturförändringar. Det kanske till och med blir dags att pensionera John von Neuman. Ingen vet egentligen vad som kommer att hända på lite sikt, men de flesta är överens om att förändringarna blir stora, åtminstone på några års sikt. Det viktiga är att det första steget har tagits. Men även om mycket handlar multiprocessorer tar vi upp andra ämnen också. Bland annat tar vi en titt på ordlängder för embeddedprocessorer. När är det vettigt att använda åtta bit och när är det bättre att ta steget till 32. Det här är inte alldeles uppenbart och det finns fortfarande gott om tillämpningar där åtta bit är bättre, även om skillnaden i kiselarea numera är ganska liten. Vi kastar också ett öga på ett nytt intressant sätt att hantera multiprocessorchip. GÖTE FAGERFJÄLL INNEHÅLL: Multiprocessorer SID Ny era SID 25 Två kärnor bättre än en SID 30 8-bitsprocessorn lever än SID 32 API i IP SID 35 Mönsterkort o substrat SID Snittprov avslöjar det innersta SID 36 Kortare utvecklingstid SID 38 Översikt: Leverantörer SID 40 Kemiskt silver bästa lösning? SID 42 Rätt ytfinish för blyfritt SID 44 Carrier Grade Linux ADSL har mognat SID 45 SID 46 Kanske de senaste 15 årens RISC-utveckling och strävan mot extrema enprocessorprestanda bara blir en parantes. När nu programvaran tvingas att ta steget över till multiprocessorteknik inleds en helt ny era, med enklare arkitekturer, annorlunda arkitekturer och framför allt många processorkärnor. Men egentligen borde den eran börjat för femton år sedan. Vi har vant oss vid att mikroprocessorsystem blir snabbare och kraftfullare för varje år. Det är en utveckling som säkerligen kommer att fortsätta. Men vi har också vant oss vid att prestandaökningen sker via ökad klockfrekvens och fler operationer per klockcykel i en enskild mikroprocessorkärna. Det är en utveckling som garanterat inte kommer att fortsätta. För snart 25 år sedan fick den numera avsomnade tidskriften Byte Magazine ett antal ledande företagsledare och tekniker att berätta hur de trodde att datorsystem skulle se ut år I gruppen ingick bland andra Bill Gates. Med facit i hand visade sig de flesta av gissningarna vara grovt felaktiga. Genomgående underskattade man utvecklingen kraftigt på hårdvarusidan. För normala hårddiskstorlekar var felet uppåt en faktor 100 och ingen trodde att klockfrekvenserna för mikroprocessorer skulle komma ens i närheten av 1 GHz. Redan 100 MHz sågs som en hög klockfrekvens. På mjukvarusidan var i stället uppskattningarna alldeles för optimistiska. De flesta trodde att parallellbearbetning skulle vara vardagsmat och att alla operativsystem och applikationer skulle vara multitrådade år TIDIGA FÖRSÖK Hur kom det sig då att gissningarna från 1980 slog såpass fel? För att försöka förklara det är det enklast att gå tillbaka i historien några år. Närmare bestämt till sjuttiotalet. I början av sjuttiotalet var det tekniskt möjligt att producera en enkel mikroprocessor. På många sätt var det en fantastisk landvinning, men de nya mikroprocessorerna innehöll inga nyheter vad gällde datorarkitektur. De utgick alla från John von Neumans idéer från fyrtio- och femtiotalet. Med en von Neuman-maskin gick det att implementera en enkel processor i några tusen transistorer och mer än så fanns inte tillgång till. Några år in på sjuttiotalet hade mikroprocessorutvecklingen tagit fart på allvar. Nya tillverkningsprocesser gav löften om tiotusentals transistorer på ett enda chip och då blev det möjligt att tänka sig antingen mera avancerade arkitekturer eller bredare arkitekturer. Det första och självklara steget var från fyra till åtta bit (redan 1972), men tidigt stod det klart att 16 och 32 bit var fullt möjligt också med en relativt begränsad transistorbudget. Multiprocessorer Deltas har ett avancerat EMC-center i Västerås, liksom i Hörsholm och inleder ny era Them i Danmark. Det effektivaste sättet att komma vidare är att använda många små sammankopplade enheter. Frågan om arkitektur var betydligt knivigare. Det experimenterades friskt, framför prestanda var ganska dåliga och priset högt. litet antal enheter. Problemet var bara att allt på stordatorsidan, och utvecklingen Den 8086-processor som tagits fram som inom objektorierad kod gjorde att många en interimslösning var nästan lika snabb såg en framtid med objektorienterad hårdvara. Parallellprocessorer fanns redan på samtidigt med 432-processorn Kompo- var både och den processor som blev klar stordatorsidan och det verkade Fig sannolikt 7. Föreslagen att snabbare monolitisk och integration billigare. APX432-arkitekturens med grundbyggblock, tillverkning i SiGe-process. GDP-proces- lagras i av en nenterna antenn parallella arkitekturer skulle vara och lösningen aktiva element också på mikroprocessorsidan. Antennen ligger sorn, på ett var dielektriskt i sin första membran version svarta, av en BCB. ESDskyddande system lå- dyrbar Å andra sidan hade minidatortillverkare Kiselsubstratet under tvåkretslösning antennen och etsas ett bort. komplett som blev alldeles för dyrt. dor En så i ett avancerad 70 m konstruktion som APX432 djupt var höglager alldeles för kiselkrävande för sin tids med tillverkningsprocesser positioner som Digital Equipment visat att en det gick att göra mycket med en ganska enkel datorarkitektur. PDP/8 och PDP/11 byggde på ganska enkla processorarkitekturer och stod som föredöme för många mikroprocessortillverkare. Intersil gjorde till och med en CMOS-implementering av tolvbitsdatorn PDP/8 (6100). INTEL SATSADE FEL Den hittills största och mest vågade satsningen gjorde Intel i mitten av sjuttiotalet. Efter framgångarna med den ganska enkla 8080-processorn ville man göra ett stort språng och en grupp i Oregon fick i uppgift att ta fram en processor baserad på de senaste årens forskning inom datorarkitektur. Projektet resulterade efter drygt fem år i processorfamiljen APX432. Arkitekturen var objektorienterad, hade ett totalt stöd för multiprocessing och virtuellt minne och hade ett mycket avancerat inbyggt säkerhetssystem. Arkitekturen tillät att man blandade processormoduler med olika funktion och tanken var att heltalsprocessorer, flyttalsprocessorer, vektorprocessorer och I/O-processorer skulle samsas i samma system. För att inte bussbandbredden skulle ställa till problem användes intelligenta minnessystem och skuradressering. Med matriskopplade bussar skulle det vara möjligt att bygga stora system med massor av processorer och i framtiden skulle många processorkärnor kunna integreras på samma chip. APX432 blev verklighet och såldes i ett TILL CISC Utvecklingen tog i stället minidatorvägen. Arkitekturer som Motorolas gav goda prestanda och krävde ändå inte särskilt mycket kiselarea. Med lite cacheminne gick det att komma runt de ganska långsamma minnsekretsarna och klockfrekvenser över 10 MHz blev möjliga. Intel bet i det sura äpplet och lade ner APX432. Man satsade i stället på den x86- arkitektur som från början bara varit avsedd för industribruk. Klagomålen över processorn 16 bit breda register och 64 kbyte-segment tystnade när man introducerade processorn. Den stod sig väl i förhållande till Motorolas varianter och hade i jämförelse med en kraftigt förbättrad inbyggd MMU. De inbyggda MMU-funktionerna var en viktig fördel i jämförelse med processorerna. Visserligen hade senare varianter som inbyggd MMU, men då hade redan de olika datortillverkarna gjort egna MMU-implementationer. x86 hade från början bara en variant av MMU. MULTIPROCESSORER Nu var förstås inte Motorola och Intel ensamma om att utveckla processorer, men de flesta följde samma recept som de. Det E-nytt SID 47 Mönsterkort och substrat Sid 36-44

2 Komponenter Forts sid 28 Multiprocessorer... forts från föregående sida fanns också undantag. Det stora undantaget var brittiska Transputer. Dess processorarkitektur var avsedd för multiprocessorsystem och Transputern blev mycket framgångsrik under en period. Det var lätt att koppla samman många Transputer-processorer och totalprestanda blev aktningsvärda. Men Transputern krävde nya sätt att programmera. Programspråket Occam fick en hel del vänner och under en period såg det ut som om det hela skulle bli en succé. Så kom RISC-processorn och ställde det mesta på huvudet. RISC SKÖT UPP UTVECKLINGEN Få begrepp har så många vanföreställningar som RISC. Men de flesta är nog överens om att effekten av RISC-arkitekturen blev dramatisk. Om det sedan på lång sikt blev till fördel eller nackdel kan möjligen diskuteras. En principiell skillnad mellan CISC-arkitekturen och RISCarkitekturen är att CISC-arkitekturen försöker förenkla för kompilator och programvara, medan RISC-arkitekturen bara Det vanligaste sättet att bygga flerprocessorchip är att låta varje processormodul ha en egen L1-cache, men dela på en gemensam L2-cache. är ute efter maximala prestanda och utan att tveka lastar över komplexitet på kompilator och applikationsprogram. Så länge man totalt sett når en prestandaökning är allt bra. Tekniskt sett handlar det mesta om att fylla en pipeline på bästa sätt. Om man kan dela upp instruktionerna i flera steg och utföra de olika stegen på ett löpande band går det att ha flera instruktioner igång samtidigt. Det här kräver bra cacheminnen, hyggligt många register och ett fast format på instruktionerna så att de passar in i pipeline-arkitekturen. Instruktionerna exekveras utifrån registren och man undviker instruktioner som hämtar data från minnet (bara load/store). Antalet instruktioner blir färre (reduced instruction set), men det är inte en nödvändighet. Med den här pipeline-fokuserade arkitekturen kunde klockfrekvenserna skruvas upp och antalet instruktioner per klockcykel ökas. I och med det försvann återigen behovet av multiprocessorsystem och programvaruföretagen kunde andas ut. Det gick att fortsätta i Det går inte att fortsätta samma prestandaökning med dagens processorarkitektur. samma gamla enprocessorspår som tidigare. X86 BLEV OCKSÅ RISC De nya RISC-processorer som introducerades, från företag som Intergraph, MIPS, AMD, IBM, Sun, Digital Equipment, HP etc, var mycket snabbare än CISC-processorerna från företag som Intel och Motorola. Det fick omedelbart följder för Motorola, som i rask följd tappade alla de kunder som tillverkade arbetsstationer. När också Apple hotade att lämna processorn valde Motorola att byta spår från arkitekturen till en ren RISC-arkitektur. I och för sig fanns redan en sådan i produktion (88 000), men kraven från Apple ledde till ett samarbete mellan IBM, Motorola och Apple, baserad på IBMs Power-arkitektur. PowerPC var född. Intel hade inte lika bråttom och valde en helt annan väg. Visserligen började Microsoft samarbeta med MIPS och Digital Equipment och lanserade med tiden till och med Windows NT för Digitals Alpha-processor. 26 ELEKTRONIK I NORDEN 18/2004

3 Forts nästa sida ELEKTRONIK I NORDEN 18/

4 Komponenter Multiprocessorer... forts från sidan 26 Men kopplingen mellan DOS/ Windows och x86 var så stark att Intel inte behövde vara alltför rädda. I stället kunde man koncentrera sig på att använda RISC-teknologin för att snabba upp x86-processorn. Att det skulle gå så bra slog de flesta med häpnad. Redan 486-processorn har lite RISC-influenser, men från och med Pentium slog fördelarna igenom på allvar. Och sedan man väl lämnat de första strömslukande BiC- MOS-processorerna bakom sig gick utvecklingen spikrakt uppåt. Utvecklingen gick från 90 MHz till svindlande 1 GHz och vidare till 3 GHz. Antalet instruktioner per klockcykel ökade från knappt en i snitt upp till ungefär två. Under de senaste tio åren har prestandaökningen varit fenomenal. EFFEKT OCH AVSTÅND Men nu verkar det vara slut på enkla sätt att öka prestanda och den här gången är det svårt att se några möjligheter att komma runt problemen. Att ta ett lika stort steg igen i en enprocessorarkitektur skulle kräva klockfrekvenser på kanske 200 GHz och det är fullständigt omöjligt med de tillverkningsprocesser som finns eller kan förväntas under den närmaste tioårsperioden. Intel har också meddelat att man inte går över 4 GHz, utan i fortsättningen arbetar med multiprocessorkonfigurationer. Problemen ligger både på processidan och i kostnaden att öka prestanda. På processidan heter problemen effektförbrukning och ledarfördröjning. Effektförbrukningen är det mest uppenbara problemet. Fram till kanske 0,13 µm gick det att kompensera ökade klockfrekvenser och ökad komplexitet med sänkt matningsspänning. Den dominerande effektförbrukningen kom från omslag i transistorer och det gick att hålla ned förbrukningen genom att inte klocka i onödan. Ändå är det kylproblemet som avgör hur snabbt man kan köra. Processorn i en snabb desktopdator måste ligga under ca 70 W och i en arbetsstation klarar man kanske att kyla bort 120 W. Från 90 nm och nedåt kompliceras problemet ytterligare av att den statiska strömförbrukningen, läckströmmen, ökar såpass kraftigt. Det är i och för sig lätt att tillverka transistorer med låg läckström, men de blir långsammare. En riktigt snabb processor, i 4-5 GHz-klassen, kräver snabba transistorer och då är risken stor att chipet förbrukar 70 W bara på grund av läckströmmarna. Även om den inte klockas alls kommer den att förbruka så mycket effekt och om processorn skall göra något som helst arbete fördubblas effektförbrukningen snabbt. Nästa intressanta problem är att ledarfördröjningen på chipet inte minskar, tvärtom ökar den med minskande geometrier. Det innebär att processorerna får allt svårare att nå platser som ligger ett stycke bort på chipet. Det blir till och med svårt att kommunicera snabbt mellan olika delar av processorn. Här är redan problemen stora och de kommer att öka mycket snabbt. ALLTFÖR DYRT Men det verkligt intressanta är att titta på kostnaden för att göra processorerna effektivare. Om man till exempel jämför en processor med en Pentium 4-processor är det ingen tvekan om att prestanda per klockcykel är mer än dubbelt så stor hos Pentium 4-processorn. Men antalet transistorer är å andra sidan 40 gånger större. En kanske rättvisare jämförelse är mellan gamla Pentium och Pentium 4. Då är skillnaden bara tolv gånger. Då går det förstås att köra Pentium 4-processorn i mycket högre klockfrekvens, men alternativet skulle kunna vara att lägga in 12 eller 40 processorkärnor och i stället för 3 GHz köra på kanske 400 MHz, respektive 200 MHz (vi får kompensera för busskollisioner, färre instruktioner per klockcykel Högre klockfrekvenser ger kraftigt ökad effektförbrukning. Kylflänsarna dominerar den här Ithanium-baserade servern från HP. etc). Det intressanta är att vi då skulle minska effektförbrukningen dramatiskt. Vi kan använda långsamma transistorer med låg läckström, vi kan minska matningsspänningen och vi minskar den dynamiska effektförbrukningen. I CMOS ändras ju den dynamiska effektförbrukningen exponentiellt mot klockfrekvensen och en halverad frekvens ger en mycket större minskning i effektförbrukning. GRATIS GRINDAR I halvledarprocesser från 90 nm och nedåt är tillgången till transistorer utomordentligt stor. Intel säger sig till exempel kunna lansera sitt första chip med över 1 miljard transistorer redan nästa år. Begränsningen ligger i stället i effektförbrukningen, inte minst den effektförbrukning som beror på läckström. Man måste också hålla ledarna så korta som möjligt i varje funktionsblock. Det här talar för en arkitektur med många små processorkärnor. En enkel matteövning visar att man till exempel skulle få in 500 processorer i 486-storlek eller processorer i 386-storlek i en krets med en miljard transistorer. Då behöver inte klockfrekvensen vara särskilt hög för att totalprestanda skall bli hisnande. PROGRAMVARAN AVGÖR Det enkla sättet att öka processorprestanda är alltså att integrera många processorkärnor på samma chip. Varför har då utvecklingen mot multiprocessorsystem tagit så lång tid? Orsaken ligger nästan helt och hållet i programvaran. Det är långtifrån trivialt att ta fram operativsystem och applikationsprogramvara för multiprocessorsystem. Så länge det var möjligt att höja klockfrekvensen och dessutom göra mer per klockcykel var det ett mera attraktivt alternativ. Att man sedan går allt längre in i en återvändsgränd har hela tiden setts som ett problem för framtiden. I och för sig har det hela tiden funnits datorer med flera processorer och multiprocessortillämpningar, men det har alltid handlat om specialtillämpningar för till exempel databashantering eller tekniska beräkningar. Våra vanligaste program är fortfarande skrivna för en enda processor och enda sättet att snabba upp ett sådant program är att använda en snabbare processor. Däremot har allt fler operativsystem stöd för flera processorer eller flera trådar i en processor. Windows NT/2000/XP, Linux, OS/X, Solaris och de flesta Unixversioner kan hantera många processorer. Men det här innebär för det mesta bara att det blir lättare och effektivare att köra flera program samtidigt. Virusskydd, utskriftsrutiner och konverteringsarbeten går mera smärtfritt i bakgrunden. Däremot påverkas ännu så länge inte det aktiva programmet, till exempel ordbehandlaren eller det grafiska redigeringsprogrammet. Men det här håller alltså på att ändras och den här gången ser det inte ut att finnas några alternativ. Alla tillverkare av programvara försöker nu bryta upp sina tilllämpningar i små byggblock som går att parallellisera. Det är ett stort och svårt arbete med många möjligheter till obehagliga fel och problem. Men den här gången finns det som sagt inga alternativ. Alla vet att nästa generation datorer kommer att vara baserade på multiprocessorteknik och de program som inte kan dra nytta av det kommer att framstå som hopplöst långsamma i jämförelse med parallelliserade program. Så det som vi väntat på i ett tjugotal år håller nu äntligen på att hända. FÖRST FLER TRÅDAR En övergång till multiprocessorteknik kommer på sikt att innebära en övergång till helt nya arkitekturer, men till att börja med blir det mer av det som vi redan är vana vid. Ett bra exempel på det är den senaste generationen av Pentiumoch Xeon-processorer. De har fortfarande bara en processorkärna, men kan ändå köra två separata trådar och alltså två separata program. I princip har processorn två hanterare för schemaläggning och så fort det finns en ledig plats i processorns pipeline försöker någon av enheterna att fylla den. På det här sättet kan processorns resurser utnyttjas effektivare. Samma sak har de flesta andra processortillverkare gjort. Det mest extrema exemplet är MIPS, som har en teknik med i princip oändligt antal trådar i samma processor. Då kan man till och med använda mekanismen för att ersätta eller förenkla operativsystem i embeddedtillämpningar. Men i praktiken är det knappast intressant att ha mer än några få trådar per processor. Sedan är processorns pipeline full för det mesta och man når inga ytterligare fördelar. Nästa steg är att lägga in fler processorkärnor på samma chip. Intel har redan gjort det med Ithanium-processorn, men mera intressant är att man kommer med Xeon- och Pentium-processorer med flera processorkärnor. Återigen är detta inget nytt. IBM har haft processorer med flera Power-CPUer i flera år och samma väg tar de flesta andra. För embeddedtillämpningar lanserade ARM sin MPCore i våras 28 ELEKTRONIK I NORDEN 18/2004

5 och Freescale har lanserat en PowerPC-processor med dubbla processorkärnor. De närmaste åren kan vi alltså förvänta oss integrerade multiprocessorer med i princip mer av vad vi är vana vid idag. Det är ett relativt enkelt sätt att äta kakan och ha den kvar. Eftersom varje enskild processor är lika snabb som dagens processorer försämras inte prestanda för befintliga tilllämpningar, samtidigt som parallelliserade tillämpningar blir klart snabbare. Om man i stället valde att ha fler, men långsammare processorkärnor skulle de befintliga tilllämpningarna i ett slag bli mycket långsammare. Det är svårt att acceptera i en övergångsperiod. snitt och behöver inte göra lika många arkitekturavvägningar. Men lika viktigt är att processortillverkarna får en mycket större frihet att göra ändringar i processorarkitekturen. Huruvida Ignius kommer att lyckas kan vi lämna därhän. Sannolikt är deras lösning alldeles för intressant för att de stora processortillverkarna skall släppa en sådan godbit. Men principen är intressant och visar en möjlig väg. En av de viktigaste trenderna de senaste åren är den mot standardiserade öppna gränssnitt och ett standardiserat processorgränssnitt på en något så när hög nivå skulle kunna förenkla för många. En trolig utveckling är i alla fall att morgondagens processorkärnor snarare blir enklare än mera komplicerade. I det läget har nog processarkitekturer som Ithanium (IA64) inte mycket att hämta. 64 BIT Och till slut några ord om 64 bit. Det är väl alldeles utmärkt och i en del fall till och med nödvändigt. Dessutom behöver en processorarkitektur med 64 bits bredd inte särskilt många fler transistorer än en vanlig 32-bitsarkitektur. Det visade MIPS och flera andra för många år sedan. Därför spelar det egentligen inte så stor roll vilken bredd man väljer på de individuella processorkärnorna. Det är mycket mera en fråga om programvara än om hårdvara. Eftersom jag började med Intels intressanta, men misslyckade APX432-processor kan det kanske vara lämpligt att sluta med Intels Ithanium-processor. Den var på sin tid tänkt att bli nästa stora arkitektursteg, men verkar väl i ärlighetens namn gå samma väg som APX432. VLIW och extremt avancerade arkitekturer är knappast den väg som utvecklingen tar. I stället blir det återigen x86 som får brygga över tills nästa stora skifte. AMD valde att utvidga x86 till 64 bit (vilket inte är särskilt svårt) och nu tvingas Intel att rätta in sig i ledet. Xeon-processorer med utvidgningar för 64 bit kompletteras med Pentium 4-processorer med samma sak. På kort sikt är det här en ganska stor händelse, men i ärlighetens namn inte särskilt revolutionerande. Det är däremot steget till multiprocessor! GÖTE FAGERFJÄLL SKIFTE PÅ VÄG Men på sikt kommer säkerligen förändringarna att bli mycket större än så. Vinsten med att använda små och enkla processorkärnor är alldeles för stor för att inte tillverkarna skall gå den vägen. När väl tappen är ur tunnan öppnas helt nya möjligheter att öka prestanda genom att använda inte bara två eller fyra, utan kanske hundratals processorkärnor. För den stora förändringen är ju steget från enkelprocessor till multiprocessor. När väl det steget är taget står helt nya möjligheter öppna. Arkitekturdebatten är redan igång och vi kommer de närmaste åren att få se förslag till helt nya processorarkitekturer. De som var med på sjuttio- och åttiotalet kommer förmodligen att känna igen sig bättre än de som vant sig vid RISC-hegemonin de senaste femton åren. Vi kan alltså förvänta oss en mycket intressant period och stora systemskiften. Var det kommer att sluta är omöjligt att säga. Vi vet vilka problem som finns och att dagens processorarkitekturer är olämpliga av en lång rad anledningar. Men om svaren skall hämtas med utgångspunkt i sextiotalets datorforskning eller i helt nya idéer är omöjligt att veta. Intressant kommer det i alla fall att bli. ÖVERGRIPANDE API Ett sätt att ta tag i multiprocessorproblemen kommer från det relativt nystartade företaget Ignius. De har utvecklat ett byggblock som fungerar som ett gränssnitt mellan applikationen och processorkärnorna. Applikationen ser ett enda programgränssnitt (API), trots att det kan finnas ett stort antal processorkärnor av samma eller olika typ. Gränssnittet tar bland annat hand om schemaläggningen av de olika processorkärnorna. Att introducera en mellannivå av det här slaget ger flera intressanta fördelar. Operativsystem och applikationsprogram får ett något så när standardiserat gräns- ELEKTRONIK I NORDEN 18/