Intel udvikler første processor uden beskyttelse
more_vert
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.

Intel udvikler første processor uden beskyttelse

Chipgiganten Intel har udviklet en processor uden de sikkerhedsmarginer, der normalt beskytter processoren og sikrer den lang levetid. Derved opnår man en processor, der enten bruger mindre strøm eller kan udføre mere arbejde for den samme mængde strøm.
I tal betyder det en øget ydeevne på 21 procent eller en besparelse på op til 37 procent ved at fjerne de såkaldte "guard bands".

»Traditionelt har vi designet cpu'er meget konservativt, men hvis vi fjerner alle sikkerhedsmarginer, kan vi fremstille et meget mere effektivt produkt,« siger Wen-Hann Weng, der er chef for kredsløbsdesign hos Intel Labs i Beijing til Ing.dk.

Ved at fjerne alle "guard bands" løber man dog den risiko, at produktet ikke kan arbejde med fuld ydeevne i hele produktets levetid. Det skyldes blandt andet de termiske påvirkninger som cpu'en udsættes for, når der tændes og slukkes for computeren.

»Ulempen er, at det kan være nødvendigt at justere clockfrekvens og spændingen, men i mange tilfælde vil slutbrugerne hellere have et hurtigere produkt,« fortsætter Wen-Hann Weng.

Der har tidligere været præsentationer af, hvordan cpu'er kunne designes uden sikkerhedsmarginer, men det er første gang, at der er fremstillet en mikroprocessor, der kan udføre et komplet, kommercielt anvendeligt instruktionssæt. I dette tilfælde IA, der kendes fra de traditionelle processorer fra AMD og Intel.

Resultatet af Intels forskning bliver processorer, der anvender mindre energi eller udfører mere arbejde for den samme energimængde, hvilket vil føre til et lavere effektforbrug, der også afspejles i lavere omkostninger til køling, der er det område, der kræver det største effektforbrug i datacentre, hvor processorerne også vil kunne anvendes.

Emner : Processorer
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Ovenstående minder om asynkron forsinkelsesuafhængig logik - her kører processoren bare det den kan følge med, og øger automatisk hastigheden hvis den køles ned, eller sænker den, hvis den varmes op.

Imidlertid, er dog helt forkert, at sige at det er et produkt uden sikkerhedsmargin. Sikkerhedsmargin for forsinkelsesuafhængig logik, er ideelt set uendelig - i modsætning til synkron logik, hvor den måske kun er sat til 20%. Ved asynkron logik, løber processoren så hurtigt som den kan løbe - men ikke hurtigere end det - og netop derfor, er sikkerhedsmarginen i princippet uendelig.

I praksis, anvendes ofte en kombination af self-timed logik, og asynkron logik. Men det er alt for risikabelt at lave self-timed logik, helt uden sikkerhedsmargin, så for denne del er sikkerhedsmarginer som for normal synkron logik. At logik er self-timed, betyder der er en lille forsinker på chippen, som typisk udsættes for samme strabasser som de komponenter der er årsag til forsinkelsens nødvendighed, og en komponent der har behov for større forsinkelse får så også større forsinkelse. Men her, er det bestemt overdimmensioneret.

Jeg synes det er noget forkert at sige at man sløjfer sikkerhedsmarginer - for det er helt forkert. Der, hvor det er nødvendigt, f.eks. for self-timed logik, vil der være sikkerhedsmarginer, og da den self-timede logik har forsinkelser der laves på chippen, og på samme måde som årsagen til forsinkelsens nødvendighed, er en overdimmensionering ofte reelt større, end hvis det var gjort i forhold til en ekstern klokke.

Forsinkelsesuafhængig asynkron logik vil svare når data foreligger, og der skal ikke "ventes" på en klokke. Derfor er sikkerhedsmargin uendelig. Selvom en komponent pludseligt bliver dobbelt så langsom som førhen, vil kredsløbet stadigt fungere perfekt - i modsætning til ved normal logik, hvor det ikke vil tåles af komponenten er mere end 10-20% langsommere, da sikkerhedsmargin normalt ikke er større. Med andre ord, så virker asynkron logik, uanset hvor sløv at en transistor bliver, og derfor er sikkerhedsmargin uendelig. Hvorimod at den "normale" synkrone logik laver fejl, hvis eksempelvis en forsinkelse ikke er stor nok.

