Xeon får "Penryn"-kjerne

[Quintero]

L2-cachen er *lynrask* (noe "cheap-chip ram" på skjermkort ikke er) og stor L2-cache på nyere CPU'er fra Intel har vist seg å være ett arkitektonisk fortrinn.

I langt større grad enn en kan si om den integrerte minnekontrolleren AMD tidlig satset på (praktiske ytelsetester).

Jeg vet ikke nøyaktig hva du mener, men tolker det som at Conroes L2-størrelse i seg selv er et langt større fortrinn enn AMDs integrerte minnekontroller. For den del vil vel de fleste være enige i at Intel har gjort mye fornuftig etter Netburst, men det er jo snakk om flere endringer enn AMD gjorde. Du nevner jo heller ikke noe spesifikt om Core2s cache-design, som f.eks. at den er delt, men kun størrelsen. Både Intel og AMD har jo før hatt dobbeltkjerner med 2MB L2, riktignok med utallige andre forskjeller med i bildet, men de har jo ikke du gjort noe poeng utav. Og såvidt jeg husker viser ikke sammenligninger mellom Allendale og Conroe mer enn noen få prosents forskjell. K7 mot K8 vil absolutt vise større forskjeller (likt klokkede modeller med lik cache).

 

Jeg er ikke den eneste som har forsøkt å forklare deg dette før:

 

Integrert minnekontroller er sannsynligvis det største fortrinnet K8 har kontra K7, selv i 1-veis systemer. Såvidt jeg husker reduseres forsinkelsen med om lag 30-40 nanosekunder under sammenlignbare forhold. I tillegg øker båndbredden, som betaler seg i form av lavere loaded latency. Dette er jo faktorer som øker ytelsen, så enkelt er det. Du snakker jo selv om fordelen ved "lynrask cache", og at kraftig redusert minneforsinkelse også har betydning for ytelsen burde ikke overraske noen. Det er forøvrig mye jeg kunne ha sagt om generell implementasjon og design av kontrollere, og hvilke strategier som er mest gunstige for hva, men jeg vet ikke om det ville hatt så mye for seg...

 

Jeg håper ikke AMD "tviholder" på sine løsninger slik Intel gjorde med Netburst utifra helt teoretiske betraktninger som i praksis viser seg å ikke ha noen reell effekt.

Så AMD burde gå tilbake til ekstern minnekontroller samtidig med at Intel følger opp med en "meningsløs" integrering av den?

 

Det at Intel snart endrer til en lignende strategi burde faktisk si deg noe...

Endret 10. november 2007 av Quintero

[Gjest Slettet+6132]

@Quintero:

Du velger bevisst? å misforstå poenget mitt.

 

Stor L2-cache i seg selv er ikke nødvendig en garanti for god ytelse i gitte applikasjoner.

 

Det er prosessor-arkitektur og implementering av denne som betyr noe.

 

Og jeg kommer *aldri* til å prøve å følge dine detaljerte betraktninger/studier av prosessor-arktiektur.

Jeg mener likevel at jeg med sikkerhet kan si noe om praktiske resultater av gitt arkitektur uten at du kan "arrestere" meg for noesomhelst.

 

Jeg fatter ikke at du skal fortsette å "disse" (kverulere) rundt dette med Intels design kontra AMD's design når de facto ytelses-tester viser at Intels "mindreverdige" FSB-design yter bedre enn AMD's design basert på integrerte minnekontroller.

I all hovedsak.

Men du er ikke aleine om å "pukke på" denne o så fantastiske integrerte minnekontroller.

En vesentlig forskjell er dog at du veit hva du snakker om i denne forbindelse.

 

Det betyr ikke at integrert minnekontroller er "feil ting". Langt derifra.

 

Poenget er at arkitektur, design og *implementering av denne* er det som teller.

 

Og det er ikke noen ulempe at Intel følger etter AMD mtp integrert minnekontroller.

 

Om dette vil gi flere fortrinn eller stor ytelsesgevinst for Intel's kommende CPU'er får tiden vise.

 

Btw:

Regner med at ryktene om Hector Ruiz avgang er ett klart signal om at AMD har prioritert feil i lengre tid nå.

