"Montecito" får 1,7 milliarder transitorer

[snorreh]

"Intel's compilers have also improved vastly over the past years, which is positive. However, they have also become better in using special tricks (strip-mining optimizations, for example) to artificially improve the Spec score; tricks that are not usable by developers who need to get real applications to the market."

 

Leste senest i dag det her hos anand , men som sagt er ikke så veldig inne i det. Men får intrykket at det ikke ligger så nærme den reelle ytelsen. (men man kan jo kanskje argumentere for at de samme triksene også brukes av andre, dermed blir det likt?)

Det blir ikke likt siden Itanium er helt avhengig av tweaking av kompilatorer for i det hele tatt yte brukbart på slike benchmarks. I tillegg til blodtrimmede kompilatorer så påvirker cache-størrelsen på prosessoren også resultatene fra SPEC-testene i en stor grad, såpass at mange mener de er tilnærmet ubrukelig som en indikator på reell ytelse (ref. den store forskjellen i ytelse på likt klokkede Itanium, men med forskjellig cache-størrelse).

[Mr Anders]

"This year the decision came down to AMD’s dual-core

Opteron, IBM’s Power5, Intel’s Montecito, and Sun’s Niagara

processors. All are multicore processors, and all but Opteron

support multithreading. Power5 is the most proven at this

time, as it shipped in systems in 2004, whereas Opteron,

Montecito, and Niagara are still in early sample stages."

 

"(...)Intel Montecito processor is the winner of our MPR

Analysts’Choice Award for Best Server Processor of 2004."

 

http://h21007.www2.hp.com/dspp/files/unpro...-Itanium105.pdf

 

Ikke veldig overraskende konklusjon sett fra min side. Dette er den CPU'en som vil få best ytelse på de fleste systemer, selv om Power5+ antagelig kommer til å ta over ledelsen i Online Transaction Processing etter hvert og Niagara kanskje vil ta ytelsestronen i en del webserverbenchmarks.

 

kk i eksil

Endret 13. februar 2005 av Mr Anders

[Boralis]

[el-asso]

En kar på RWT har fordelingen av transistorene:

 

Core logic - 57M

Core caches - 106.5M

L3 cache - 1550M

Bus Logic & I/O - 6.7M

Total: 1.72B

[Mr Anders]

En kar på RWT har fordelingen av transistorene:

 

Core logic - 57M

Core caches - 106.5M

L3 cache - 1550M

Bus Logic & I/O - 6.7M

Total: 1.72B

Helt ekstremt hvor effektivt de core transistorene er brukt. Hvor mange transistorer er det i kjernelogikken til Dothan? kan ikke være langt unna de 28.5M som er i en Montecito kjerne, men flyttalls ytelsen vil jo ikke komme i nærheten. Det vil neppe noen annen form for ytelse heller gjøre. Med 50W per kjerne er ikke steget ned til Dothans 21W / 27W veldig langt heller. LV versjonene kommer vel til å havne i det området.

 

Ellers kommer vel AMD fansen til å få vann på mølla når de etterhvert forstår hva 100W for Montecito egentlig betyr. De mer detaljerte slidene er vel ikke offentliggjort ennå...

 

For å si det sånn... en 100W Montecito vil nok sluke minst like mye effekt som en 122W Madison gjør fordi en 122W Madison kommer svært skjelden i nærheten av de 122W den er ratet for, mens Montecito vil ligge å vippe rundt 100W nokså kontinuerlig. Kan faktisk gå litt over i korte tidsinterval som et resultat av tilbakekoplet regulering, men den henter det inn igjen rett etterpå.

Endret 15. februar 2005 av Mr Anders

[snorreh]

Jeg synes det er mildt sagt litt tvilsomt at en prosessor som ennå ikke er i salg (og som kanskje ikke kommer i år engang), og som derfor ikke har blitt testet på noen som helst måte kan vinne en slik tjener-pris. Hvis det er en pris Intel fortjener for Montecito så må det være "CPU Hype Award of the Year" for både 2003, 2004 og 2005. Snakker om hakk i plata!

 

En kar på RWT har fordelingen av transistorene:

 

