CPU utviklingen siste 5 år

[Anders Jensen]

Har lagd en aldri så liten graf som viser (i allefall litt av) hvordan CPU utviklingen siste 5 1/4 år har vært.

 

http://www.hw64.com/images/SPECintLog.PNG

 

Mulig noen finner den litt vanskelig å lese da den har logaritmisk y-akse. Jeg skal komme tilbake med kommentarer til grafen, hvorfor akkurat denne benchmarken er brukt og kanskje en versjon med lineær y-akse om interessen er der. Nå er det imidlertid helg og jeg har ikke fått feiret slutten på eksamensperioden ennå, en hel uke på etterskudd... Altså neppe noe før _sent_ i morgen.

[el-asso]

Artig med noe å kose seg med til morgenkaffen Ser fram til videre kommentarer.

Går ut fra at Peak og ikke Base er brukt for at ikke kompilatoren skal være hinderet for å få fram cpu ytelsen.

[Åsmund@ATi]

hehe, artig!

Ja, jeg husker min P4 @ 2.53 hehe, det var tider,,, eller vis vi går tilbake til 98..fks..

[endrebjo]

Den rosa er Moores lov og den blå/lilla er topp CPU-ytelse i det året?

[el-asso]

Den rosa er Moores lov og den blå/lilla er topp CPU-ytelse i det året?

En kan vel se den som en ideallinje for SPEC-int basert på ytelsesøkning tilsvarende Moore's "lov". Utgangspunktet er 4.kvartal 99, og en med en dobling 2.hvert år får vi:

4.kvartal 99 = 444

4.kvartal 01 = 888

4.kvartal 03 = 1776

4.kvartal 05 = 3552 (hvilket ikke kommer til å nås)

 

Utviklingen har altså gått paralellt med ideallinjen fram til 2004 for så å avta og stoppe opp.

Endret 12. juni 2005 av el-asso

[RiFkinD]

hehe, artig!

Ja, jeg husker min P4 @ 2.53 hehe, det var tider,,, eller vis vi går tilbake til 98..fks..

ikke mobb den æ lev enda på den

[Malvado]

Ganske informativ og interesann liten graph!

 

A.J tror du det vil bli større sprik nå mellom graphene med dual core eller ser vi mot en tilnærmelse mot den øvre linjen?

Endret 12. juni 2005 av Malvado

[endrebjo]

Er SPEC-int skrevet for SMT/SMP, eller tar den bare i bruk én kjerne/prosessor?

[Anders Jensen]

OK da skulle det være sent nok på søndagskvelden. Må si jeg fortsatt mangler litt på å være helt i vater. Nok om det.

 

http://www.hw64.com/images/SPECint.PNG

 

Vel her er samme grafen men med lineær y-akse. Det hele ser litt mer dramatisk ut med tanke på hvor mye en nå ligger etter den tenkte doblingstrenden. (merk: grafen med logaritmisk y-akse gir det riktigste bildet av trenden. Med lineær y-akse blir de siste resultatene for dominante i grafen pga den store forskjellen i verdiene.) Den rosa grafen som viser denne doblingstrenden er egentlig ikke Moores lov, men den er veldig nært knyttet til den. Moores lov sier at vi har en dobling av antall transistorer på en chip over en gitt periode. f. eks 18 eller 24 måneder. Det er imidlertid ikke alltid at flere og raskere transistorer medfører samme økning i ytelse.

 