Kanskje de nå skal fokusere på f.eks. å få sitt klart (på papiret) bedre arkitetur implemtert slik ta det faktisk gir en vesentlig ytelsesboost.. Og ikke bare i SPecInt.

Endret 10. november 2007 av Slettet+6132

[Theo343]

Men er det ikke slik at integrert minnekontroller og HTT gir bedre ytelse i noen situasjoner, mens Intels quad pumped FSB og høy L2 kommer bedre ut i andre?

Endret 10. november 2007 av Theo343

[Gjest Slettet+6132]

Men er det ikke slik at integrert minnekontroller og HTT gir bedre ytelse i noen situasjoner, mens Intels quad pumped FSB og høy L2 kommer bedre ut i andre?

 

Jo.

 

Rent teknisk er det vel ingen tvil om at AMD's arkitetktur med integrert minnekontroller ("motorvei direkte mellom RAM og CPU") er et stort fortrinn.

 

Det er like liten tvil om at dette fortrinnet (pt) på ingen måte har gitt noen vesentlig generell boost i håndtering av program(maskin)kode (som jo er det CPU'en har som jobb for å si det primitivt).

 

I visse typer syntetiske benchmarks så kommer AMD's arkiteturiske fortrinn (relativt) tydelig fram, men det er i større grad Intels (Core 2 Duo's) mer "primitive" arktitektur som gir boost i andre benchmarks.

 

Jeg imøteser mange og gode offisielle tester av K10 mot Core 2 Duo i månedene som kommer.

 

Så kan vi jo bruke masse tid på å diskutere hvem "har rett" og hvem som "har feil", dersom det er interessant.

 

Jeg forholder meg til rene tall i dagens (og kommende) benchmarks, klokkbarhet, pris, teknologi som ytelse pr.watt..osv.

 

Å begi meg inn på dyptgående analyser av selve arktitekturen ser jeg foreløpig som mindre interessant.

Det er *ihvertfall IKKE* noe AMD kan basere framtida på mtp suksess i markedet.

 

Jeg synes likevel det er imponerende å se andre som kan argumentere / redegjøre for arkitetur her på forumet.

 

[Quintero]

@Quintero:

Du velger bevisst? å misforstå poenget mitt.

Neida, og jeg synes det blir en tanke drøyt å foreslå det. Jeg sa jo at jeg ikke var sikker på hva du siktet til, men vil fortsatt si at jeg baserte meg på en ganske "rett frem" tolkning av ordene dine.

 

Stor L2-cache i seg selv er ikke nødvendig en garanti for god ytelse i gitte applikasjoner.

 

Det er prosessor-arkitektur og implementering av denne som betyr noe.

 

Og jeg kommer *aldri* til å prøve å følge dine detaljerte betraktninger/studier av prosessor-arktiektur.

Jeg mener likevel at jeg med sikkerhet kan si noe om praktiske resultater av gitt arkitektur uten at du kan "arrestere" meg for noesomhelst.

Nå er jeg langt ifra noen CPU-spesialist selv, men som en entusiast med en mer teoretisk vinkling enn de fleste, kan jeg generelt si følgende: Noen ganger kreves det faktisk teoretisk kunnskap for å kunne trekke konklusjoner, også fra benchmarks. Uten kunnskap kan man ikke alltid være sikker på hva man i det hele tatt observerer. Blant de mer teoretisk orienterte er det heller ikke et ukjent fenomen at "klokkefreaker" som i stor grad klamrer seg til praktisk testing ofte kan lure seg selv med resultatene. Men dette er mer på generelt grunnlag, og forskjellene mellom Core2 og K8 er jo ganske store. Du kan jo som alle andre se på en rekke forskjellige tester, som gjennomgående viser at Core2 yter bedre, og med sikkerhet konkludere at Intel har hatt det beste produktet siden midten av 06.

 

Jeg fatter ikke at du skal fortsette å "disse" (kverulere) rundt dette med Intels design kontra AMD's design når de facto ytelses-tester viser at Intels "mindreverdige" FSB-design yter bedre enn AMD's design basert på integrerte minnekontroller.

I all hovedsak.

