Conroe kommer i juli

[Anders Jensen]

Core versus Hammer: Memory subsystem

Core's most important competitor, the Hammer ("K8") architecture, has two small but noteworthy advantages. The first is its bigger 2 x 64 KB L1 cache. This is only a small advantage as an 8-way 32 KB cache will have a hit rate close to that of a 2-way 64 KB cache.

 

The second and more important advantage is the on die memory controller, which lowers the latency to the memory considerably. However, the lower clockspeeds of the Core CPUs (relative to NetBurst) and the faster FSB also lower latency significantly. With the numbers available to us now, we have reason to believe that the Athlon 64 X2's latency advantage will shrink to only 15 to 20%. For comparison, the memory subsystem of the Pentium 4 was almost twice as slow as the Athlon 64 (80-90 ns versus 45-50 ns).

 

However, those two small advantages are likely negated by all the other memory subsystem metrics. The Core CPUs have much bigger caches and much smarter prefetching than the competition. The Core architecture's L1 cache delivers about twice as much bandwidth (Measured by ScienceMark), while it's L2-cache is about 2.5 times faster than the Athlon 64/Opteron one.

Angående den grønne teksten så skjønner jeg ikke helt hvorfor høyere klokkehastighet på FSB og lavere klokkehastighet på CPU skal senke latencyen til minnet. Greit nok at lavere klokkehastighet på CPU gir færre CPU-klokkesykluser før de forespurte dataene kommer tilbake, men det er jo ikke det samme som at latencyen målt i tid (ns) blir kortere. Er det noen som kan forklare disse to tingene?

6030854[/snapback]

Veldig bra spørsmål. For å ta økt FSB hastighet først. Dette reduserer unloaded latency ved at mange av syklusene som benyttes i minnehierarkiet blir kortet ned i lengde (målt i tid). For loaded latency vil en i tillegg dra nytte av at køer i minnehierarkiet blir kortere som en konsekvens av høyere throughput.

 

Når det gjelder påstanden om at lavere klokkede arkitekturer skulle senke forsinkelsen mot minnet på noen måte så er det jo logisk nok bare tull. Det som menes er at mengden klokkesykluser som går til spille er lavere. Dette er forsøvidt også en nokså tullete kommentar siden antallet klokkesykluser som går til spille ikke er den viktige faktoren derimot er antallet klokkesykluser som går til spille multiplisert med IPC av interesse. Siden lavere klokkede arkitekturer må ha høyere IPC for å kunne gi tilsvarende ytelse. Generelt gjelder det at jo høyere ytelse en kjerne har jo mer blir den belastet av forsinkelsen i minnehierarkiet. Om den oppnår høy ytelse ved høy IPC eller høy klokkefrekvens er ikke av særlig interesse.

 

Jeg påstår altså at Johan bare rabler når han drar inn kjernefrekvensen uansett hva han ønsker å mene at den skal bety for latency. Den eneste måten han kan ha rett på er at vi definerer IPC til å være uendret, men da er det plutselig ikke så smart å ha en lavere klokket arkitektur lengre...

[ATWindsor]

Angående den grønne teksten så skjønner jeg ikke helt hvorfor høyere klokkehastighet på FSB og lavere klokkehastighet på CPU skal senke latencyen til minnet. Greit nok at lavere klokkehastighet på CPU gir færre CPU-klokkesykluser før de forespurte dataene kommer tilbake, men det er jo ikke det samme som at latencyen målt i tid (ns) blir kortere. Er det noen som kan forklare disse to tingene?

 

Du svarer jo deg selv, de mener akkurat som du sier at latencyen på minnet målt i klokkesykluser er lavere.

 

Med 1066mhz fsb og 2666mhz prosessor så er forholdet mellom fsb og cpu ca 1:2,6. Med 800mhz fsb og 3800mhz prosessor er forholdet 0,8:3,8 - nesten dobbelt så ille.

 

AMDs K8 har det optimale forhold på 1:1 her, prosessoren og minnekontrolleren kommuniserer på samme hastighet.

 

