Lite firekjernesalg før neste høst

[Simen1]

Quintero: Jeg skjønner heller ikke hvorfor AMD økte L2 latencyen så mye. Hvis den var en viktig faktor som begrenset hastigheter så hadde de ikke trengt å øke den så mye når de ikke skal pumpe opp klokkehastighetene noe voldsomt. Med den latencyen ser det ut som de sikter seg inn på 70% høyere klokkehastigheter (rundt 3,5 - 5 GHz), noe de ikke har gitt signaler om på noen annen måte. Hverken for K8 65nm eller etterfølgeren K8L på 65nm. (Men det er jo lov å håpe )

 

Det høres rett og slett ut som de måtte kutte noen svinger for å klare å krympe L2 cachen til 65nm. AMD trenger virkelig raskere og tettere L2 cache-design. Intel mestrer jo dette til fingerspissene.

 

Angående innføringen av L3 så hadde jeg trodd at det ble mindre behov for så mye som 1MiB L2, men at L2-cachen gjerne kunne fått raskere latency. Jeg hadde sett for meg at L2 cachen skulle reduseres til 512KiB uten at latencyen ble rørt. Altså samme antall klokkesykluser men litt raskere på grunn av høyere klokkefrekvens.

[Simen1]

http://www.digi.no/php/art.php?id=362139

7553740[/snapback]

Dette blir muligens litt oppgulp av det Del sa, men jeg synes artikkelen var litt enkel, særlig når han forklarte amdahls lov og når han fortalte hvor dårlig og komplisert designet til Cell var.

 

Amdahls lov er komplisert, men litt forenklet sier den at jo flere kjerner, jo mindre prosentmessig reell ytelsesforbedring får man. Dette er fordi stadig mer ytelse spises opp av koordingeringen. Det er ikke løst på de fleste server-applikasjoner - der installerer man stort sett bare flere kopier av applikasjonen som går i parallell og fordeler brukere utover disse.

 

Det finnes ingen klar løsning i sikte.

 

- Forskere som driver med tungregning og dataklynger har forsket på skaleringsproblemet i 20-30 år uten noen signifikante gjennombrudd, forteller Microsoft-evangelisten.

Her tenker de nok på tradisjonell Xeon MP-arkitektur. Det finnes spennende måter å hjelpe på dette betydelig. Og flere metoder er på vei inn. Ulik programvare har utrolig forskjellige krav, eller måter de bruker maskinkrafta på. Dvs. at det finnes et vell av ulike måter å forbedre ytelsen på som vil gi hver sine programtyper et skikkelig dytt. En god del programvare som beregner relativt små (opp til ca 1GB) men kompliserte beregninger i en rekke iterasjoner kan f.eks ha enorm ytelsefordel av mer parallelle arkitekturer med god intern båndbredde. Jeg tenker selvfølgelig på GPU. F.eks ATIs R600 med enormt mange små og parallelle prosessorer, med en vanvittig god intern og ekstern båndbredde. Internt vil også latency være rimelig kjapp. For større problemer (2GiB+) så vil ikke GPU kunne tilby nok minne så der er det essensielt at det er CPU-systemer med god intern kommunikasjon. I klassen 1-4P er det ikke så nøye men, i større systemer er interconnect svært viktig. Det e ulike måter å løse dette på, noe går så det ryker etter på intels løsning med et felles minne i et slags nav og mange prosessorer rundt. Annen programvare foretrekker AMDs løsning med direkte kommunikasjon mellom en rekke sokler og lokalt minne på hver sokkel. Dette siste er avhengig av at programvaren oppfatter minnet som lokalt eller ikke lokalt slik at det slipper å ta unødvendige omveier i kommunikasjonen med minnet. Dette kalles NUMA og finnes implementert i Linux, Windows XP og Vista. Riktignok burde jeg satt XP i parantes siden støtten er svært dårlig der.

 

Problemet hittil har vært at vi ikke har kompilatorer som kan ta i bruk GPU når det trengs og CPU når det trengs. Ofte er ikke GPU tilgjengelig i systemet så slike kompilatorer har kun fungert på spesielle konfigurasjoner. Men det er lys i tunellen. Folding@Home har nå blitt portet til GPU. Det kjører 20-40 ganger kjappere på en moderne GPU enn på en moderne CPU. ATIs R600 vil nok bedre dette tallet betraktelig. AMDs "fusion" er en kombinasjon som har både GPU-egenskaper og CPU-egenskaper. Når kombinasjonen blir tilgjengelig i en god del av systemene som selges så vil det også bli flere kompilatorer som tar i bruk egenskapene og kan dirigere program til der de yter best. Vi kan ikke kvitte oss med CPU-kjerner for de har sine fordeler over GPU. Det er kombinerte brikker vi trenger for å "lure" amdahls lov i en del år. Cell var tidlig ute med å vise at slike kombinerte løsninger lar seg gjøre. En feit kjerne til tråder som liker det best, og 7-8 smale kjerner til en bunt med tråder som liker det best.

 

Pessimismen i artikkelen som ikke ser noen lys i tunellen deler jeg altså ikke.