Core logic - 57M

Core caches - 106.5M

L3 cache - 1550M

Bus Logic & I/O - 6.7M

Total: 1.72B

Interessante tall, og viser at Montecito egentlig er cache med prosessor istedenfor prosessor med cache. 1656 millioner transistorer bare til cache er helt hinsides etter min mening, men det er nok eneste nødløsning for å få brukbar ytelse på en prosessor som tross alt benytter en antikvarisk FSB. Athlon 64 med 640KB cache, integrert dual-channel minnekontroller og integrert HyperTransport-nordside trenger totalt bare 68.5 millioner transistorer til sammenligning. Gjett hvilken løsning som gir best pris/watt/ytelse?

 

En morsom tanke; Mens AMD integrerer minnekontrolleren på prosessorene sine så integrerer Intel istedet minne (gigantisk cache) direkte på prosessorene sine

Endret 16. februar 2005 av snorreh

[Boralis]

He he , til tross for at denne er kåret til beste serverprosessor så klarer du å finne feiler og mangler, bra vi har noen som overgår ekspertene og sier hvordan tingene er

Endret 15. februar 2005 av Snekker`n

[Mr Anders]

He he , til tross for at denne er kåret til beste serverprosessor så klarer du å finne feiler og mangler, bra vi har noen som overgår ekspertene og sier hvordan tingene er

Denne tråden begynner vel å forklare signaturen min rimelig selvstendig... Jeg lurer på om Opteron 8xx kan måle seg mot Celeron M på pris/watt/ytelse i et system som nødvendigvis bare kan passe sistnevnte? Hvis Opteron ikke kan klare det så må det jo være en møkka CPU. Jeg kan ikke forstå annet enn at virkeligheten må være så enkel! (ok dette er ironi for de som sliter med slikt...eller virkeligheten..?)

 

oooh post nummer 100.. jeje særlig..

Endret 15. februar 2005 av Mr Anders

[snorreh]

Flere detaljer om "Montecito" her:

http://babelfish.altavista.com/babelfish/t...f11%2fisscc2%2f

 

Det mest imponerende med denne prosessoren er reduksjonen i strømforbruket takket være Foxton:

 

 

Såvidt jeg kan forstå så er Foxton noe a'la Intel Enhanced SpeedStep/AMD PowerNow (Cool'n'Quiet), bare at det styres 100% via prosessoren i maskinvare og ikke via programvare slik de andre jeg har nevnt (?).

 

 

Prosessorkjernene benytter altså totalt 80-81W, mens den gigantiske 24MB cachen benytter bare 5W (!), FSB'en bruker 8W og resten bruker 6W. Det lave strømforbruket til cachen er meget imponerende, så det blir spennende å se om vi får se Foxton også på desktopen etterhvert. Her har iallefall AMD endel å lære av Intel, ingen tvil om det.

Endret 16. februar 2005 av snorreh

[el-asso]

Men hva (pokker) er en "Power Envelope" ?

[Dollar]

Men hva (pokker) er en "Power Envelope" ?

Løst oversatt "ønsket ramme" i denne sammenheng.

[Mr Anders]

Men hva (pokker) er en "Power Envelope" ?

En grense. Altså en grense for effektforbruk som prosessoren skal operere innenfor. Som Dollar oversetter det "ønsket ramme" er ikke så dumt i denne sammenhengen heller. Det er ikke en absolutt grense, men en tilstreber å ligge innenfor mesteparten av tiden.

 

Montecito måtte ha hatt en power envelope på ca 150W om den ikke hadde Foxton, eventuelt måtte den ha lavere frekvens. Med Foxton kan prosessoren justere spenningen som igjen medfører at frekvensen økes slik det er implementert i Montecito. Det hele styres av en egen CPU som kontinuerlig leser av temperaturmålere og amperemeter. Hvis denne styrings CPUen kalkulerer at effektforbruket er lavere enn 100W så kan den øke spenningen slik at effektforbruket stiger opp til 100W. Dette gir også en økt klokkefrekvens. Hvis belastningen av CPU så øker (økt CPU utilization) så vil effektforbruket stige over 100W og styrings CPUen må justere ned spenningen (som igjen drar ned klokkefrekvensen) slik at effektforbruket kommer inn under 100W igjen. Dette skjer svært fort. Tror det er snakk om rundt 1000 justeringer i sekundet. Med DBS (Demand Based Switching) kan power envelope justeres ned til et lavere nivå enn 100W vha. software.

 

Foxton vil neppe hjelpe like mye på andre smalere CPU arkitekturer enn de IPF arkitekturene vi har i dag da disse har jevnere CPU utilization enn brede design, men noe vil det hjelpe.

 

L3 cache på Montecito er forøvrig et asynkront design. Det gjør at de får ned effektforbruket og forsinkelsen. Forsinkelsen på de 12MB store L3 cache modulene er bare 14 sykluser. Hadde det vært vanlig synkront design hadde antagelig forsinkelsen vært omtrent 17 sykluser. 14 sykluser er forøvrig hva Madison 9M har på sin L3 cache i dag.

 

Om noen år vil vi kanskje se de første asynkrone CPUene til bruk i servere og arbeidsstasjoner om det ikke blir for vanskelig å designe. Da blir i alle fall frekvens kappløpet avsluttet en gang for alle. Asynkrone design har ingen klokke, men for å sitere en SUN Labs presentasjon: It's hell to design.

 

Å utvikle asynkrone OOO prosessorer er ikke noe jeg ville satt i gang med. IPF derimot med sit relativt sett enkle kjernedesign er godt egnet.

Endret 16. februar 2005 av Mr Anders

[el-asso]

Mye å lære her skjønner jeg

Hvis denne styrings CPUen kalkulerer at effektforbruket er lavere enn 100W så kan den øke spenningen slik at effektforbruket stiger opp til 100W. Dette gir også en økt klokkefrekvens. Hvis belastningen av CPU så øker (økt CPU utilization) så vil effektforbruket stige over 100W og styrings CPUen må justere ned spenningen (som igjen drar ned klokkefrekvensen) slik at effektforbruket kommer inn under 100W igjen

Hvilket betyr at klokkefrekvensen går ned når det er mest bruk for den

[Mr Anders]

Mye å lære her skjønner jeg 

Hvis denne styrings CPUen kalkulerer at effektforbruket er lavere enn 100W så kan den øke spenningen slik at effektforbruket stiger opp til 100W. Dette gir også en økt klokkefrekvens. Hvis belastningen av CPU så øker (økt CPU utilization) så vil effektforbruket stige over 100W og styrings CPUen må justere ned spenningen (som igjen drar ned klokkefrekvensen) slik at effektforbruket kommer inn under 100W igjen

Hvilket betyr at klokkefrekvensen går ned når det er mest bruk for den

I noen tilfeller kan det bety det. Det er ikke til å unngå. Alternativet (som er hva vi har i dag) er at CPU er designet for worst case slik at den kun opererer på den frekvensen den tåler å kjøre et power virus.

 

CPU utilization i dette tilfellet må ikke sammenblandes med den grafen du ser i task manager. Ta f. eks et rent integer program, da ligger FPU helt død og drar nesten ikke noe effekt. I denne sammenhengen vil en da si at CPU utilization _ikke_ er 100% selv om hver eneste syklus er fylt opp med instruksjoner. Skal du ha 100% CPU utilization (altså max effektforbruk) så må du bruke så mange execution units som mulig på hver eneste klokkesyklus. Det er i alle fall en grei tilnærming for enkle VLIW og EPIC prosessorer. For de mer kompliserte OOO prosessorene er det verre å kallkulere da bare en liten del av effektforbruket i disse svis av i execution units (mye overhead med andre ord). Scheduling og spekulering tar f. eks masse effekt.

 

Et vanlig scenario er at CPU f. eks står i en database server og vil ikke komme over 60% belastning selv om systemet kjører på 100% belastning. Ofte er det ping-pong aktivitet mellom CPU og minne eller CPU og I/O der CPU jobber litt for så å vente en haug med sykluser på data. I slike tilfeller vil en tjene en del på Foxton da CPU kan svare raskere fordi den kjører på langt høyere frekvens en hva den kan kjøre et power virus eller LINPACK uten å overopphete.

 

Hovedpoenget er at en slipper å designe for worst case. Det hadde sikkert gått greit å slippe Montecito på 2.2GHz uten Foxton fra starten av helt til noen fant på at de skulle kjøre et power virus eller LINPACK som også er et program med høyt effektforbruk. Typisk opp i 80% av max tror jeg kommer veldig an på disse matrisestørrelsene, men når en måler max FLOPS så er en naturlig nok i nærheten av det maksimale mange CPUer kan forbruke av effekt.

 

EDIT:

Jeg har fått inntrykk av at Montecito vil bli lansert på 2GHz og at dette er den frekvensen prosessoren garantert kan kjøre en hvilken som helst kode (power virus inkludert). Med Foxton vil den imidlertid kunne øke frekvensen opp til 2.2GHz eller så, men bare så lenge den ikke går over 100W. I praksis vil det si at programmer som ligner på SPECint antagelig vil kjøre på høyere CPU klokke enn programmer som ligner på LINPACK i bruk av CPU. Det kan jo bli en interessant variabel i ymse benchmarks...

Endret 16. februar 2005 av Mr Anders

[Mr Anders]

Denne oppsummerer Montecito veldig grundig:

http://www.encompassus.org/images/pdfs/montecito.pdf

[el-asso]

CPU utilization i dette tilfellet må ikke sammenblandes med den grafen du ser i task manager. Ta f. eks et rent integer program, da ligger FPU helt død og drar nesten ikke noe effekt. I denne sammenhengen vil en da si at CPU utilization _ikke_ er 100% selv om hver eneste syklus er fylt opp med instruksjoner. Skal du ha 100% CPU utilization (altså max effektforbruk) så må du bruke så mange execution units som mulig på hver eneste klokkesyklus. Det er i alle fall en grei tilnærming for enkle VLIW og EPIC prosessorer. For de mer kompliserte OOO prosessorene er det verre å kallkulere da bare en liten del av effektforbruket i disse svis av i execution units (mye overhead med andre ord). Scheduling og spekulering tar f. eks masse effekt.

 

En måte å se dette på er vel at en EPIC prosessor som Itanium har en mer effektiv utnyttelse av execution core enn en x86, siden den "løser" branches ved parallelisering og dermed jamt over har flere execution units i bruk.

(Nå kan jo også si at en effektiv utnyttelse av execution core og en effektiv execution core være to forskjellige ting)

 

Nå skjønner jeg riktignok ikke hvorfor du setter VLIW og EPIC i samme bås siden sistnevnte bruker fast instruksjonslengde og dermed skulle trenge mindre jallamikk for å instruksjonene fram til execute ?

[Mr Anders]

Det er vel ingenting som behøver mindre "jallamikk" enn en VLIW... EPIC er akkurat som VLIW bare at du må bruke litt ekstra ressurser og tid for å tilordne dynamisk mellom instructionslots og fysiske ressurser. Det er jo det som gjør EPIC så utrolig mye mer dynamisk enn VLIW og attpåtil reduserer code bloat en hel haug.

 

Edit: ser at det jeg refererte til som CPU utilization i effektforbruk sammenheng er blitt døpt "Activity Factor" av Intel. Det er jo greit å ikke bruke de samme begrepene om forskjellige ting tenker jeg..

Endret 16. februar 2005 av Mr Anders

[snorreh]

Men hva (pokker) er en "Power Envelope" ?

Det er et tak for hvor mye strøm prosessoren skal bruke og i denne sammenhengen er det altså 100W, se også vedlagt bilde hentet fra presentasjonen i "Knick Knack" sin link.

[Boralis]

Mr Anders, takk for meget god informasjon om dette , veldig lærerikt for mange av oss. Stå på

[cyberklad]

Jeg tenker at om du går til de som selger en itanium sever og sier at du vil ha en så tenker dem nok ikke så stort på om du representerer deg selv eller en bedrift. de er nok bare glade for og få solgt saken