Poenget er at istedetfor å vente 200 klokkesykluser hvor prosessoren ikke gjøre noe så venter conroe 100 klokkesykluser, en ganske drastisk nedgang i bortkastete klokkesykluser.

6032258[/snapback]

 

Det her er kasnkje et dumt spørsmål, men hvorfor er 1:1 optimalt, hadde det ikke feks vært bedre om fsb hadde vært 10 ganger raskere enn CPU? Hadde ikke det senket antallet klokkesykluser man må vente enda mindre?

 

EDIT: alstå om man ser bort i fra eventulle problemer med å få dette implmentert i praksis.

 

AtW

Endret 3. mai 2006 av ATWindsor

[Anders Jensen]

En ting jeg lurer på angående så brede kjerner som Core. Hvorfor ligger hver "kjerne" hver for seg på brikken? Hvorfor syr de ikke sammen de to kjernene til en kjempekjerne med delt L2, delt L1, delte dekodere, delte porter, delt ROB, delte execution units, osv? Arealmessig må det jo være det samme om kjernene ligger hver for seg eller om alle enhetene samles i en diger enormt bred pipeline som kan takle f.eks 8 instruksjoner per klokkesyklus og kjørt SMT (HyperThreading) for å fordele lasten fra to eller kanskje 3 tråder utover den brede arkitekturen?

 

Et slikt design ville gjort at hvis en tråd kan ha veldig høy ILP så kan den få møtt etterspørselen ved å bruke execution units som de andre trådene ville latt stå ubrukt?

6032149[/snapback]

Det du beskriver her er mye likt planlagte Alpha EV8. Den var 8-way superscalar og 4-way SMT. Altså på en måte 4 kjerner med sine separate registre som delte på 8 execution pipelines. Ideen høres jo veldig ideell ut men problemet her blir vel klokkefrekvens vs. watt. Ytelsen per tråd blir nok skuffende på slike oppsett fordi det ikke nytter å få så brede design til å kjøre på høye klokkefrekvenser. Det hele bunner vel i ineffektiviteten til Tomasulo algoritmen. Den sier at du skal ha en rekke tabeller som hver inneholder en og kun en instruksjon og alle nødvendige parametre som trengs for å kunne utføre denne instruksjonen. Parametrene kan være slikt som register verdier benyttet av instruksjonen og om disse er blitt oppdatert av alle instruksjoner som må være før denne i køen for å få riktig kjøring osv. I det heltatt en god del opplysninger om hver instruksjon og muligheten til å kunne kjøre den. Dermed kan en kjøre den så tidlig som mulig fremfor når programmet self definerer at den skal kjøre slik i en in order maskin. Problemet, slik jeg forstår det, er å fylle opp disse tabellene. Hver gang en instruksjon er ferdig så vil dette ha implikasjoner for en rekke andre instruksjoner, men det er opp til kjernen å finne ut hvilke. Hvis du da har 8 execution pipelines som hver klokkesyklus skal oppdatere x antall entries i x antall tabeller og si at du har 50 tabeller per tråd altså 200 totalt... det blir mye arbeid per syklus som igjen gir lange sykluser om en ikke er villig til å gni på godt med spenning.

 

Dette er årsaken til at OOO execution er dead end. Vi må tilbake til noe som er langt billigere å implementere HW messig enn OOO. Niagara, Cell, EPIC og EDGE har alle det til felles at de forsøker å oppnå god ytelse uten bruk af OOO nettopp fordi OOO ikke kan gi en bærekraftig utvikling på sikt.

[blackbrrd]

Det spiller ikke noen rolle om du har 100 biler og 10 filer på en motorvei eller om du har 10 biler og 100 filer, du får samme hva kun kjørt 10 biler av gangen.

 

Altså, hvis du har en flaskehals så har du en flaskehals...

 

Det som muligens hadde gått an å gjøre var å multiplexe/demultiplexe, da ville du kunne virtuelt hatt en 3ghz fsb på 256bit mens du i virkligheten har en 12ghz 64bit fsb. Da ville det lønnt seg å ha andre forhold enn 1:1.

[ATWindsor]