Jeg tilbringer stadig mindre tid på dette middelmådige forumet, og når jeg først logger på så er det ikke for å kverulere. Jeg sitter absolutt ikke med noen følelse av å ha drevet med meningsløs flisespikking her.

 

Det jeg reagerte på var hvordan du fokuserte på integrert minnekontroller vs større cache, nesten som om det var de eneste design-elementene som hadde betydning. Jeg gikk igjennom ditt utsagt, som jeg oppfattet som temmelig svart/hvitt, og føler ikke at jeg var urimelig:

 

"L2-cachen er *lynrask* (noe "cheap-chip ram" på skjermkort ikke er) og stor L2-cache på nyere CPU'er fra Intel har vist seg å være ett arkitektonisk fortrinn.

I langt større grad enn en kan si om den integrerte minnekontrolleren AMD tidlig satset på (praktiske ytelsetester)."

 

^ Det sitatet kan jeg vanskelig tolke som noe annet enn en at mesteparten koker ned til cachestørrelse vs minnekontroller. Temaet er i og for seg verdt å diskutere, men det virket unyansert når du ikke nevnte andre faktorer. Så "problemet" mitt var først og fremst at du virket å sette den ene opp mot den andre, helt uten å nevne andre, viktigere forskjeller i arkitekturene. Og det virker ikke særlig overbevisende når forskjellen mellom Conroe og Allendale er heller liten, og når både Intel og AMD for lenge siden hadde prosessorer med 2MB L2 (for Allendale yter jo likefullt bedre enn Netburst og K8). Det er også en utbredt oppfatning at K8 uten integrert minnekontroller ville ha kommet langt dårligere ut, selv om ingen vet nøyaktig hvordan en slik CPU ville ha ytet.

 

Jeg har aldri sagt at det ene ikke kan kompensere for det andre - faktisk har jeg eksplisitt fortalt deg det motsatte. Det har jo også Anders Jensen vært inne på, både i denne og tidligere tråder. Men som du er inne på i forrige innlegg - det er selvsagt ikke noen automatikk i at prosessoren med størst cache eller den mest effektive minnekontrolleren må være best i alle tilfeller

[Quintero]

Men er det ikke slik at integrert minnekontroller og HTT gir bedre ytelse i noen situasjoner, mens Intels quad pumped FSB og høy L2 kommer bedre ut i andre?

Joda, som AJ har nevnt handler det mye om størrelsen på datasett og hvorvidt de samme dataene brukes om og om igjen av CPU.

 

Isolert sett er både stor cache (hvis forsinkelsen ikke blir urimelig høy) og integrert minnekontroller en fordel mtp ytelse. Designet som helhet bør være i en viss "balanse".

 

Intel har lavere båndbredde og høyere forsinkelse, derfor tjener de mer på aggressiv RAM-til-CPU prefetching, og da er det jo greit å ha litt cache å boltre seg i. Nå er vel ikke Core2 like avhengig av høy båndbredde som Netburst, for såvidt jeg vet bruker Core2 mindre hyppig oppdatering av RAM (som spiser båndbredde og øker loaded latency). Så for Core2s vedkommede handler det nok mer om at selve minnesystemer rett og slett er mindre effektivt.

PS: Quadpumping er ikke noe stort poeng i seg selv, og kan absolutt ikke regnes som noe fortrinn i forhold til AMDs løsning. Når K8-prosessorer adresserer minnet, så foregår det 100 % paralelt (dualchannel), og den teoretiske båndbredden vil alltid utgjøre kanalenes samlede overføringskapasitet. Husk at FSB er én kanal på 64 bits (quadpumped), mens hver minnekanal også er 64 bits, bare dualpumped. Kommunikasjonen mellom minne og kontroller foregår alltid på minneklokken (AMD).

 

AMD har tradisjonelt hatt mindre hyppig oppdatering av minnet, som betyr en "renere" minnebuss, med færre skifter av retning, kortere køer (dvs lavere forsinkelse til mottaker), og en mer "spontan" måte å aksessere minnet på. De korte køene gjør at minnets interne forsinkelser (tRCD, CAS, osv) blir en større del av helheten, mens båndbredden blir mindre vesentlig. For Netburst så er det motsatt. Lange, sammenhengende overføringer skjuler i større grad de interne forsinkelsene, og båndbredden blir mer avgjørende for den effektive forsinkelsen til mottaker. Høy båndbredde holder kølengden nede fordi overføringene tar kortere tid.

 

