Xeon på Pentium M-arkitektur

[snorreh]

X86-Secret sin troverdighet har vært trukket i tvil mange ganger, så jeg ville ikke stolt blindt på det de påstår mhp. EM64T-støtte spesielt ikke når plansjen i saken deres ikke nevner det med et eneste ord:

 

 

FYI: EM64T-støtte betyr minst 40-bits minneadressering, mer om dette her:

http://www.redbooks.ibm.com/abstracts/tips0475.html?Open

Endret 29. juli 2005 av snorreh

[Simen1]

X86-secret.com

 

Il supportera également l'EM64T ("36 bit memory addressing"), l'EIST (Gayserville 3), le multi-threading (CPU BI-Core oblige) et le "FSB address and data parity", un système de contrôle d'erreurs sur le bus de donnée.

 

Noe som betyr oversatt til engelsk;

It will also support the EM64T ("36 bit memory addressing"), the EIST (Gayserville 3), multi-threading (CPU Bi-Core obliges) and the "FSB address and dated parity", a system of control of errors on the data bus.

Dette virker på meg som om x86-secret har feiltolket sin kilde. 36bit minneadressering er ikke det samme som EM64T. Det kilden deres mener med 36bit minneadressering tror jeg er det samme som PAE36/PSE36. EM64T er på sin side 40bit minneaddressering.

 

Edit: Snorreh var kjappere ute

Endret 29. juli 2005 av Simen1

[el-asso]

http://www.anandtech.com/cpuchipsets/showd...spx?i=2342&p=16

http://www.aceshardware.com/SPECmine/index...mt=2800&o=0&o=1

Tror du "glemte" å nevne at det bare er en 755 det er snakk om her.

[snorreh]

http://www.anandtech.com/cpuchipsets/showd...spx?i=2342&p=16

http://www.aceshardware.com/SPECmine/index...mt=2800&o=0&o=1

Tror du "glemte" å nevne at det bare er en 755 det er snakk om her.

Nei, for hvilken serie det er snakk om har lite å si med tanke på relativ flytetallsytelse. Kjerne for kjerne så vil "Yonah" yte lavere enn "Dothan" likevel, ettersom den effektive FSB-hastigheten på "Yonah" blir 333MHz (667/2) sammenlignet med 400/533MHz på "Dothan". Med en kjerne skrudd av så ser jeg likevel ikke helt bort i fra at ytelsen til "Yonah" kan bli brukbar, selv om den dessverre altså mangler 64-bits støtte.

Endret 31. juli 2005 av snorreh

[Simen1]

Kjerne for kjerne så vil "Yonah" yte lavere enn "Dothan" likevel, ettersom den effektive FSB-hastigheten på "Yonah" blir 333MHz (667/2) sammenlignet med 400/533MHz på "Dothan".

Nå er det vel streng tatt ikke så enkelt som å dele bussbåndbredden i to fordi det er to kjerner. To busser på 333 vil ikke yte likt som en delt buss på 667. Grunnen er at bruken av båndbredde vil svinge opp og ned for hver lille tidsluke for hver av de to kjernene. Noen øyeblikk vil den ene kjernen kreve mindre, mens den andre krever mindre og omvendt. Denne fleksibiliteten gir noe økt effektivitet og ytelse i forhold til to ufleksible busser på 333 (en for hver kjerne).

 

P-M er også en arkitektur som er mindre avhengig av bussbredde enn netburst, så båndbredden på bussen vil i utgangspunktet ikke være noen gigantisk flashehals. Tvert i mot så tror jeg en buss på 667 vil stå fint i stil til den prosessoren der. En 800-buss ville sikkert vært noe bedre, men jevnt over tviler jeg sterkt på at ytelsen på en 800-buss på denne ville økt ytelsen i nærheten av 20% i forhold til den med 667 slik du gir inntrykk av ved å si at bussen på 667 er en stor flaskehals.

 

Hva som blir det endelige resultatet vil bli spennede å se, men jeg ser ikke så mørkt på det.

[snorreh]

Hvilken ytelse "Yonah" kommer til å få gjenstår det fortsatt å se selvsagt, men basert på overklokking av bussen til P3 og "Banias/Dothan" så tyder det meste på at denne arkitekturen er båndbredde-begrenset spesielt i SMP (P3). Det som skiller PM mest fra P3 er nettopp at førstnevnte benytter en P4-buss, og den er utvilsomt båndbredde-begrenset. I et SMP-oppsett slik "Yonah" er designet for å brukes så vil også trafikken om FSB bli vesentlig større og representere en klar flaskehals. I en bærbar/desktop så vil nok ikke dette representere noe stort problem, men for dens tvillingbror "Sossaman" som skal brukes i tjenere så regner jeg med at dette vil bli ganske så problematisk der ytelse er kritisk.