Den blå grafen viser det beste resultatet som er postet hvert kvartal på spec.org for SPECint2000 peak. Grunnen til at nettopp denne benchmarken er valgt, foruten at det er svært mange resultater tilgjengelig, er at den representerer hva en kan sammenligne med 100 meter sprint i et friidretts VM. Det er liksom klassikeren. SPECint er en samling av programmer som er svært CPU-intensive og de benytter ingen eller minimalt med flyttalls ressurser i CPU. Programmene er heller ikke flertrådede så de kan ikke dra nytte av SMT (f. eks HyperThreading) eller SMP (f. eks dual core). Det som også er litt morsomt med slike "integer programmer" generelt er at (general purpose) CPU ser ut til å være den absolutt beste løsningen for å få best mulig ytelse. Det er etter min mening litt unyttig å teste hvor kjapt en CPU kan gjøre en jobb som f. eks en GPU kan gjøre mange ganger kjappere. Det er de intrikate kombinasjonene av branch instruksjoner som gjør at spesialisert hardware ikke fungerer godt til dette.

 

Peak ble valgt fremfor Base fordi jeg ønsker å eliminere kompilator-uferdigheter mest mulig. Det er fullt mulig å lage kompilatorer som selv tester alle kombinasjoner av kompilator flagg slik at en slipper å sette flaggene selv, men av praktiske årsaker (lang kompileringstid blandt annet) gjør en ikke dette. Base resultatene krever at alle delprogrammene i SPEC testen er kompilert med samme sett av kompilator flagg. Altså egentlig en test av hvor god kompilatoren er til å finne de beste løsningene selv på et bredt spekter av programmer. Det begynner nå å bli vanlig med kompilatorer som bruker en profilering av koden til å gjøre den endelige kompileringen. Da faller hele poenget med Base resultatene bort fordi de blir eksakt lik Peak resultatene.

 

Med overgang til dual core vil vi nok se en ytterligere negativ trend til å begynne med, men etter noen generasjoner med CMOS prosess vil heller ikke dual core være nevneverdig effektbegrenset og den negative trenden forårsaket av overgangen til dual core vil ikke lengre være der. Den totale throughput for en dual core chip er imidlertid mye høyere, men det er ikke alltid relevant.

Endret 12. juni 2005 av Anders Jensen

[Simen1]

Takk for den meget illustrerende grafen. Noe lignende ble tatt opp for drøyt ett år siden, men den gangen med litt annen vinkling: MHz gjennom tidene, og kun CPU'er fra Intel og AMD. En forlengelse av grafen frem til i dag ville garantert vist poenget mye tydligere. Mulig jeg finner frem den gamle fila, forlenger grafen og poster det i en ny tråd eller i denne tråden.

 

Det hadde vært veldig interresant å sett utviklingen av mer velkjente typer benchmarks (velkjente for forumgjengere flest) fremstillt på samme måten. Kanskje også snevret ned til kun x86.

Endret 13. juni 2005 av Simen1

[Anders Jensen]

Hm den hadde jeg ikke sett før. Må ha hatt en pause på det tidspunktet. Husker det var en graf med SuperPi resultater også, men den var vel plottet mot frekvens og ikke lanseringstidspunkt om jeg husker riktig.

 

Hadde nok vært interessant med en benchmark som var mer kjent for publikum på denne siden, men det skal vel godt gjøres å finne en CPU intensiv benchmark som er bedre egnet enn SPECint. Det er jo bare en helt vanlig samling med typisk workstation programmer fra litt før år 2000. Hovedforskjellen på disse programmene og de testene vi ser mest av på typipske hardware sider er at SPEC testene kommer som kildekode og må derfor kompileres av testeren. Det setter jo visse kompetansekrav til testeren både med tanke på utførelse og tolking av resultatene.

 

Ellers er jo x86 så godt representert i grafen at en kan jo nesten se bort fra de andre men det spørs om ikke denne ytelsestronen går over til IA64 om ikke lenge. Og folk har behov for å få opp øynene og se at verden er litt bredere enn x86, bokstavelig talt. Jeg håper Steve Jobs er med på de notene...

[endrebjo]

...

Programmene er heller ikke flertrådede så de kan ikke dra nytte av SMT (f. eks HyperThreading) eller SMP (f. eks dual core).

...

Det er kanskje litt dumt å bruke slike programmer siden ytelsen i fremtiden er svæært avhengig av SMP.

[Simen1]