Men igjen, det er fullt mulig å kompensere for både lite cache og ekstern kontroller, på andre områder.

[haalo]

Blir imponert over mye du kan, Quintero. Vennligst ikke forlat forumet .

 

---

 

Ser at det står LGA775 i prisguiden også. Det er egentlig en gangske alvorlig feil, burde rettes opp fort.

[Theo343]

Føler meg alltid tilfredstilt av svarene til Quintero og andre kunnskapsrike mennesker her .

[Gjest Slettet+6132]

@Quintero:

 

Flott svar

 

Det var jeg som misforstod.

 

At du velger å kalle dette ett middelmådig forum er jo ikke akkurat usant.

Derfor er det viktig at du fortsetter å "gidde" å poste her.

[Anders Jensen]

AMD har tradisjonelt hatt mindre hyppig oppdatering av minnet, som betyr en "renere" minnebuss, med færre skifter av retning, kortere køer (dvs lavere forsinkelse til mottaker), og en mer "spontan" måte å aksessere minnet på. De korte køene gjør at minnets interne forsinkelser (tRCD, CAS, osv) blir en større del av helheten, mens båndbredden blir mindre vesentlig. For Netburst så er det motsatt. Lange, sammenhengende overføringer skjuler i større grad de interne forsinkelsene, og båndbredden blir mer avgjørende for den effektive forsinkelsen til mottaker. Høy båndbredde holder kølengden nede fordi overføringene tar kortere tid.

Litt i tvil om dette du sier om kortere køer. Det kommer jo litt an på hvilke kølengder en sikter til her. Jeg vil vel egentlig påstå at de dype køene i minnehierarkiet til Intel er mye av årsaken til at de klarer å skvise ut så mye ytelse av systemene sine. Generelt sett er en lang hw implementert kø bedre enn en kort kø og i dette tilfellet handler det om å utnytte mest mulig MLP, noe som ikke er noe unntak fra regelen. Dette fordi en kort kø vil tvinge frem en blokkering når den blir full. Basic kønettverk teori. De fleste køer implementert i høy ytelse hardware er også slik at ventetiden i køen er variabel slik at en task ikke venter lengre enn nødvendig. I tillegg har noen køer reordering som igjen fungerer bedre jo flere elementer som befinner seg i køen.

[Quintero]

Takk for støtten, folkens! Jeg får vel prøve å holde motivasjonen oppe

 

AMD har tradisjonelt hatt mindre hyppig oppdatering av minnet, som betyr en "renere" minnebuss, med færre skifter av retning, kortere køer (dvs lavere forsinkelse til mottaker), og en mer "spontan" måte å aksessere minnet på. De korte køene gjør at minnets interne forsinkelser (tRCD, CAS, osv) blir en større del av helheten, mens båndbredden blir mindre vesentlig. For Netburst så er det motsatt. Lange, sammenhengende overføringer skjuler i større grad de interne forsinkelsene, og båndbredden blir mer avgjørende for den effektive forsinkelsen til mottaker. Høy båndbredde holder kølengden nede fordi overføringene tar kortere tid.

Litt i tvil om dette du sier om kortere køer. Det kommer jo litt an på hvilke kølengder en sikter til her. Jeg vil vel egentlig påstå at de dype køene i minnehierarkiet til Intel er mye av årsaken til at de klarer å skvise ut så mye ytelse av systemene sine. Generelt sett er en lang hw implementert kø bedre enn en kort kø og i dette tilfellet handler det om å utnytte mest mulig MLP, noe som ikke er noe unntak fra regelen. Dette fordi en kort kø vil tvinge frem en blokkering når den blir full. Basic kønettverk teori.

Jeg er ikke sikker på om vi tenker på de samme tingene her, men skal prøve å utdype mitt syn.

 