Endret 29. juli 2005 av snorreh

[Simen1]

Dual P3 synes jeg blir en dårlig sammenligning siden den har en buss som bare er 1/4 av den som er på Dothan nå. (133 vs. 533-buss). Det å si at Dual P3 er båndbreddebegrenset er helt OK og riktig, men det gir liten relevans ovenfor et dual-system med 533-buss.

 

Det blir nesten som å skylde på at Radeon .... 16-pipelines og 256bit minnebuss er så treg på grunn av minnebåndbredden, og at beviset er at Radeon ... med 8 pipelines og 64bit minnebuss er båndbreddebegrenset.

 

Det er mer relevant å se på Dothan med 400FSB vs. Dothan 533FSB, men selv dette gir ikke noe fullstendig bilde siden vi ikke har sett effekten av en delt buss som er bredere enn P3 sin relativt smale buss.

[snorreh]

Det er jo bare å se på Pentium-D i såfall og sammenligne resultatene med P4 på samme klokkefrekvens og 800FSB, for hvis det er noe PM og P4 har til felles så er det nettopp FSBen. Kjerne for kjerne så yter Pentium-D som kjent dårligere enn P4, og med tanke på at kjernene i "Yonah" i tillegg har delt cache så ser jeg ikke bort ifra at den også kommer til å yte merkbart dårligere enn "Dothan". Det lukter iallefall flaskehalser lang vei...

Endret 29. juli 2005 av snorreh

[Simen1]

Kjernene er helt annerledes på P-M og P4, båndbreddekravene er også helt forskjellige grunnet forskjellige teknikker.

 

Pentium-D har lite med denne diskusjonen og sammenligningen å gjøre.

[Bob Ibsen]

Det er jo bare å se på Pentium-D i såfall og sammenligne resultatene med P4 på samme klokkefrekvens og 800FSB, for hvis det er noe PM og P4 har til felles så er det nettopp bussen. Kjerne for kjerne så yter Pentium-D som kjent dårligere enn P4, og med tanke på at "Yonah" også har delt cache så ser jeg ikke bort ifra at den kommer til å yte dårligere enn "Dothan".

Nei, fordi arkitekturene har karaktertrekk som fører til store forskjeller når det gjelder mininetrafikk. Med en Netburst-CPU vil enhver cache-oppdatering øyeblikkelig speiles hele veien til RAM. Dette er en såkalt write-through cache-policy, og Pentium M benytter ikke denne, trolig fordi det fører til økt effektbruk og krav til båndbredde. AMD-prosessorer har samme policy som Pentium M, og disse arkitekturmessige forskjellene er også grunnen til at P4 er så mye mer avhengig av høy båndbredde enn Dothan og AMD K7 / K8.

[snorreh]

Nei, AMD sin løsning for cache-håndtering er vesentlig bedre:

http://www.techreport.com/reviews/2005q2/p...40/index.x?pg=2

AMD's dual-core chips share some common resources between cores, including a single system request queue, a single on-die memory controller, and a single set of HyperTransport links for external I/O and cache coherency updates. The two cores can share data with one another via the very high speed on-chip system request interface, which is how cache coherency updates (and cache-to-cache data transfers) are passed.

Mer detaljert om dette her:

http://www.hexus.net/content/reviews/revie...nVybF9wYWdlPTM=

There's also cache coherency to talk about. Back in the days of the Athlon MP, AMD implemented the MOESI cache coherency protocol. MOESI stands for Modify, Owner, Exclusive, Shared, Invalid. Each of those is a state the caches in the system can occupy, depending on what's being done with them by the CPU cores. For example, say that core one updates some memory in its cache, before writing it back out to memory. Core two is always snooping the traffic to core one, and as it spots that happening it marks the caches as Modified, to indicate they're not coherent. In a MESI cache coherency scheme, without the Owner state, if core two wanted to read that memory, it would have to ask core one for it, which tells two to hang on a short while while it writes the data back out to main memory.

 

However, since Athlon MP, single core SMP Opteron and now dual-core Opteron and Athlon 64 X2 have used the Owner state. In the case above, Owner state allows core one to pass the data that core two wanted over the core-to-core interconnect and update the cache on the other CPU directly, without writing it back out to main memory, with the caches then marked as Shared. You can see how that would increase performance.

 