Synkron logik, er i virkeligheden værre end det ser ud til, da dette også indeholder self-timed logik i mange tilfælde. Enkeltfaset synkron logik (f.eks. D-Flipflops, JK-Flipflops, og andre edge-triggede flipflops) indeholder forsinkelsesafhængig logik. Disse forsinkelser er meget små, og svarer i problemstilling til frekvenser der er langt over 10 - 20 GHz. Kun hvis der anvendes flerfaset synkron klok, kan sådanne problemer undgås. Mange problemer på chips skyldes idag at der anvendes enkeltfase klok, og derved skal forsinkelserne matches, f.eks. igennem et shift register. Ved enkeltfaset synkron klok, er det ikke klokkens klokfrekvens der er flaskehalsen men hensyn til pålidelighed, men den forsinkelse der er i logik og flipflops. Anvendes flerfaset klok, er muligt at helt undgå sådanne problemer, og dermed at såfremt klokfrekvensen bare er lav nok, så vil kredsløbet fungere uanset hvor sløv en transistor måtte være.

Når ingeniører idag har problemer, hvor de skal anvende P-Spice og justere forsinkelser så at kredsløbet fungerer, men at klokfrekvensen hellerikke tvinges for langt ned, så er de i høj grad selv ude om det: De anvender en teknologi, der er særdeles skøbelig, og afhængige af de små forsinkelser. Et typisk design, lavet med normal synkron klok, er hele vejen igennem præget af timing problemer, såsom at resultatet afhænger af, hvad der kommer først. Ofte er det svært at få til at fungere, eller upålidelig. Hvis derimod, at der anvendes flerfase synkron klok, findes ikke sådanne problemer. Tingene vil "bare virke", hvis det logisk set fungere. Du behøver knapt at overveje timingen, hvis ikke det var for at udregne hvor hurtigt kredsløbet kan køre. Det vil altid fungere, hvis bare klokken er sløv nok. I forhold til synkron logik, er det også hurtigere, da data flyder over latchene og det betyder der ikke er setop og holdetid. En latch, giver derfor ikke anledning til forsinkelse, på samme måde som flipflops. Tofase klok, klarer derfor normalt også en væsentligt højere klokfrekvens. Ved samme klokfrekvens, vil dataene "flyde" over latchene, og løser dermed selv mange problemer med hensyn til timingen. Resultatet er langt mindre kritisk timing ved samme klokfrekvens, fordi at hvis en komponent f.eks. forsinker mere - og en anden forsinker mindre - så vil det fungere. Fra at være et "worst case" problem, bliver timing problematikken til en middel over flere komponenter. Og det betyder igen, at hvor man normalt må sætte alt i kasser af bestemt størrelse - så vil det blive mere effektivt, og kunne klare større timingskev, og normalt større klokfrekvenser, hvis at klokken styres korrekt.

Asynkron forsinkelsesuafhængig logik har store fordele i CPU design, fordi det selv fortæller når data ankommer. Det betyder, at hvis jeg f.eks. laver en CPU, som jeg giver 16 indstruktioner der udføres efter hinanden (først folder jeg eventuelle loops ud, og herefter forwarder jeg, så hvis ALU5 bruger data fra ALU2 så hentes data via en multiplexer), så vil den tid det tager at alle indstruktionerne ikke mere være proportional med antallet af indstruktioner, men proportional med den binære dybde. Dette er langt hurtigere, end på nogen måde logisk kan udregnes på forhånd, og scheduleres. I mange år, har man forsøgt at logisk vurdere om to indstruktioner brugte data fra hinanden, og schedulere sig ud af problemet, for at kunne anvende to CPU'er ideelt. Ulempen er, at man her ikke ser på den logiske dybde i problemet - og igen får man sat problemet i "kasser" der er væsentligt overdimmensioneret i forhold til problemets størrelse. Ser du på den samlede ALU som en "super alu" og hvornår den er færdig, så vil en ALU, hvor det er muligt at konkludere bit 7 går høj, fordi bit 5 og 6 tvinger den til det, kunne anvende bit 7 i de efterfølgende ALU'er straks, uden at se på bit 0 og 1. I mange tilfælde gør den slags problemer sig gældende - f.eks. hvis du lægger éen til et tal, trækker éen fra, og mange andre. Alt det med carry lookahead betyder næsten intet. Og det betyder igen, at man kan satse på at lave ALU'erne hurtigere med hensyn til forsinkelsen i beregningen, fremfor at ofre resourcer på lookahead, der også gør ALU'en sløv i beregningen. Og igen, fås derfor større antal beregninger i sekundet, trods deres data afhænger af hinanden. Worst case, er at menten flyder lidt bagefter, men oftest vil det ikke ske, da "noget" måske forudsiger den på forhånd, fordi at nogle af de øverste bits er høj, eller lav. Man kan bevise, at sandsynligheden for at en bit ribler igennem hele vejen er meget lav, og at den typiske dybde er O(log(n)) til antal bits, eller mindre - altså på samme niveau, som look ahead.