Det spiller ikke noen rolle om du har 100 biler og 10 filer på en motorvei eller om du har 10 biler og 100 filer, du får samme hva kun kjørt 10 biler av gangen.

 

Altså, hvis du har en flaskehals så har du en flaskehals...

 

Det som muligens hadde gått an å gjøre var å multiplexe/demultiplexe, da ville du kunne virtuelt hatt en 3ghz fsb på 256bit mens du i virkligheten har en 12ghz 64bit fsb. Da ville det lønnt seg å ha andre forhold enn 1:1.

6033963[/snapback]

 

Jeg skjønner ikke helt analogien din, kan du forklare det på en litt annen måte? Sånn jeg har forstått det, så blir antallet "uvirksomme" klokkesykluser man må vente flere jo tregere FSBen er i forhold til CPUen. Hvorfor lønner deg seg da ikke å feks ha en FSB som er dobbelt så rask som CPU (altså frekvens).

 

AtW

[Anders Jensen]

Angående den grønne teksten så skjønner jeg ikke helt hvorfor høyere klokkehastighet på FSB og lavere klokkehastighet på CPU skal senke latencyen til minnet. Greit nok at lavere klokkehastighet på CPU gir færre CPU-klokkesykluser før de forespurte dataene kommer tilbake, men det er jo ikke det samme som at latencyen målt i tid (ns) blir kortere. Er det noen som kan forklare disse to tingene?

 

Du svarer jo deg selv, de mener akkurat som du sier at latencyen på minnet målt i klokkesykluser er lavere.

 

Med 1066mhz fsb og 2666mhz prosessor så er forholdet mellom fsb og cpu ca 1:2,6. Med 800mhz fsb og 3800mhz prosessor er forholdet 0,8:3,8 - nesten dobbelt så ille.

 

AMDs K8 har det optimale forhold på 1:1 her, prosessoren og minnekontrolleren kommuniserer på samme hastighet.

 

Poenget er at istedetfor å vente 200 klokkesykluser hvor prosessoren ikke gjøre noe så venter conroe 100 klokkesykluser, en ganske drastisk nedgang i bortkastete klokkesykluser.

6032258[/snapback]

Kindercludge; "tre feil på en gang? Det kan da ikke være mulig?" jovisst.

 

*1066"MHz" FSB og 2666MHz kjerne gir et forhold på 1:2.5 ikke 1:2.6

*800"MHz" FSB og 3800MHz kjerne gir et forhold på 1:4.75 og ja dette er nesten dobbelt så ille* når vi får det hele normalisert til 1 og ikke X_whatever

*AMDs K8 har helt andre forhold i minnehierarkiet og påstå at de har et 1:1 forhold mellom kjerne og minnekontroller er jo greit nok, men hva så? Det er ikke der den viktige forskjellen mellom Intels og AMD minnehierarki er. Forskjellen er at det er et helt ledd (FSB linken) som mangler i AMD sitt hierarki sett i forhold til Intel sitt. Klokkefrekvensen til en minnekontroller er ikke mer indikasjon på ytelse enn den er for prosessorkjerner. Det finnes lavt klokkede minnekontrollere med veldig høy ytelse.

 

*)Men joda det er poenget at Conroe vil sløse unna ferre klokkesykluser ved en main memory hit. La oss si at Conroe svir av 100 sykluser og at P4 svir av 200 sykluser i samme case. La oss også anta at Conroe gjør 50% mer per syklus enn P4. Conroe vil være raskere i dette tilfellet pga høyere effektivitet, men det svir nesten like mye (150 vs. 200 P4 normaliserte sykluser) å måtte gå til main memory siden den er mer effektiv. Det jeg sier er at Conroe har større verdi per syklus og dermed er det ikke riktig å bare blindt sammenligne sykluser fra Conroe og P4.

 

En fordel med lavt klokkede arkitekturer er imidlertid at det bør være enklere å bygge gode cache strukturer for de siden det er enklere å levere mer på samme syklus pga parallellitet enn å levere litt mindre på langt kortere sykluser. f.eks det bør være enklere å levere 4 verdier per syklus ved 2 GHz enn 2 verdier per syklus ved 4 GHz, men båndbredden er akkurat den samme.

