Conroe kommer i juli

[Theo343]

Hvorfor skulle minnekontrolleren til AMD på AM2 ha samme problem som nåværende?

[Gjest Slettet+6132]

er ikke en ekspert på temaet, men vet at man får høyere ytelse ved å bruke flere moduler med mindre plass på hver. er ikke store forskjellen det er snakk om, men den er der.

6009481[/snapback]

 

Da har du nok misforstått. Men for å bruke dual channel trenger man riktignok 2 stk. Å bruke flere har ingen ytelsesfordel, det har derimot flere potensielle ulemper med tanke på stabilitet og du kan risikere å måtte bruke dårligere timings. Jeg hadde aldri kjøpt mer enn 2 brikker til en ny pc, men oppgradering senere blir selvsagt noe annet...

6010483[/snapback]

 

Det du sier her gjelder faktisk kun for enkelt hovedkort/cpu kombinasjoner.

 

i875p hovedkortet til intel sammen med P4 northwood fikk faktisk bedre ytelse jo flere "banks" som var i bruk. Det var knekkende likegyldig om du brukte to "dobbeltsidige" eller fire "enkeltsidige" minnebrikker - ytelsen var lik. Ytelsen var dog litt latere med to "enkeltsidige" minnebrikker.

 

Her artikkelen jeg sikter til:

http://www.anandtech.com/memory/showdoc.html?i=1839&p=1

 

Jeg aner ikke om dette fortsatt er tilfelle, men hvis det er det så har nok Conroe en relativt stor fordel, ettersom det er vanskelig å få kjørt 4 minnebrikker på cl2 og 1t på ddr... Vet ikke hvordan det er med am2 - men antar at minnekontrolleren der har samme problemer med timeings som den nåværende - dvs at de blir dårligere ved flere enn to minnebrikker.

 

*Enkeltsidig og dobbeltsidig vil egentlig si hvor mange "banks" som blir brukt på minnekontrolleren

6014439[/snapback]

 

Interessant link/test... det er dog en stund siden dette da..

Selv har jeg med en del Intel-system etterhvert erfart at ytelse går ned med 4 Dimms kontra 2 dimms (dvs. 2 vs. 1 dual channel)... dog ikke i samme grad som med A64/S939.

Man klarer ihverftall ikke samme "minne-klokk"..

Som ett eksempel i farten:

Med mitt ene Dothan system - 740M @ 2.54 - 2x OCZ DDR466 så kunne minnet kjøres på DDR522 @ 2.5-3-3-7. Med 4 brikker var det ikke mulig å få minnet over DDR466, og der ble beste "combo" å kjøre "synkront" CPU/RAM med DDR422 @ 2-3-2-5.

[Gjest Slettet+6132]

Hvorfor skulle minnekontrolleren til AMD på AM2 ha samme problem som nåværende?

6014500[/snapback]

 

Det vet vi jo lite om ennå... det er da tross alt "bare" ett "sokkel-skifte".. og minnekontroller siiter per def. på CPU.. ergo da må AMD ha gjort forbedringer med neste generasjon A64 for AM2 (noe som ville være naturlig å tro ja)..

 

On topic:

Jeg gjentar meg selv sikkert, men det hadde vært greit å få noen "prereleases"/nyheter fra hk-produsenter/Intel om hvilke hk som kommer/vil støtte Conroe..

Blir litt rart å se at CPU-varianter er "dokumentert".. og at en del "utvalgte" har dem under "testing" sammen med "beta-hk".

Fugger et. co. på xs.org har jo bent frem sagt/skrevet at de "lekker" litt info om testingen pr.dag.. selv om de evt. har testet ferdig.. under påskudd å holde trafikken på sx.org nede/under kontroll. (Kan trolig ha noe for seg).

Dette virker på meg som en måte å "hausse" opp forventninger.. noe jeg bl.a. i denne tråden/dette forum ser fungerer..

Endret 30. april 2006 av Slettet+6132

[blackbrrd]

Hvorfor skulle minnekontrolleren til AMD på AM2 ha samme problem som nåværende?

6014500[/snapback]

 

Jeg sa jeg ikke visst om den kom til å ha samme problemer, men at de hadde det pr idag.

 

Personlig tror jeg ikke de får fikset problemet med dårligere ytelse med flere enn to minnebrikker med minnekontrolleren til am2.

[blackbrrd]

Interessant link/test... det er dog en stund siden dette da..