At en kø har kapasitet til å romme mange entries gir naturlig nok høyere terskel før en blokkering oppstår. Men jeg snakket om hvor mange forespørsler som befinner seg i køen til enhver tid, ikke dens "fysiske" kapasitet. Og høy throughput gjør jo at en gitt lengde tar kortere tid å rydde unna.

 

At mange adresser står i kø gir flere kandidater å velge mellom, og det kan gjøre det lettere å ivareta høy throughput. Sannsynligheten blir da større for at en eller flere av adressene faller under et område som er lett tilgjengelig (aktiv rad), og dermed kan bobler unngås / reduseres. Men lange køer er ikke noen forutsetning for at overføringer fra forskjellige områder kan overlappe hverandre perfekt. Fra et kommando-ståsted så er jo kontrolleren alltid et steg foran aktiviteten på databussen, og avhengig av timings, antall banker, organisering, osv, så er det også mulig å kamuflere de operasjonene som ikke kan unngås (som jeg kommer tilbake til kan enkelte operasjoner hoppes over, under enkelte forutsetninger). Men hvis målet er optimal throughput så kan det fremdeles bli nødvendig å stokke om på køen før man rekker å skvise inn forespørsler som ikke er lettest tilgjengelig. Jeg tviler dog på at noen kontrollere endrer på rekkefølgen av det formålet alene.

 

 

De fleste køer implementert i høy ytelse hardware er også slik at ventetiden i køen er variabel slik at en task ikke venter lengre enn nødvendig. I tillegg har noen køer reordering som igjen fungerer bedre jo flere elementer som befinner seg i køen.

Det er ikke sikkert vi er på samme spor, men jeg tenker at dette avhenger av hva man regner som optimal minnehåndtering. Jeg tror ikke at optimal utnyttelse av databussen nødvendigvis er det som gir høyest ytelse. Enten man prioriterer throughput eller lavest mulig forsinkelse til utvalgte data, kan det nok slå negativt ut hvis strategien utøves for aggressivt. Siden jeg kjenner bedre til AMDs kontrollere, vil jeg her basere meg på dem. Vi diskuterer jo minnekontrollere på et ganske generelt grunnlag, og lignende funksjoner gjelder sikkert for Intel også.

 

 

Bypass Max (0-15): Denne angir det høyeste antallet sykluser som kontrolleren kan nedprioritere den eldste forespørselen, til fordel for lettere tilgjengelige data. Når øvrige forespørsler ligger til rette for å kunne forlenge "flytsonen" så kan det være gunstig å unngå et avbrudd, istedenfor å veksle til et annet område, og deretter måtte vende tilbake for å fullføre lesingen av forrige område. Kontrolleren vil altså stokke om på forespørslene basert på deres tilgjengelighet. Ulempen er at kritiske data kan bli unødig forsinket.

 

Denne funksjonen kan minne om Native Command Queueing som harddisk-kontrollere benytter, og det er nok lettere å se for seg prinsippet i et mekanisk komponent. Vi kan tenke oss en harddisk som skal håndtere tre forespørsler - vi kaller dem 1, 2 og 3. Nummer 1 befinner seg ytterst på platen, nummer 2 befinner seg helt innerst, og nummer 3 er i midten. Hvis vi endrer rekkefølgen de leses i til 1 - 3 - 2 så vil altså lesehodet kaste bort mindre tid på å flytte seg frem og tilbake mellom hver overføring, som reduserer den totale forsinkelsen før alle områdene er lest.

 

 

Read/Write Queue Bypass (maks 16): Hensikten med denne er å kunne utsette en overgang fra lesing til skriving i inntil 16 sykluser etter at en skriveforespørsel mottas (K8). Dette punktet blir forbedret i K10, iom at den har dypere skrivebuffere som naturlig nok gjør at turnarounds kan utsettes ytterligere. Hver av dens kontroller kan jo i tillegg operere i hver sin retning på samme tid.

 

 

Idle Cycle Limit (0 - 256): Bestemmer maks antall sykluser en rad kan holdes åpen etter forrige overføring, før den konsekvent lukkes. En av nøklene er balansen mellom følgende situasjoner:

 

Page Hit: Raden er allerede åpen, dermed kan den leses etter en eneste kommando - CAS.

 