Endret 3. mai 2006 av Anders Jensen

[Simen1]

Veldig bra spørsmål. For å ta økt FSB hastighet først. Dette reduserer unloaded latency ved at mange av syklusene som benyttes i minnehierarkiet blir kortet ned i lengde (målt i tid). For loaded latency vil en i tillegg dra nytte av at køer i minnehierarkiet blir kortere som en konsekvens av høyere throughput.

 

Når det gjelder påstanden om at lavere klokkede arkitekturer skulle senke forsinkelsen mot minnet på noen måte så er det jo logisk nok bare tull. Det som menes er at mengden klokkesykluser som går til spille er lavere. Dette er forsøvidt også en nokså tullete kommentar siden antallet klokkesykluser som går til spille ikke er den viktige faktoren derimot er antallet klokkesykluser som går til spille multiplisert med IPC av interesse. Siden lavere klokkede arkitekturer må ha høyere IPC for å kunne gi tilsvarende ytelse. Generelt gjelder det at jo høyere ytelse en kjerne har jo mer blir den belastet av forsinkelsen i minnehierarkiet. Om den oppnår høy ytelse ved høy IPC eller høy klokkefrekvens er ikke av særlig interesse.

 

Jeg påstår altså at Johan bare rabler når han drar inn kjernefrekvensen uansett hva han ønsker å mene at den skal bety for latency. Den eneste måten han kan ha rett på er at vi definerer IPC til å være uendret, men da er det plutselig ikke så smart å ha en lavere klokket arkitektur lengre...

6033848[/snapback]

Takk Det ante meg at det var noen ugler i mosen her ja. Det at økt klokkefrekvens en plass skulle gi økt ytelse og senket klokkefrekvens en annen plass skulle gi samme effekt syntes jeg hørtes noe selvmotsigende ut.

 

Når det gjelder overganger mellom ulikt klokkede kretser så er det vel forsinkelsen i at et signal må vente i overgangen på å komme i takt med det andre signalet. Det mest ugunstige er vel rare brøker som 1:3,25 og sånt.

 

Prosessorer med ekstern minnekontroller har vel to slike overganger (CPU->FSB og FSB-RAM) mens AMD's interne minnekontroller har bare en overgang. Dette sparer vel en slik venting både på tur og retur. Den interne klokkefrekvensen til minnekontrolleren kan vel også spille en rolle for hvor lett det er å stable forespørsler, sikfte av banker, refresh osv i en gunstig rekkefølge. Nå vet jeg ikke hvilken frekvens minnekontrolleren i intels brikkesett kjører på, men jeg antar det er betydelig lavere enn AMD's interne.

[Simen1]

Det du beskriver her er mye likt planlagte Alpha EV8. Den var 8-way superscalar og 4-way SMT. Altså på en måte 4 kjerner med sine separate registre som delte på 8 execution pipelines. Ideen høres jo veldig ideell ut men problemet her blir vel klokkefrekvens vs. watt. Ytelsen per tråd blir nok skuffende på slike oppsett fordi det ikke nytter å få så brede design til å kjøre på høye klokkefrekvenser. Det hele bunner vel i ineffektiviteten til Tomasulo algoritmen.

6033940[/snapback]

Hvordan mener du klokkefrekvens vs. watt blir påvirket? Hvis man samler de samme execution units og alle de andre ressursene som allerede finnes i en DC, sammen til en bred design uten å øke det totale antall execution units på brikken så blir det vel ikke noen flere watt totalt sett? Men du tenker kanskje på at en samling av enhetene på brikken vil samle hotspots på et mindre område og begrense klokkefrekvensen på grunn av det?

 

Angående OOO og Tomasulo så er jo intel i ferd med å vise at det går an å ta OOO et steg videre med Core, selv om det var dødsdømt for et par år siden å prøve å skvise mer ILP ut av x86, og at det i så fall ville ført til wattmonstere/transistormonstere.

 