There's less latency when cache data needs to be updated, since you don't need two trips out to main memory, one per core, for a read and write to get the caches back in sync. It's worth noting that Intel's multi-processor Xeon systems currently implement the MESI protocol, so they do have to go out to main memory if cache data is marked Invalid or Modified. I'm not sure how Intel's dual-core processors operate in terms of cache coherency.

 

In a nutshell, if you don't want to wrap your head around cache coherency protocols, the X2 allows the individual caches of each core to be updated without a costly round trip of data into and out of main memory.

 

Cache coherency is one of the main problems to work around when building multi-processor architectures, and only gets harder to do if caches get bigger and you add more processing units to a multi-processor system. It's good to see AMD carry on the work they did with Athlon MP, in that respect.

Mye tyder på at Intel vil implementere MESI-protokollen på "Yonah" også som altså ikke er like bra ytelsesmessig sammenlignet med AMD sin MOESI-protokoll ettersom forsinkelsene der blir større.

Endret 29. juli 2005 av snorreh

[Bob Ibsen]

Ok, men jeg mente minnebussens aktivitet på single-core P4 og P-M. Dvs hvorvidt nylig oppdaterte data skrives konsekvent tilbake til RAM, eller om det først inntreffer ved en "eviction". Mulig vi var på to forskjellige steder, men write-policy er uansett relevant når man skal sammenligne betydningen av høy FSB for forskjellige plattformer.

[martiol]

Den skal jo komme i dobbeltkjerne-utgave og denne arkitekturen egner seg vel ikke så mye til HT som netburst gjør.

At Netburst skal være bedre egnet eller mer avhengig av SMT enn P6 lignende arkitekturer tror jeg utelukkende er basert på missforståelser.

 

SMT har sine fordeler og ulemper, men kan nok implementeres på det meste av OoO arkitekturer med lignende resultat enten det er snakk om Netburst, P6, k8 eller Power5.

 

Det ser ut til å være en vanlig myte (på entusiast forum vel og merke) at dype design har mer å hente av SMT enn korte design. Det er nok ikke så enkelt. F.eks vil svært brede OoO design ha veldig mye å hente på SMT fordi de ikke er kapable til å finne nok ILP on the fly. Power5 er glimrende eksempel på nettopp det.

heh ja. Men du avkreftet ikke myten?

[el-asso]

Nei, AMD sin løsning for cache-håndtering er vesentlig bedre:

[...]

Mye tyder på at Intel vil implementere MESI-protokollen på "Yonah" også som altså ikke er like bra ytelsesmessig sammenlignet med AMD sin MOESI-protokoll ettersom forsinkelsene der blir større.

 

Om Intel vil skifte til MOESI protokollen på "Yonah" aner jeg ikke, men i forhold til cache latency er det ingen ting å si på "Dothans" ytelse:

 

With such a large L1 cache, it is difficult to get much lower than 3 cycles, as we see that the Pentium M has a similar L1 access latency as the Athlon 64.

 

But what we came here to look at was L2 cache latency, which matters much more in real world application performance where not everything fits into L1:

 

Cachemem L2 Latency,  ScienceMark L2 Latency

AMD Athlon 64: 17 cycles 18 cycles

Intel Pentium 4 (Northwood): 16 cycles 16 cycles

Intel Pentium 4E (Prescott): 23 cycles 23 cycles

Intel Pentium M:  10 cycles 10 cycles

 

Here's where things get very interesting - the Pentium M has the lowest L2 cache access time of any of the modern day desktop microprocessors. With a 10 cycle L2 latency, any application that fits within the Pentium M's 2MB cache will most definitely perform very well on the CPU. It is the 10 cycle L2 that allows the Pentium M to be competitive with much higher clocked CPUs in most mobile applications as they are normally office application tasks that are generally very cache-friendly.

 

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2342&p=5

[snorreh]

Nei, AMD sin løsning for cache-håndtering er vesentlig bedre:

[...]

Mye tyder på at Intel vil implementere MESI-protokollen på "Yonah" også som altså ikke er like bra ytelsesmessig sammenlignet med AMD sin MOESI-protokoll ettersom forsinkelsene der blir større.

Om Intel vil skifte til MOESI protokollen på "Yonah" aner jeg ikke, men i forhold til cache latency er det ingen ting å si på "Dothans" ytelse