Typisk vil man lave hurtige processorer, hvor nogle veje er mere optimeret end andre, og så omregne indstruktionerne til VLIW - hvor der i VLIW indstruktionssættet også er angivet forwardingen mellem CPU'erne. Dette kan nu regnes ud, så der bruges den mest effektive indgang på en funktion, i forhold til den kritiske path. Ved ADD indstruktioner, er indgangene x og y symetriske, så de ombyttes til største effektivitet, meddens man ved SUB indstruktionen indfører to, der er optimale for henholdsvis X-Y eller Y-X og der så kan vælges den SUB indstruktion, så der er den mest optimale vej igennem kredsløbet. Optimeringer af den type, kan ofte få indstruktioner der udføres i rækkefølge speeded op med en faktor to, og dette er i nogle algorithmer netop flaskehalsen. I den type problemer, vil så kunne opnås noget der svarer til dobbelt klokfrekvens.

Jeg går ud fra, at Intel har "indset" at asynkron og forsinkelsesuafhængig logik, gør sig egnet i VLIW processorkerner, og at det er det som det drejer sig om. Historien om, at man har sløjfet sikkerhedsmarginer kan næppe have noget på sig. Sandsheden er sandsynligvis, at man har valgt en kredsløbsserie, der er robust overfor f.eks. forsinkelser (forsinkelsesuafhængig logik), og derfor ikke behøver marginer. I teorien er sikkerheden nu uendelig, hvor den før var afhængig af enhver path og transistors forsinkelse.

  • 0
  • 0

Out of order execution, den intelligente løsning imho, understøttes i ARM's Cortex A9 CPU.

Intels processorer understøtter også out of order. Men det er ikke det samme, som at f.eks. tage indstruktionerne til 16 processorer, og koble dem sammen ved hjælp af forwarding, samt se på hvornår hver enkelt bit er færdig. Årsagen er, at du arbejder bitvis, og f.eks. en "or 80h", sætter bit 7, og den så kan bruges i næste indstruktion uanset hvad der kommer ind. Ved out of order, tager du en worst case for hele indstruktionen, uanset hvad den beregner. Ved out of order scheduleringen ved man hvad der ønskes gjort, men man kender ikke data som der arbejdes på.

Du kan sagtens kombinere de to metoder - out of order, vil så give lavere dybde i den beregning som de asynkrone ALU'er udfører. Men ofte vil out of order kun finde indstruktioner der kan udføres totalt uafhængigt af hinanden, og ikke kunne anvende processoren effektivt hvis der udføres et stort antal indstruktioner. Skal her laves out of order, er det ikke kun at finde indstruktioner som ikke forbinder hinanden, men også at finde nogen der bruger hinandens resultater med lille dybde - og det skal udregnes, så processoren finder passende dybder og udfører samtidigt. Det er en smule kompliceret, og kan bedst lade sig gøre i software. Det man kan, er at indbygge det i en dynamisk compiler (f.eks. en in-time oversætter, som oversætter fra Intel kode, til noget "speciel" maskinkode, hvor også out of order tages i betragtning under oversættelse). Ellers er det en tung opgave, og det koster også strøm. Gøres det af en oversætter, kan resultatet gemmes i flash eller på harddisk og huskes til næste gang, hvor hastigheden så øges, og strømforbruget mindskes.

Forskellen mellem de out-of orders som Intel og AMD bruger, og den der opstår når kredsløbet trådes op til at fungere over flere indstruktioner ved at ALU'erne direkte trådes sammen, f.eks. med multiplexere, baseret på forwardingen (i nogle tilfælde kan forwardes over flere indstruktioner end der reelt udføres, ved at "forrige" cycles indstruktioner ligger tilgængelige, og det giver mulighed for større fleksibilitet med hensyn til brug af registerfiler f.eks. at undgå konfligt), er primært at den logiske out-of order udregning alene gør det udfra indstruktionernes path imellem hinanden, og ikke udfra data på udførselstidspunktet. Det betyder, at de bitmæssige fordele der opstår i et optrådet netværk, ikke betragtes i out of order beregningen, og den ser alene på, om to indstruktioner kan udføres totalt uafhængigt, og ikke delvis uafhængigt. Gives indstruktionerne derimod til masser af ALU'er, og man så lader dem afgøre hvornår at data foreligger, så tages højde for alt. Man kan så optimere koden, f.eks. reducere dybden ved at flytte paranteser (a+(b+(c+d))) = (a+b)+(c+d) og forsøge at schedulere koden, så ALU'erne bruges bedst muligt.