Siden Intel ser ut til å lykkes med ennå flere execution units per kjerne og teoretisk inntil 4-5 intruksjoner per klokkesyklus så tenke jeg at det kanskje gikk an å gå ennå lengre de neste årene ved å lage en sentralisert SMT-brikke. F.eks teoretisk 6-8 instruksjoner per klokkesyklus og 2-veis HyperThreading.

 

P4 hadde jo en annen innfallsvinkel på HT siden det fungerte i stor grad ved å fylle opp stalls (i lengderetning av en lang pipeline), mens det jeg foreslår er å lage en kjerne som hovedsaklig fyller opp bredden av den brede pipelinen.

Endret 3. mai 2006 av Simen1

[blackbrrd]

På en måte så er det hele feil, ettersom en conroe på 2,6 ghz skal være kjappere enn en P4 på 3,8ghz. Med samme fsb så mister conroe'n da mer arbeid når den venter på ram enn P4'n gjør.

 

Det at conroe klarer seg bedre med den fsb'n den har i forhold til P4'n har vel mer med bedre cache arkitektur og kortere pipeline å gjøre enn at forholdet mellom fsb og cpu klokkehastighet er blitt mindre.

[Anders Jensen]

Hvordan mener du klokkefrekvens vs. watt blir påvirket? Hvis man samler de samme execution units og alle de andre ressursene som allerede finnes i en DC, sammen til en bred design uten å øke det totale antall execution units på brikken så blir det vel ikke noen flere watt totalt sett?

6034611[/snapback]

Jo det er akkurat det som skjer. ved å slå de sammen så får du et mye bredere nettverk for å koble alt sammen. Nå er det ikke lengre nok med 1 registerfil som er koblet til 4 execution pipelines og ca 40 reservation stations som er koblet til de samme 4 execution pipelines. Det du foreslår er vil medføre 80 reservation stations og 2 registerfiler (for kun 2-way SMT ikke 4 way) og alt dette koblet til samtlige 8 execution pipelines. Selvfølgelig vil dette gå vesentlig tregere. Det er som å lage ei rundkjøring med 8 avkjørsler hver med 80 felt i steden for ei med 4 avkjørsler hver med 40 felt (som jo er ille nok.). Du får ikke alle til alle koblinger gratis. De koster masse tid og effekt. For IPF finnes det forslag om å segmentere den massive 6-way pipelinen opp i 3+2+1 med minimalt av muligheter for trafikk mellom disse segmentene. Dette for å lage noe som ser ut som en 6-way pipeline men som klokker som 3-way pipeline (ca 50% kjappere).

 

PS hva skjer når du øker antall porter på en crossbar? går den fortere/tregere/samme som før? Og hvorfor har vi ikke svitsjematriser med uendelig mange porter på 1watt? hvorfor koster ikke 244 porters Brocade Silkworm IB svitsj like mye som en Cnet 4 port fast ethernet svitsj. det hele er samme smørja. Bredere = tregere eller dyrere og mer effekthungrig. Sånn er det alltid med elektronisk logikk. Det er faktisk dette som er årsaken til at RAM ikke kan henge med på CPU utviklingen også. Større RAM brikker medfører større 1:n koblinger. Da kan du tenke deg hvor ille det er å øke en m:n kobling. (der m = reservation stations eller registerfiler og n = execution pipelines. Det er også et n:n nettverk for forwarding av resultater mellom hver execution pipeline. En vil jo ikke ha full pipeline penalty bare fordi et resultat skulle benyttes i en annen execution pipeline enn det ble produsert i.)

Endret 3. mai 2006 av Anders Jensen

[Theo343]

Akkurat... tro det eller ei.. makes sense.

[nosto]

10 sec.dette blir bra

[ATWindsor]

10 sec.dette blir bra

6190636[/snapback]

 

Jeg kan godt regne ut like mange siffer i pi fortere enn det om du vil

 

AtW

[nosto]

hehe tror deg jeg

[Betroz]

Topic burde kanskje endres til "Conroe kommer 23. Juli"

Ser ut som 2.93 Ghz blir høyeste klokk ved lansering. Men det blir mye penger å betale for åpen multi!