Det ser ikke slik ut, men det som teller mest ytelsesmessig på reelle problemer er tilgangstider på minne og ikke bare cache. På dette området ligger Athlon 64 flere hestehoder foran takket være sin ekstremt raske integrerte minnekontroller. Likevel er det interessant det du kommer med her, selv om tilgangstidene på cache sannsynligvis vil være endel dårligere på "Yonah" ettersom hver kjerne der deler nøyaktig den samme cachen. Hvis "Yonah" kun implementerer MESI-protokollen så vil nok write-through cache-policy som Bob Ibsen nevner også bli et problem ytelsesmessig.

Endret 1. august 2005 av snorreh

[Bob Ibsen]

Cachemem L2 Latency,  ScienceMark L2 Latency

AMD Athlon 64: 17 cycles 18 cycles

Intel Pentium 4 (Northwood): 16 cycles 16 cycles

Intel Pentium 4E (Prescott): 23 cycles 23 cycles

Intel Pentium M:  10 cycles 10 cycles

Å bare ta hensyn til antall klokkesykluser blir jo ikke helt riktig fordi alle cache-nivåer kjører synkront med CPUens interne klokke. Tallene fra Anandtech er noen helt andre enn Intel selv oppgir, nemlig 7 slag for Northwood og 11 for Prescott. L1-latencyen er så vidt jeg vet trukket ifra, både i Intels og Sciencemarks målinger.

 

At Northwood skal ha L2-latency på nesten like mange klokkesykluser som K8, ser jeg på som temmelig usannsynlig. L2-ytelsen er jo alfa og omega for Netburst. I tilfellet L1 miss - L2 hit har denne arkitekturen, med sin write-through policy en fordel i at det allerede finnes to kopier av alt innholdet som er i L1. Derfor kan en blokk i L1 overskrives med nye data fra L2 uten ekstra flytting og frigjøring, som write-back ville ha medført. På K8 kan ikke en linje bare overskrives uten videre, fordi det som regel ikke finnes noen backup av den. Netburst har i tillegg lavere L2-associativity enn K8 (8 mot 16), slik at færre tags må sammenlignes for hvert søk. Når det gjelder Dothan er jeg usikker, men jeg har ihvertfall problemer med å sluke disse tallene rått

 

 

Edit: Etter en søkerunde ser tallene ut til å samsvare ganske bra med de fleste kilder, men det varierer endel. Vet ikke helt hva jeg skal tro

Endret 31. juli 2005 av Bob Ibsen

[el-asso]

Cachemem L2 Latency,  ScienceMark L2 Latency

AMD Athlon 64: 17 cycles 18 cycles

Intel Pentium 4 (Northwood): 16 cycles 16 cycles

Intel Pentium 4E (Prescott): 23 cycles 23 cycles

Intel Pentium M:  10 cycles 10 cycles

Å bare ta hensyn til antall klokkesykluser blir jo ikke helt riktig fordi alle cache-nivåer kjører synkront med CPUens interne klokke. Tallene fra Anandtech er noen helt andre enn Intel selv oppgir, nemlig 7 slag for Northwood og 11 for Prescott. L1-latencyen er så vidt jeg vet trukket ifra, både i Intels og Sciencemarks målinger.

 

At Northwood skal ha L2-latency på nesten like mange klokkesykluser som K8, ser jeg på som temmelig usannsynlig.

Hmm, det er mulig du har rett. I og med at Netburst bruker dupliserende inclusive cache relationship sparer de ganske mange klokkesykler i forhold til Hammer/K8's exclusive cache som i utgangspunktet må flytte "gamle" data fra L1 til L2 og "nye" data fra L2 til L1 igjenn (forutsatt at dataene finnes i L2).

Imidlertid bruker jo A64 en VB (Victim Buffer) som minsker forsinkelsen i antall klokkesykluser.

 

Men det er godt mulig disse tallene må tas med en klype salt

 

Ett annet interessant moment er at det er snakk om forsinkelse i absolutte klokkesykluser. Når en ser på cache (som følger prosessorens klokkehastighet) vil forsinkelsen målt i tid være mindre for Netburst siden denne opererer på høyere frekvens enn PM og A64.

 

Eksempelvis vil en forsinkelse på 17 sykler ta 8,5 ns på A64 3200 (2,0 GHz), mens

23 sykler på en Prescott 640 (3,2 GHz) bare tar 7,2 ns, og en Pentium M 760 (2,0 GHz) vil ved 10 syklusers forsinkelse bruke 5 ns.

 