Page Miss: Banken står i aktiv standby, hvor ingen rader er aktive. Dataene blir tilgjengelige etter tRCD - CAS.

 

Page Conflict: Denne oppstår når kontrolleren ber om en rad som befinner seg i en bank hvor en annen rad allerede holdes åpen. Det blir altså en konflikt hvor den ene må vike for den andre, som påtvinger en ekstra operasjon før de nye dataene blir tilgjengelige. Det kreves altså tre operasjoner; tRP - tRCD - CAS

 

Å holde en rad åpen av hensyn til fremtidige forespørsler kan altså slå ut begge veier. Hvilken ICL-verdi som er optimal kommer mye an på hvilken policy kontrolleren bruker, adressemønster til en gitt applikasjon, radlengde, antall moduler, og totalt antall banker. Jo flere banker det blir å fordele dataene mellom, jo gunstigere blir det å bruke en høy verdi. Flere rader som inneholder helt urelaterte data kan altså holdes aktive samtidig. Det betyr også at data som befinner seg i helt forskjellige områder kan hentes uten at det skaper bobler. Et lite unntak er hvis det må hoppes mellom forskjellige CS-ranks - da må kontrollerens receivere aktiveres på nytt, og det skaper en liten forsinkelse (Read Preamble). Disse eksemplene forteller meg likefullt at mange kø-elementer neppe er noen absolutt forutsetning for optimal båndbredde-effektivitet.

Endret 12. november 2007 av Quintero

[RamGuy]

Hvor stor forskjell er det på Intel Xeon E5345 2.3GHz og Intel Xeon E5440 2.8GHz?

 

Disse nye kommer bare til sokkel 775, som utelukker støtte for mer enn 8GiB RAM, og muligheten for 2x prosessorer, samt FB-DIMM..

 

Lurer på om en server med 8GiB DDR2 RAM og 1x E5440 @ sokkel 775 er bedre enn 8GiB DDR2 RAM og 2x E5345 @ sokkel 771

 

Disse sokkel 771 hovedkortene til over 3'000kroner må da ha noen fordeler kontra 775 hovedkortene til rundt 1'500?

[Smirnoff]

E5440 er til LGA771. Det står 775 i prisguiden, men det er feil. Det er mye bedre å bruke Intel Processor Spec finder.

[RamGuy]

E5440 er til LGA771. Det står 775 i prisguiden, men det er feil. Det er mye bedre å bruke Intel Processor Spec finder.

 

Hmm.. Ser at en E5405 også er 771. Da blir vell heller spørsmålet mitt om dere hadde foretrukket 2x E5405 eller 2x E5345 ?

 

E5405 er jo priset LANGT lavere enn E5345.

E5345 har riktignok litt høyere frekvens, men mindre cache minne og kjører på 65nm og ikke 45nm.

 

2x E5405 får du til en lavere pris enn en E5345. Derfor skulle mann jo nesten tro at det må være noe ved E5345 som gjør at den koster så veldig mye mer enn E5405?

Endret 12. desember 2007 av RamGuy

[haalo]

E5440 er til LGA771. Det står 775 i prisguiden, men det er feil. Det er mye bedre å bruke Intel Processor Spec finder.

 

Hmm.. Ser at en E5405 også er 771. Da blir vell heller spørsmålet mitt om dere hadde foretrukket 2x E5405 eller 2x E5345 ?

 

E5405 er jo priset LANGT lavere enn E5345.

E5345 har riktignok litt høyere frekvens, men mindre cache minne og kjører på 65nm og ikke 45nm.

 

2x E5405 får du til en lavere pris enn en E5345. Derfor skulle mann jo nesten tro at det må være noe ved E5345 som gjør at den koster så veldig mye mer enn E5405?

Prisforskjeller trenger ikke å samsvare med ytelsesforskjeller. Om det er verdt det må du vurdere, en faktor kan være TCO som jeg tror er mye lavere på E5345. Men hvorfor skal du kjøpe en dualsocket-tjener met 8 CPU-kjerner? Tviler ærlig talt på at du trenger det når du lurte på hvorfor serverhovedkort er så mye dyrere.