Det sjove er, at mange processorudviklere anvender en del chip plads på out of order eksekvering. Og denne plads, kunne være brugt på et antal ALU'er i et ligeså stort antal, som out of order udregningen foregår over... Med andre ord, vil faktisk være bedre foruden. Flere ALU'er, der trådes op, og selv udregner out of order, vil få større beregningskapacitet, og selvom de så måske ikke anvendes helt så effektivt, så vil det større antal som opnås ved at spare out-of order delen, ofte give en hurtigere CPU. Out of order, dynamisk pipeline, og mange andre "advancerede" teknologier, kan også have tendens til at sløve CPU'en i dens flaskehals, og derved medføre færre indstruktioner kan udføres i rækkefølge. Skal den slags ting udregnes, skal det helst ske før level 1 cache. Det kan ske med f.eks. forwardingen (så komperatorer til forwarding og udregning af prioriteringen ved brug af samme registre undgås i den inderste loop), og det kan ske - specielt i software - for advancerede algorithmer, der placerer de rette indstruktioner i VLIW indstruktioner.

Jeg tror på, at fremtiden er in-time compilers, fordi det er bedst at tilegne maskinkoden til processoren, og ikke gøre software afhængigt af denne. Med en in-time compiler, er muligt at decideret oversætte til en given CPU, og gøre det udfra dens indre parametre såsom forwardingens størrelse. Hver CPU får sin kode, og in-time compilere laves individuelt til alle CPU'erne. Ofte vil de være relativ ens, men kunne indeholde parametre, såsom pipelinens dybde, registre, ol. og så oversætte optimalt til brug af hardwaren. De vil også kunne udregne out-of order execution, og de vil have mulighed for at overskue kode mange megabytes længere fremme i programmet, ved nogle programmeringssprog. Out-of order execution på den måde, svarer noget til parallelisering af sekventiel kode automatisk, og så opskrive mange tråde, hvor de enkelte tråde udføres uafhængigt. Her vil opstå så mange tråde i mange tilfælde, at der skal udvælges hvilke der udføres på de begrænsede antal ALU'er. Og denne udvælgelse er også kompliceret.

  • 0
  • 0

Jeg forstår kun ca 1/3 af dine indlæg, men det jeg troede og jeg synes er interessant er at det lader til at ting som out of order execution passer som en puslespilsbrik mht software abstraktion som f.eks. OpenCL og GCD på mac'en. Disse forbedringer i software arkitekturen betyder et boost på ca 50% i ydelse. Der er altså belæg for at det kan betale sig.

Når jeg mener intel jagter ARM er det fordi at Arm kan levere bedre ydelse pr watt. Denne nye opfindelse fra intel tilsigter det selv samme. Med andre ord er denne opfindelse "blot" et træk i spillet om at levere silicium til markedet.

  • 0
  • 0

Jeg tror ikke der er noget at sige til, at ARM leverer bedre ydelse per watt. Intel er for længst gået bort fra deres egen arkitektur, og alle nyere processorer har stjålden RISC idéen, og implementeret den i stedet - derfor, har Intel en oversætter kørende i CPU'en, der oversætter simultant, og også bruger strøm. Så det siger næsten sig selv, at de altid vil bruge lidt mere strøm, da de har brug for strøm til oversættelse. Hvis ARM valgte, at supportere Intel indstruktioner, ved at lægge en lille Intel to ARM konverter ind først, så forstår du lidt af idéen med Intels arkitektur, og hvorfor den ikke er hel god.

Det lyder meget sandsynligt at du får ekstra i ydelse, når der håndteres out of order. Men det tager også op på chippen, og ikke mindst bruger strøm - så man må overveje om man vil bruge arealet på flere processorer, eller out of order. Bruges flere processorer, vil de også til en vis grad få out of order, fordi at ordrer der har lavere dybde over n indstruktioner udføres hurtigere. I nogle tilfælde betyder dybden end ikke så meget, fordi at der arbejdes bitvis. Out of order, vil dog som regel kunne øge ydelsen, men udfra et strømmæssigt synspunkt, tror jeg det er bedre med et større antal ALU'er, der forwarder data til hinanden (så n indstruktioner bindes sammen i en samlet logisk komponent incl. eventuelle afhængigheder). Afhængighederne betyder ikke så meget, på grund af den bitvise anskuelse. Hvis man kan beskæftige et stort antal ALU'er, uden afhængigheder, og derved bruge out of order optimalt, er det naturligvis en stor fordel - men problemet er at opnå dette. Det er svært at beskæftige et stort antal ALU'er effektivt - det er derimod muligt, hvis de "trådes op", incl. dependencies.

  • 0
  • 0