Selv har jeg med en del Intel-system etterhvert erfart at ytelse går ned med 4 Dimms kontra 2 dimms (dvs. 2 vs. 1 dual channel)... dog ikke i samme grad som med A64/S939.

Man klarer ihverftall ikke samme "minne-klokk"..

Som ett eksempel i farten:

Med mitt ene Dothan system - 740M @ 2.54 - 2x OCZ DDR466 så kunne minnet kjøres på DDR522 @ 2.5-3-3-7. Med 4 brikker var det ikke mulig å få minnet over DDR466, og der ble beste "combo" å kjøre "synkront" CPU/RAM med DDR422 @ 2-3-2-5.

6014590[/snapback]

 

Siste side av den testen jeg linket til viste ytelse med blandete minnepar - den var ikke videre imponerende for Intel

[Theo343]

Blackbrrd: Du sa,

Vet ikke hvordan det er med am2 - men antar at minnekontrolleren der har samme problemer med timeings som den nåværende

Det var en antagelse jeg ikke forstod siden AMD oppgraderer minnekontrolleren fult og helt pga. støtte for DDR2 . Så vi vet ikke, men jeg ville ikke anta det. Men back to topic.

 

Jeg også venter på reelle hovedkort. Før det er Conroe litt luft for meg.

Endret 30. april 2006 av Theo343

[blackbrrd]

Før de faktisk har lansert Conroe-hovedkort - og Conroe i det hele tatt så er vel hele greia et luftslott

 

Det er et luftslott som unektelig ser veldig bra ut dog

[Theo343]

Jupp, enig der hehe

[blackbrrd]

www.anandtech.com kom akkurat med en artikkel som går dypere inn på hva som er gjort med conroe. De har også sammenlignet den med K8, P4 og P-M.

 

Interessant lesning og de 20% vi så i ytelsesøkning ser ut til å kunne stemme for flere applikasjoner enn de conroe hittil er blitt testet med.

 

Det var litt som å se spek'n til K7'n for første gang, da la jeg øyeblikkelig merke til at K7'n hadde 50% flere FPU enheter enn Intel sin P3...

[eldavid]

www.anandtech.com kom akkurat med en artikkel som går dypere inn på hva som er gjort med conroe. De har også sammenlignet den med K8, P4 og P-M.

 

Interessant lesning og de 20% vi så i ytelsesøkning ser ut til å kunne stemme for flere applikasjoner enn de conroe hittil er blitt testet med.

 

Det var litt som å se spek'n til K7'n for første gang, da la jeg øyeblikkelig merke til at K7'n hadde 50% flere FPU enheter enn Intel sin P3...

6020751[/snapback]

 

Husk link: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748

[sannheten_666]

Godt å høre at AMD har fått skuta på rett kjøl igjen, jeg har ikke funnet noe nyere lesestoff på amd's am2 ytelse.

 

ATW, selvsagt, men spørs om det er nok.

vet ikke hva amd har tngt til å lansere som svar til conroe, men med det jeg har sett, hvis det er korekt, vil ikke en FX62 eller lignende kunne gjøre noe med denne cpu'en, og da ligger de såpass mye lenger under at de må kappe priser MYE, og ikke har noe å svare med i toppen.

 

oppskriften på en sakte død.

 

men vi får se.

spennende.

6007823[/snapback]

 

Ja, men sålenge det går sakte nok, så klarer de seg jo (om de kommer med noe nytt etterhvert), intel har jo ligget under en god stund, og de har ikke dødd enda

 

AtW

6008062[/snapback]

 

 

men så er det fordi de systematisk har prøvd å presse AMD ut ved å drive sanksjoner mot merker som velger AMD osv. da... P4 hadde fortjent å være en større flopp...

[GKO]

P4 hadde fortjent å være en større flopp...

 

Blir vel feil å kalle P4 en flopp, før A64 kom på banen så var den jo overlegen socet A som da var AMD`s alternativ .

Rett skal være rett.

[ATWindsor]

P4 hadde fortjent å være en større flopp...

 

Blir vel feil å kalle P4 en flopp, før A64 kom på banen så var den jo overlegen socet A som da var AMD`s alternativ .

Rett skal være rett.

6024910[/snapback]

 

Det varierete litt fram og tilbake over tid hvem som var best av socket A og P4 synes jeg, men over det hele var p4 bedre ja.

 

AtW

[O.J]

Godt å høre at AMD har fått skuta på rett kjøl igjen, jeg har ikke funnet noe nyere lesestoff på amd's am2 ytelse.

 

ATW, selvsagt, men spørs om det er nok.

vet ikke hva amd har tngt til å lansere som svar til conroe, men med det jeg har sett, hvis det er korekt, vil ikke en FX62 eller lignende kunne gjøre noe med denne cpu'en, og da ligger de såpass mye lenger under at de må kappe priser MYE, og ikke har noe å svare med i toppen.

 

oppskriften på en sakte død.

 

men vi får se.

spennende.

6007823[/snapback]

 

Ja, men sålenge det går sakte nok, så klarer de seg jo (om de kommer med noe nytt etterhvert), intel har jo ligget under en god stund, og de har ikke dødd enda

 

AtW

6008062[/snapback]

 

 

men så er det fordi de systematisk har prøvd å presse AMD ut ved å drive sanksjoner mot merker som velger AMD osv. da... P4 hadde fortjent å være en større flopp...

6024355[/snapback]

 

man må også huske at begge firmaene har både langtids - og kortidsavtaler med firmaer for leveranser.

det har i hvertfall reddet Intel.

[O.J]

men så er det fordi de systematisk har prøvd å presse AMD ut ved å drive sanksjoner mot merker som velger AMD osv. da... P4 hadde fortjent å være en større flopp...

 

Pentium4 kan sies å være en flopp fordi den ytet dårligere klokke for klokke enn Pentium3, og den har mye effekt og varmeproblemer. hadde dem heller bygget videre på Pentium3 så hadde kanskje situasjonen vært en helt annen i dag.

 

men for oss forbrukere kan det ha vært bra fordi det tillot en mindre aktør til å vokse og bli konkurransedyktig.

Hadde Intel gjort alt riktig med utviklingen etter Pentium3 hadde nok ikke AMD sluppet til på samme måte, og vi ville ikka hatt samme konkurransen som vi har i dag.

Endret 1. mai 2006 av O.J

[Simen1]

www.anandtech.com kom akkurat med en artikkel som går dypere inn på hva som er gjort med conroe. De har også sammenlignet den med K8, P4 og P-M.

 

Interessant lesning og de 20% vi så i ytelsesøkning ser ut til å kunne stemme for flere applikasjoner enn de conroe hittil er blitt testet med.

 

Det var litt som å se spek'n til K7'n for første gang, da la jeg øyeblikkelig merke til at K7'n hadde 50% flere FPU enheter enn Intel sin P3...

6020751[/snapback]

Husk link: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748

6021148[/snapback]

Jeg sitter og koser med med å finlese artikkelen nå

 

Så dukker det opp et spørsmål fra min side:

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?

[Simen1]

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?

[blackbrrd]

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.

[blackbrrd]

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]

 

Jeg tror det ville vært svært vanskelig å lage en slik prosessor, kanskje spesiellt med tanke på at den da ville hatt halvparten så mange registre som en dobbeltkjerneprosessor.

 

Leste forresten noe interessant som stod om hva slags oppgaver heltallsdelen av prosessorene jobber med, det er høye tynne trær. Det er derfor conroe og yonah kan ha svært bra heltallsytelse i forhold til amd, selv om de har færre alu enehter (2 vs 3 hvis jeg husker riktig).

 

Flyttall er noe helt annet og der har de også lært av dette og laget SSE (1,2,3).

[Simen1]

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

6032258[/snapback]

Jeg tror ikke det var antall klokkesykluser de mente men antall nanosekunder siden de har en sammenligning mellom P4's 80-90ns og K8's 45-55ns i det samme avsnittet.

 

Jeg tror det ville vært svært vanskelig å lage en slik prosessor, kanskje spesiellt med tanke på at den da ville hatt halvparten så mange registre som en dobbeltkjerneprosessor.

6032272[/snapback]

Nei, samme antall registere i fantasiprosessoren min som i dagens DC. De samme ressursene på brikken, bare sammenflettet i stedet for separat. Se for deg at to tofeltsveier slåes sammen til en firefeltsvei. Dersom den ene trådbehandleren vil ha flere ressurser enn den andre så får den dynamisk tatt i bruk overflødige ressurser enkeltvis. F.eks at firefeltsveien gjøres om fra 2 kjørebaner i hver retning til 1 i den ene retningen og 3 i den andre retningen dersom belastningen på den ene retningen er veldig høy i forhold til den andre retningen. Jeg tror et slikt system både ville økt ILP/tråd og gjort at flertrådete programmer med mye nøsting kunne ytt mye bedre enn om kjernene var separate med mange klokkesykluser latency for utveksling av data.