Det er kanskje litt dumt å bruke slike programmer siden ytelsen i fremtiden er svæært avhengig av SMP.

Enkelte oppgaver er rett og slett ikke parallelliserbare. Uansett hvem som lager programmet eller hva det heter. Det kommer f.eks av såkalt "nøstet" avhengighet.

[Anders Jensen]

...

Programmene er heller ikke flertrådede så de kan ikke dra nytte av SMT (f. eks HyperThreading) eller SMP (f. eks dual core).

...

Det er kanskje litt dumt å bruke slike programmer siden ytelsen i fremtiden er svæært avhengig av SMP.

Vel både ja og nei. Noen programmer kjører tregere på to tråder enn på en tråd fordi du må bruke så mye synkronisering av trådene og har ekstra overhead i koden pga flertrådingen at en kommer ut negativt. Det er også begrensninger på hva slags algoritmer en kan benytte på flertrådede operasjoner. På den andre siden er det jo riktig at SMP og SMT er fremtiden, men dette er strengt tatt et nødvendig onde.

 

Jeg tviler f.eks på at et dual P3 800MHz system vil være mer responsivt enn et Dothan 1600MHz system. Det hadde vært morsomt om en kunne fått til å måle det. Gjør nå en antagelse om at Dothan har samme IPC som P3 for å kunne bruke frekvens som mål her.

[Del]

Og folk har behov for å få opp øynene og se at verden er litt bredere enn x86, bokstavelig talt. Jeg håper Steve Jobs er med på de notene...

Virker ikke slik:

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2439

 