[ManagHead]

Topic burde kanskje endres til "Conroe kommer 23. Juli"

Ser ut som 2.93 Ghz blir høyeste klokk ved lansering. Men det blir mye penger å betale for åpen multi!

6192124[/snapback]

Vi burde da ha blitt vendt til det nå?

[leifeinar]

Ser ut som 2.93 Ghz blir høyeste klokk ved lansering. Men det blir mye penger å betale for åpen multi!

 

er man avhengig av det for og klokke bra? eller klarer man seg med og og stille litt på fsb

[Stigma]

Ser ut som 2.93 Ghz blir høyeste klokk ved lansering. Men det blir mye penger å betale for åpen multi!

 

er man avhengig av det for og klokke bra? eller klarer man seg med og og stille litt på fsb

6192534[/snapback]

 

Ja, det hadde jeg også likt å visst. Ser ut for meg som 6600 blir en veldig bra kandidat for klokking. Altså i forhold til pris og potensiell ytelse. Du har vel strengt tatt ikke behov for åpne multipliers ved midnre hovedkortet ikke klarer å takle FBS hastigheten eller? Det er lenge siden jeg klokket Intel systemer, så kanskje jeg overser noe?

 

-Stigma

[Gjest Slettet+6132]

Ser ut som 2.93 Ghz blir høyeste klokk ved lansering. Men det blir mye penger å betale for åpen multi!

 

er man avhengig av det for og klokke bra? eller klarer man seg med og og stille litt på fsb

6192534[/snapback]

 

Ja, det hadde jeg også likt å visst. Ser ut for meg som 6600 blir en veldig bra kandidat for klokking. Altså i forhold til pris og potensiell ytelse. Du har vel strengt tatt ikke behov for åpne multipliers ved midnre hovedkortet ikke klarer å takle FBS hastigheten eller? Det er lenge siden jeg klokket Intel systemer, så kanskje jeg overser noe?

 

-Stigma

6192686[/snapback]

 

Jeg vet ikke hva du sikter til her?

 

På "gamle gode" Socket A/eks.Barton's med åpne MP (begge veier) så var åpen MP (oppover) en forutsetning for høy klokk da få hk fra den tida klarte mye over FSB220-230. På "slutten" av Socket A's levetid var alle CPU'er låst.. unntat MP utgavene (selvsagt).

 

Med A64 (ikke FX) kom muligheten til å justere MP *ned* dvs.. ofte litt feilaktig kalt "åpen" MP.. Det er det samme som ES utgaver av P4 og alle nyere "Mobile" versjoner (Pentium M) har hatt. (ES utgaver fra Intel er som FX utgaver fra AMD der MP kan justeres i begge retninger).

 

Dersom man bedriver overklokking for å sette rekorder er det om å gjøre å ha så høy FSB/HTT som mulig... såfremt hk'et klarer dette.. Da setter man MP ned.. og kjøper *rådyr* RAM for å kunne kjøre RAM så høyt som mulig (via RAM-dividers).

 

"Eldre" Intel hk har ikke vært så gode som hk for A64 mht. høy FSB/HTT.. Dette har i det siste endret seg.. De bedre Asus hk (S775) klarer FSB350-360, men gode hk for S939 klarer jo HTT400++.

Det ser ut (ifølge litt uofisielle tester) at de nyeste hk for Conroe (i975x) max'er ut ved FSB450..foreløpig..

Det burde holde selv for rimelige utgaver av Conroe med lav (låst) MP.. for de som vil klokke.

 

PS.

"Klokking er klokking".. og skiller seg i praksis lite fra Intel til AMD.. Men det er det nok bare de av oss som til daglig bruker/klokker flere system fra både Intel og AMD som syns...

Endret 28. mai 2006 av Slettet+6132

[leifeinar]

Det ser ut (ifølge litt uofisielle tester) at de nyeste hk for Conroe (i975x) max'er ut ved FSB450..foreløpig..

 

med andre ord åpen MP er oppskrytt., er jo kjekt med litt god ram og bra hovedkort uansett