Når det gjelder forsinkelse mot RAM har A64 en klar fordel med sin integrerte minnekontroller selv om "data raten" bare er på 400 MHz (og ikke følger CPU klokken som for cache).

 

Edit: Noe parantes greier

Endret 31. juli 2005 av el-asso

[Bob Ibsen]

CPUIDs artikkel om K8

 

On the other hand, an inclusive relationship can be very efficient, as the Pentium M shows.

Her mener de altså at P-M er inclusive. Men i tabellen noen sider nedi denne artikkelen står det svart på hvitt at den er write-back. Jeg er også sikker på at jeg har lest ett eller annet sted at Pentium M er exclusive write-back, først og fremst av hensyn til strømsparing.

 

CPUIDs artikkel om P-M

 

We notice that the L1 and L2 sizes don't add, that proves the inclusive relationship between the two cache levels : the L1 is duplicated in the L2, that provide the best performances, but some waste in the total cache quantity.

...når man tenker på Dothans lave tilgangstider (ifølge alle!), samt størrelsesforholdet imellom nivåene, virker det sannsynlig at den er inclusive. På den andre siden er det ingen tvil om at P-M er mindre avhengig av høy båndbredde enn P4. Jeg må jo si at jo mer jeg leser, jo mer forvirret blir jeg...

 

 

Angående victim-cache er visst ikke alle helt enige, der heller:

 

Later processors, such as the AMD K7 and K8, used the very large secondary cache as a victim cache, to avoid duplicate storage of the contents of the large primary cache.

 

In order to speed-up the process, the exclusive caches very often use a victim buffer (VB), that is a very little and fast memory between L1 and L2. The line evicted from L1 is then copied into the VB rather than into the L2. In the same time, the L2 read request is started, so doing the L1 to VB write operation is hidden by the L2 latency. Then, if by chance the next requested data is in the VB, getting back the data from it is much more quickly than getting it from the L2.

 

AMD made the choice of an exclusive relationship for the first time on the Thunderbird. The CPU architecture fits on this choice, with a big L1 cache and a 8-entries victim buffer.

Alle oppklaringer mottas med takk!

Endret 31. juli 2005 av Bob Ibsen

[snorreh]

Bob Ibsen: Kanskje dette oppklarer endel av det du lurer på:

http://techreport.com/reviews/2003q3/penti...hz/index.x?pg=1

The Pentium M's L2 cache is 8-way associative, just like the Pentium 4's, but to conserve power, elements of the Pentium M's L2 cache are only activated when needed. Having to power up parts of the L2 cache before use will add latency that can degrade system performance, but it should reduce the Pentium M's power requirements, which is key for a mobile chip.

[...]

The Pentium M's huge L2 cache is complemented by 64KB of L1 cache that's split evenly between instruction and data caches. Intel has yet to divulge the exact size of the Pentium 4's L1 instruction cache, but the Pentium 4 M's 8KB L1 data cache is a quarter the size the Pentium M's.

 

One more difference between the Pentium M and Pentium 4's L1 cache is that the former is a write-back cache, while the latter is a write-through cache. With a write-through cache, data is written to L1 and main memory simultaneously; write-back caching only writes L1 data to main memory when absolutely necessary. In theory, a write-back cache should be faster than a write-through cache because the write-back cache does fewer slow memory writes.

http://www.digit-life.com/articles2/rmma/rmma-dothan2.html

L1/L2 Data Cache capacities – 32 and 2048 MB respectively, Cache organization type – inclusive (that is L1 data is duplicated in L2).

Se også:

http://www.anandtech.com/mobile/showdoc.aspx?i=1800&p=6

http://www.digit-life.com/articles2/rmma/rmma-dothan.html

http://arstechnica.com/articles/paedia/cpu/pentium-m.ars/1

http://arstechnica.com/articles/paedia/cpu/pentium-2.ars/6

Endret 1. august 2005 av snorreh

[Bob Ibsen]

Takk for linkene, snorreh! Skal gå igjennom dem når jeg kommer hjem fra jobb

Så håper jeg at det ikke bare fører til ytterligere forvirring. Det med write-policyen til P-M ble ikke særlig klarere etter å ha lest sitatene dine... Begge deler virker både logisk og ulogisk på forskjellige måter.

 

Det som står om at write-back i teorien er raskere, har jeg aldri hørt før. Hvis båndbredden er for lav, vil det være riktig, men så lenge båndbredden er høy nok er write-through den policyen som gir høyest cache-effektivitet. Det mener jeg ihvertfall inntil det motsatte er bevist