Ellers så virker det jo som om store ting er på gang med Cell, skjønt ideene der (med mange ALU'er) er ikke helt nytt. Du kan jo sjekke ut dette:

http://www.clearspeed.com/

Teoretiske flops er dog ingen garanti for reell ytelse, de forsøkene som har vært gjort på å bruke GPU'er til annet enn grafikk har ikke akkurat tatt av.

[Anders Jensen]

Cell på desktop er en selverklert katastrofe. Det er feil type regnekraft på feil sted. Masse SP FP og en rimelig smal in-order general purpose CPU. Er som å lage webserver av en haug Ati radeon brikker. Bra på papiret for de som ikke aner hva de leser.

 

Ellers blir det helt sikkert x86 og ikke IA64 i Mac, men det er jo lov å håpe på støtte for IA64 med tid og stunder også. Steve har en tendens til å hoppe på det som til en hver tid er best og gir rimelig blanke i bakoverkompatibilitet. IA64 vil utvilsomt være godt egnet for Power Mac ved 90nm og 65nm. Du vil neppe finne noen CPU som slår IA64 i både int og FP ytelse på de prosessnodene. Det gjør du faktisk ikke på 130nm heller...

[Del]

SPEC testene er anerkjente benchmarker som er ment som beslutningsstøtte for innkjøp ved IT avdelinger, så jeg støtter Anders fullt ut når han bruker int testen. For de på forumet som ikke er kjent med disse testene kan det være litt forvirrende å gå inn på spec.org, siden det sjelden står hva som er inni maskinene som blir listet opp. Det er en som tok jobben med å finne ut av det i fjor:

http://forum.pcvsconsole.com/viewthread.php?tid=11606

selv om denne ikke er helt up-to-date, gir listen en god pekepinn. Legg spesielt merke til hvor godt Itanium2 og Power5 yter på flyttall, det er dette de er skreddersydd for, typisk HPC.

 

Arkitekturen til Itanium2 (IA64) har blitt lovprist av mange, og representerer (bl.a.) en videreutvikling av SMT (markedsført som hyper threading) som vi finner i P4, kalt super hyper threading, hvor målet er å utnytte ILP (instruction level parallelism) optimalt (m.a.o. sørg for at CPU'en utfører maksimalt med instruksjoner hver klokkesyklus). For å oppnå dette har man gjort flere fremskritt, bl.a. med registrene og håndteringen av disse. Selv om AMD ikke har SMT betyr ikke det at en AMD CPU kun kan utføre en instruksjon pr. klokkesyklus. Alle moderne CPU'er er såkalt super skalare (samme gjelder trivielt for vektoriserte), d.v.s. kan utføre flere instruksjoner pr. syklus, men kun på en tråd I en A64. Ved å bruke flere tråder er ideen å "fylle opp" kapasiteten til CPU'en bedre, det er vel denne problematikken Anders referer til med synkronisering?

 

Dette var teorien, som nevnt posten over er praksis ikke alltid det samme. Mye av tiden en prosessor "svir" av skyldes cache miss, d.v.s. at dataene CPU'en trenger ikke er å finne i cache, så de må hentes fra minnebrikken, det tar en hel masse klokkesykluser (ideellt sett skal jo da CPU'en jobbe med andre ting, men det er ikke alltid like lett å få til i praksis). Hvor mye cache miss en får avhenger både av problemet, og hvor godt optimalisert det er, men selvfølgelig også av størrelsen på cache. Top linje Itanium2 har 9MB cache, og den er svindyr. Dual kjerne Power5 har svimlende 36MB L3 cache, og er heller ikke på billigsalg. Så da kan man jo spørre seg om det er den fantastiske arkitekturen som gjør at de får ca. 50% ytelsesøkning i FP sammenlignet med P4 eller A64.

[snorreh]

Meget interessant, men det hadde vært mer interessant å sett på utviklingen mhp. pris/ytelse/watt for prosessorer de siste årene. Nå som maskinvare er omtrent gratis i forhold til 5 år siden så ligger utfordringen for å oppnå høyere ytelse i bedre programvare og da er f.eks. disse SPEC-testene sånn sett rimelig utdaterte på det aller meste.

Endret 3. juli 2005 av snorreh

[Edmund Blackadder]

Husker for maangemange år siden at min far hadde en pc på kontoret sitt og den pcen var regnet som en ganske god pc. Og da var prosessoren på 13 MHz!!!

[Simen1]

Godt poeng Del. Mulig parallelliseringsgrad vil slevfølgelig være svært varierende fra oppgave til oppgave. Det er godt å høre at det er utvikling på programvarenivå mot mer parallellisering, men det er kanskje ikke noen bombe.

 

Det kan vel kanskje sammenlignes litt med å doble transferrate på harddisker uten å endre aksesstiden. En del oppgaver vil få dobbel ytelse mens andre ikke vil få noe mer ytelse. Hver enkelt applikasjon vil utvikles til å bruke disken mer sekvensiellt så ytelsen kan følge transferrate bedre. Men ikke alle applikasjoner kan legges sekvensiellt. F.eks en database på 100GB med 1kB entries. Jo mer programvare som blir laget med sekvensiell aksess jo bedre, men for hver dobling av transferrate så vil det bli færre og færre applikasjoner som er begrenset av transferrate og flere og flere som er begrenset av aksess. Etter hvert går vinninga opp i spinninga (diminishing returns).

 

Men for å rette litt på det jeg sa tidligere: På kort sikt (0-5 år) ser jeg på 2 kjerner som det optimale. Om 5-10 år kan sikkert 4-8 kjerner være på sin plass selv for vanlige brukere. Eller som jeg ser mer for meg: Flere typer kjerner med hver sine styrker samlet på en brikke. Omentrent som Cell er i dag, men sikkert med en forskjellig fordeling av antall kjerner/SPUer, størrelse og oppgaver på hver kjerne osv.

 

Dette minner meg litt om menneskekroppen: Vi har mange forskjellige organer spesialisert på sine oppgaver. Til sammen er organene en organisme som er svært fleksibel og kan gjøre veldig mye. En smart sammensetning av mange typer spesialiserte kjerner vil sikkert kunne gi en glimrende samlet prosessor.

 

</filosofen tar seg en pause >