Naturligvis tager det længere tid at udføre de n indstruktioner, hvis noget tager dobbelt så lang tid (og så vil out of order være godt, hvis det kan bringe tiden ned til det halve), men har vi et stort antal ALU'er, viser det sig at dybden alligevel er lav. Måske tager det 10 gange så lang tid - men der udføres 100 gange så mange indstruktioner. Out of order, kan måske bringe det ned til 9 gange så lang tid, for 100 indstruktioner. Desto mere intelligent, at out of order er, desto bedre effektivitet opnås, og det mest effektive er at 100 indstruktioner af 100 CPU'er udføres på éen indstruktions tid. Problemet er at optmere bedst muligt til det. Og det tror jeg, er nemmest at gøre i software - specielt hvis der tages hensyn til problemer som pris, chipareal, og strømforbruget. Optimeres af en in-time compiler, eller i software - så er den scheduleringen regnet ud på forhånd, eller opdelt i flere tråde, som kan kommunikere og udføres uafhængigt.

  • 0
  • 0

Apple har taget skridtet og foreslået blocks at deres nye block udvidelse af C bliver implementeret specifikationen. Smart, fordi blocks bruges af Apple's nyligt open-sourced Grand Central Dispatch.

GCD komibineres med den ny LLVM teknologi i Clang compileren der skulle boote højniveau sprog markant i ydelse.

  • 0
  • 0

Bare for at påpege det indlysende, så har Intel tidligere ejet ARM, hvis CPU'er de solgte under XScale navnet. Når de frasælger firmaet, må det være fordi de ved noget vi andre ikke ved.
Intels Atom CPU'er arbejder in-order ligesom Itanium. Resten arbejder Out-of-order (OOO). Intels OOO er den mest effektive pt. pga. "memory-disambiguation", der tillader tidlig hentning af data til instruktionerne i OOO køen. Man har derfor også øget størrelsen af reorder-buffer fra 96 til 128 fra Core2 til i7 for bedre at udnytte teknologien. Pga. denne teknologi har intel været i stand til at matche AMD på ydeevnen på trods af front-side-bus flaskehalsen. Fra Pentium4 til Core2 faldt loaded latenstiden på RAM fra ca. 120 til 90ns med samme motherboard! (Ja, fysisk samme).
Idéen med at bruge et stort antal CPU-kerner i stedet kendes jo fra Nvidia og ATI's skærmkort, der kan accelerere visse former for kode.
Med Larrabee prøver intel at bibringe skærmkortene en simplere programmeringsmodel og binær-kompatibilitet. Både til brug for grafik og general-purpose programmering. Det er sågar planlagt, at Larrabee skal indbygges i cpu'en på et senere tidspunkt.

  • 0
  • 0

Man har derfor også øget størrelsen af reorder-buffer fra 96 til 128

Problemet er at alle disse hundkunster tager bunker af siliciumplads. Og den kunne være brugt på 128 processorkerner i stedet. Nu udføres 128 indstruktioner, ved at finde dem der kan udføres samtidigt, og sætte til et mindre antal ALU'er. Imidlertid fylder 128 ALU'er ikke meget, når de er uden co-processoren, og kun udfører assembler indstruktioner. Data vil forwardes direkte imellem dem, og der er ikke latche og flipflops mellem indstruktionerne. Alene det gør, at selv med dependencies, så går det 3-5 gange så hurtigt. Data vandrer fra den ene ALU til den næste, ligeså hurtigt som data flyder igennem invertere. Det betyder, at trods der er afhængigheder, så tager det ikke lang tid at udføre 128 indstruktioner i et huk. Udover selve flow er langt hurtigere ved dependencies, så kommer dertil statistik der gør at de binære afhængigheder er færre. Og ialt, vil 128 indstruktioner, kunne udføres på kun lidt ekstra tid, i gennemsnit 3 gange éen indstruktions tid (eller hvor mange der udføres samtidigt).

Det spændende er også, at mange ALU'er scalerer godt - afhængighederne bliver ikke væsentligt dybere, meddens at udførselshastigheden vokser med antal ALU'er. Det største problem i sidste ende, er dermed index opslag i ram, baseret på et indexberegninger. Dette kan løses ved at udfører index beregningerne i god tid, men det kræves nogen schedulering, der dog kan gøres i software, og i CPU emuleringssoftware.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten