Firekjerne kommer i november?

[Gunderz]

Når kan man forvente å få quadkjerne CPU innenfor en rimelig prisramme(3000) fra henholdsvis AMD og Intel?

[Simen1]

Gunderz: Det spørs litt hva du mener med quadkjerne. Hvis du tenker på intels 2x dobbeltkjerne (Kentsfield) så tror jeg du kan forvente det mot slutten av 2007. Hvis du tenker på AMDs 2x dobbeltkjerne (quadfather 4x4) så tror jeg også prisene på det vil komme ned mot 3000kr (for totalt 4 kjerner) mot slutten av 2007. Hvis du tenker på ekte quadkjerne med 4 kjerner på samme silisiumbrikke så tror jeg prisene vil komme under 3000kr i løpet av 2008.

 

Revox: Angående skalering (ytelseøkning som funksjon av økning i klokkefrekvens) så stemmer det du sier ut sier ut i fra de testene jeg har lest til nå. Dvs. at 10% økning i klokkefrekvens på K8 gir rundt 9% økt ytelse, mens for Conroe gir det en smule mindre, rundt 7-8%. Dvs, at jo høyere klokkefrekvensene blir på begge to jo mindre blir ytelseforskjellen. (Krysningspunktet ligger ikke innen noen praktisk rekkevidde). Sammenliger man K8 mot netburst så stemmer det ennå bedre. netburst gir bare rundt 5% økt ytelse når klokkefekvensen øker med 10%.

 

el_salvad har allerede rettet deg på Tulsa vs. Conroe.

[ArneJ.]

Fint og flott og alt det der at det kommer en 2xdobbeltkjerne fra Intel så raskt. Men det virker jo på mange her inne som de tror på at ytelsen automatisk blir oppmot 4 ganger bedre nå, og da spesiellt i spill. Tar jeg ikke helt feil så blir det litt som med dualcore cpuer bare enda verre, støtter ikke spillet/programmet multitreading så får du heller et større overhead og dertil dårligere ytelse enn en singlecore cpu på samme frekvens.

 

Blir selvfølgelig noe annet om det støtter multitreading. Men lite vits i å kjøpe et produkt man ikke får dratt nytte av i særlig grad før om enda en stund bare fordi det er der. Bare se på hvor tregt det går med å få ut spill som støtter dualcore,det er LENGE iallefall i dataverdenen siden man fikk dualsystemer.

 

Og som Simen1 å mange her sier så er den lave fsben til Intel en flaskehals, og jo mer frekvensene øker på 4 kjerner eller mer, jo dårligere skalerer den i forhold til amd sin HTT.

 

Men siden jeg alltid leser mange tester før jeg kjøper hw så blei det Intel core 2 dou på meg også for en god stund siden. Jeg orker ikke å tenke på hva som kommer om en stund, tar det da.

[Revox]

Tror intel kan tjene ganske mye på å øke FSB men ikke nok til å presse 4 kjerner så langt. Målet dems blir vel å gjøre som AMD, å intregrere minnekontrolleren på cpu. Var flere som lurte på hvorfor plutselig Dell ble så intressert i Opteron rett ved Conroe lanseringen.. Det er nok ikke uten grunn da Opteron skalerer mye bedre enn Conroe. Eller Tulsa heter den vel

6820860[/snapback]

 

Revox da, selv om du har en fin og tight rumpe, så er vel Tulsa fortsatt på 65nm Netburst arkitektur

6822670[/snapback]

 

woops.. My bad

[blackbrrd]

Gunderz: Det spørs litt hva du mener med quadkjerne. Hvis du tenker på intels 2x dobbeltkjerne (Kentsfield) så tror jeg du kan forvente det mot slutten av 2007. Hvis du tenker på AMDs 2x dobbeltkjerne (quadfather 4x4) så tror jeg også prisene på det vil komme ned mot 3000kr (for totalt 4 kjerner) mot slutten av 2007. Hvis du tenker på ekte quadkjerne med 4 kjerner på samme silisiumbrikke så tror jeg prisene vil komme under 3000kr i løpet av 2008.

 

Revox: Angående skalering (ytelseøkning som funksjon av økning i klokkefrekvens) så stemmer det du sier ut sier ut i fra de testene jeg har lest til nå. Dvs. at 10% økning i klokkefrekvens på K8 gir rundt 9% økt ytelse, mens for Conroe gir det en smule mindre, rundt 7-8%. Dvs, at jo høyere klokkefrekvensene blir på begge to jo mindre blir ytelseforskjellen. (Krysningspunktet ligger ikke innen noen praktisk rekkevidde). Sammenliger man K8 mot netburst så stemmer det ennå bedre. netburst gir bare rundt 5% økt ytelse når klokkefekvensen øker med 10%.

 

el_salvad har allerede rettet deg på Tulsa vs. Conroe.

6822837[/snapback]

 

Nå synes jeg du tar for deg skaleringen av conroe og a64 ganske grovt, det hadde kanskje vært greit å linke til dataene du bruker?

 

For å sjekke cpu skalering er spill egentlig litt uegnet ettersom de ofte er GPU limiterte, ikke cpu limiterte.

 

Tok derfor for meg windows media encoder resultatene fra denne testen:

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2802&p=8

 

Sammenlignet skaleringen på E6300->E6400, E6700->X6800 og 3800+ -> 4200+.

Skaleringen for conroe med 2mb l2 cache var på 97,7%, mens skaleringen for x2 med 2x512kb l2 cache var 99,6%. Skaleringen for Conroe med 4mb l2 cache var derimot bedre enn lineær (100,2%), som sier meg at forskjellene i skalering her som er på mindre enn 2% ikke er signifikante.

 

Konklusjon:

I windows media encoder skalerer x2/conroe tilnærmet lineært med klokkefrekvens.

 

Når jeg tenker meg om så tror jeg at jeg konkluderer med at 2mb l2 cache versjonen av conroe skalerer litt dårligere enn 4mb versjonen og A64 som begge ser ut til å skalere lineært.

 

Prefetching og stor cache kan tydligvis levere svært god skalering, på lik linje med en integrert minnekontroller.

 

Forresten, kryssningspunket som du snakket om ang x2/conroe er for 4mb versjonen ikke bare utenfor praktisk rekkevidde, det virker som det til tider er fullstendig fraværende også

 

Når jeg først driver å babler om det her, når conroe'n har en fsb på 2000mhz istedetfor 1066 så skjer kommunikasjonen med minnekontrolleren nesten like hurtigt som på en A64.. hmm.. ihvertfall like ofte som på en x2 4200+

Endret 7. september 2006 av blackbrrd

[Simen1]

For å spinne litt videre på det med FSB og flaskehals så er det ikke sånn at FSB er en flaskehals hele tiden. FSB kan godt være flaskehals i ett millisekund og ikke en flaskehals i neste. Når man øker beregningskapasiteten til prosessoren uten å øke FSB så vil FSB oftere bli en flaskehals. Altså flere millisekunder per sekund enn før. Dette vil begrense ytelsen i enkelte øyeblikker og gjøre at programmer yter litt dårligere.

 

For ordens skyld kan jeg ramse opp prosessor, ram, antall kjerner, og båndbredde på noen av intels siste arkitekturer:

 

Pentium4 "northwood" med 2 kanaler DDR-400......: 1 kjerne, 6,4 GB/s FSB, 6,4GB/s minnebåndbredde

Pentium D "Presler" med 2 kanaler DDR-667...........: 2 kjerner, 6,4 GB/s FSB, 10,7GB/s minnebåndbredde

Core Duo "yonah" med 2 kanaler DDR2-667............: 2 kjerner, 5,3 GB/s FSB, 10,7GB/s minnebåndbredde

Core 2 Duo "Conroe" med 2 kanaler DDR2-800........: 2 kjerner, 8,5 GB/s FSB, 12,8GB/s minnebåndbredde

Core 2 Quad "Kentsfield" med 2 kanaler DDR2-1066: 4 kjerner, 8,5 GB/s FSB, 17,1GB/s minnebåndbredde

 

Legg merke til at minnebåndbredden er langt høyere enn FSB. CPU får altså ikke brukt den høye minnebåndbredden siden den må kommunisere med minnet gjennom flaskehalsen FSB. Ofte er ikke dette noe problem siden CPU likevel ikke spør etter så høy minnebåndbredde, men i noen øyeblikker blir den stående og vente på FSB. Jo større gapet er mellom FSB og minnebåndbredde, jo oftere vil disse stå og vente på FSB. Legg også merke til det med antall kjerner. Hele poenget med flere kjerner er å kunne kjøre flere ytelsekrevende applikasjoner samtidig, enten forskjellige programmer i form av multitasking, eller flertrådete programmer. En dobling av antall kjerner fører slett ikke til en dobling i båndbredden på FSB. Når antall kjerner igjen dobles til 4 så blir det ingen økning i FSB. Fra Pentium 4 med én kjerne til Kentsfield med 4 kjerner økes bare FSB med stusselige 33%. Dette betyr selvsagt at prosessoren og minnebussen stadig oftere vil måtte vente på FSB'en før de får oversendt dataene. FSB blir en større og større flaskehals.

 

I tillegg til dette har vi noe som heter cache coherency. Det er trafikk mellom kjernene som går via FSB. Hensikten med dette er at prosessorene må fortelle hverandre om hvilke endringer som er gjort på data som ligger i cachen. Jo flere kjerner jo mer blir det av denne trafikken på FSB. Dvs. at FSB får stadig mer overhead og mindre av den teoretiske båndbredden til å overføre minnetrafikk etter hvert som man øker antall kjerner. Nå har jeg hørt litt motstridende meldinger om Conroe faktisk kan overføre data direkte mellom to kjerner, uten å bruke FSB, altså ved å bruke den delte L2 cahcen, men både på Presler og Kentsfield MÅ denne trafikken gå via FSB.

 

blackbrrd: Takk for utdypelsen. Jeg lagret ikke regnearket jeg satt opp, men det var et godt utvalg tester der. Tester som åpenbart var begrenset av andre ting som GPU, minnebåndbredde og andre ting fjernet jeg for å få en best mulig sammenligning av selve kjernene. Når du først sammenlignet så hadde det vært fint om du sammenlignet noe mer enn bare windows media encoder. Jeg synes det er litt tynnt å skrive en konklusjon basert på bare en benchmark.

[blackbrrd]

Jeg er fullt klar over at det er rimelig tynt med bare en benchmark som utgangspunkt, men jeg skulle bare illustrere at det du sa angående skalering var svært upresist og muligens helt feil.

 

Det er ikke noe personangrep på deg bare så det er klart Simen1, husker sist gang jeg tråkket i "mente å huske at" når det kom til skalering i forhold til cache størrelse på conroe. Jeg trodde det var 10%, mens det var max 10% og gjennomsnittlig 3,5% forskjell i ytelse pr mhz mellom 2 og 4 mb cache. (kilde: anandtech eller xbitlabs)

 

Det jeg egentlig er interessert i er dokumentasjon for påstanden din, ettersom jeg tror den er feil og at Conroe skalerer ca like bra som A64.

 

Samme hvordan man vrir å vender på det så burde man antageligvis holde skaleringen gruppert utfra applikasjonstype, tenker det er noen applikasjoner som A64 skalerer bedre enn Conroe - og motsatt. Nå mener jeg ihvertfall at vi har indisier som tilsier at Conroe skalerer like bra som A64 i encoding...

Endret 8. september 2006 av blackbrrd

[Simen1]

Det er over hodet ikke tatt som noe personangrep. Det er bare hyggelig å ha kompetente folk å diskutere med, selv om det innebærer at jeg blir "eid" av og til. Det er sånt man lærer av

 

Jeg skal prøve å finne frem det materialet jeg brukte til å analysere skaleringen senere i dag. Regner med det tar litt tid å få det grundig så jeg tar det i så fall etter jobb. Dokumentasjon for påstander er viktig for troverdigheten så det skal jeg fremskaffe. (eller korrigere meg selv på om det blir nødvendig)

[Quintero]

Når jeg først driver å babler om det her, når conroe'n har en fsb på 2000mhz istedetfor 1066 så skjer kommunikasjonen med minnekontrolleren nesten like hurtigt som på en A64.. hmm.. ihvertfall like ofte som på en x2 4200+

6823118[/snapback]

Nei, her må du huske å skille mellom dataoverføringer og kommunikasjon mellom CPU - kontroller (dvs kommandoer). 2000 MT (500 quadpumped) er ikke det samme som at kontrolleren opererer på 2000 MHz. At en quadpumped buss kan overføre 4x64 bits pr syklus sier jo lite om hvor effektivt CPU og minnekontroller kommuniserer, og AMD har også en annen fordel i at disse enhetene alltid vil kjøre synkront. At kontrolleren og minnet ikke opererer synkront er strengt tatt ikke noen ulempe når forskjellen i klokkefrekvens blir så stor (AMD), mens det på Intel-systemer vil være et ekstra ledd hvor det kan (og ofte vil) oppstå asynk-forhold (data må bufres, og "syklusene må vente på hverandre"). Intels minnekontrollere er også mindre effektive i den forstand at dualchannel ikke opererer 100% i paralell.

[Quintero]

Var det så store problemer med dette på NForce4 da?

6821145[/snapback]

Sprøs vel litt hva man legger i "store", men det har ikke akkurat vært trivielt å få 4 minnebrikker til å fungere sammen feks, kanskje er jeg kravstor, personlig synes jeg har du 4 slotter, så bør det alltid fungere med 4 brikker, om alle brikkene fungerer (og man må jo såklart regne med at den treigeste brikken begrensen farten for alle).

 

AtW

6821180[/snapback]

Nei, men det var jo minnekontrolleren som var skyld i at man ikke kunne bruke mer enn to plasser uten å slakke på timings og/eller klokkefrekvens. Jeg tenkte mer på hele greia med at man hadde problemer med at enkelte brikker ikke fungerte optimalt, eller ikke i det hele tatt. Det har det vel vært lite med på NForce4.

6821552[/snapback]

Det tok en stund før AMDs integrerte kontrollere ble virkelig gode, men etterhvert fungerte de jo utmerket med fire brikker. At man må øke til 2T command rate er egentlig uinteressant mtp at Intel-kontrollerne har vært låste på 2T i lang tid, også før overgangen til DDR2. Derfor blir det jo litt feil å regne det som en ulempe ved AMD.

[ATWindsor]

Var det så store problemer med dette på NForce4 da?

6821145[/snapback]

Sprøs vel litt hva man legger i "store", men det har ikke akkurat vært trivielt å få 4 minnebrikker til å fungere sammen feks, kanskje er jeg kravstor, personlig synes jeg har du 4 slotter, så bør det alltid fungere med 4 brikker, om alle brikkene fungerer (og man må jo såklart regne med at den treigeste brikken begrensen farten for alle).

 

AtW

6821180[/snapback]

Nei, men det var jo minnekontrolleren som var skyld i at man ikke kunne bruke mer enn to plasser uten å slakke på timings og/eller klokkefrekvens. Jeg tenkte mer på hele greia med at man hadde problemer med at enkelte brikker ikke fungerte optimalt, eller ikke i det hele tatt. Det har det vel vært lite med på NForce4.

6821552[/snapback]

Det tok en stund før AMDs integrerte kontrollere ble virkelig gode, men etterhvert fungerte de jo utmerket med fire brikker. At man må øke til 2T command rate er egentlig uinteressant mtp at Intel-kontrollerne har vært låste på 2T i lang tid, også før overgangen til DDR2. Derfor blir det jo litt feil å regne det som en ulempe ved AMD.

6825124[/snapback]

 

Javel? Jeg har en tålelig ny AMD (1 år), og i den er det langtifra garantert at man bare kan slenge inn 4 brikker (der ikke alle er like), og regne med at det fungerer smertefritt.

 

AtW

[Scortech]

firekjerner er ikke for spillere..er jo bare tull dette.....Det er veldig få spill som støtter 2 kjerner og enda mer tull blir det nå når det kommer fire kjerner....

[leifeinar]

Hvordan er TDP med disse cpuene? blir det dobbelt av C2D?

[el_salvad]

Hvordan er TDP med disse cpuene? blir det dobbelt av C2D?

6825167[/snapback]

 

Skal være på 110W. Opp fra 65W på E6700.

[Quintero]

Javel? Jeg har en tålelig ny AMD (1 år), og i den er det langtifra garantert at man bare kan slenge inn 4 brikker (der ikke alle er like), og regne med at det fungerer smertefritt.

 

AtW

6825151[/snapback]

For det første sa jeg ikke ett ord om bruk av forskjellige brikker. Om det ikke fungerer er det ikke bare minnekontrolleren det behøver stå på. Forskjellige minnebrikker responderer forskjellig på spenning og timings, derfor er det ikke gunstig å blande forskjellige typer. Det sier egentlig lite om kvaliteten på kontrolleren.

 

Det kan forsåvidt legges til at ingen socket 939-prosessorer er garantert å klare fire dualrank-brikker på DDR400, men det vil som regel fungere i praksis. Dette avhenger ganske mye av hovedkortene også, noe som trolig er grunnen til at AMD bare garanterer for DDR333.

[ATWindsor]

Javel? Jeg har en tålelig ny AMD (1 år), og i den er det langtifra garantert at man bare kan slenge inn 4 brikker (der ikke alle er like), og regne med at det fungerer smertefritt.

 

AtW

6825151[/snapback]

For det første sa jeg ikke ett ord om bruk av forskjellige brikker. Om det ikke fungerer er det ikke bare minnekontrolleren det behøver stå på. Forskjellige minnebrikker responderer forskjellig på spenning og timings, derfor er det ikke gunstig å blande forskjellige typer. Det sier egentlig lite om kvaliteten på kontrolleren.

 

Det kan forsåvidt legges til at ingen socket 939-prosessorer er garantert å klare fire dualrank-brikker på DDR400, men det vil som regel fungere i praksis. Dette avhenger ganske mye av hovedkortene også, noe som trolig er grunnen til at AMD bare garanterer for DDR333.

6826472[/snapback]

 

Den delen du kommenterte var jo om nforce4, så jeg er inneforstått med at det ikke nødvendigvis er minnekontrollerens feil, men for meg som sluttbruker, så er det ikke så viktig, poenget er at det ikke funker så bra som det skal.

 

Og ikke kunne bruke forskjellige brikker vil jeg ikke si harmonerer med at det "fungerer utmerket med fire brikker", men det blir vel en "smakssak", det er ihvertfall det jeg oppfatter som problemet.

 

AtW

[Quintero]

Den delen du kommenterte var jo om nforce4, så jeg er inneforstått med at det ikke nødvendigvis er minnekontrollerens feil, men for meg som sluttbruker, så er det ikke så viktig, poenget er at det ikke funker så bra som det skal.

Jeg kommenterte hovedsaklig om AMDs integrerte minnekontroller, ikke nForce4 spesielt. Hovedkortets rolle i dette er stort sett de elektriske karakteristikkene, kretslengde, signal/støy-forhold, BIOS, osv.

 

Og ikke kunne bruke forskjellige brikker vil jeg ikke si harmonerer med at det "fungerer utmerket med fire brikker", men det blir vel en "smakssak", det er ihvertfall det jeg oppfatter som problemet.

 

AtW

6826525[/snapback]

Det kreves jo en viss tilpasning fra brukerens side, og det går igjen i mange ting. Man kan jo f.eks. si at en bil fungerer utmerket med fire hjul - men om de har forskjellig størrelse, etc, fungerer det jo ikke like bra... Det jeg mente er at fire like brikker som regel fungerer bra med revisjon E CPU og DDR400 - å forlange noe mer blir ofte urealistisk (litt avhengig av hvor forskjellige brikkene er).

[el_salvad]

Intels 4-kjerners prosessor "kentsfield" vil være 2 stk Conroe limt sammen på samme brikken. Tester av Core 2 Duo viser at FSB er en merkbar flaskehals allerede ved 2 kjerner og 1066FSB. Når de så dobler antall kjerner uten å øke FSB så vil klart FSB bli en ennå større flaskehals. For AMD's del betyr 4x4 at man øker fra 2 til 4 minnekanaler samtidig som man går fra 2 til 4 kjerner, samt at systembussen ikke forstyrrer trafikken på minnebussen. Dette kan vise seg å gjøre mye med ytelsen i de applikasjonene som støtter så mye som 4 kjerner (noe som er hele vitsen med å kjøpe en PC med 4 kjerner). Både løsningene til AMD og intel vil gjøre at cache coherency må gå via systembussen mellom hvert av kjerne-parene. Altså likt på det punktet rundt juletider, men AMDs 4-kjerneutgave av K8L vil endre på det. Da vil all cache coherency foregå internt på brikken og ikke via systembussen slik som hos intel.

 

 

Som jeg trodde, ser det ut som du tok feil. Etter Tomshardware sin test av Kentsfield, så er der nesten ingen forskjell på 2,67Ghz@1067FSB mot 2,67Ghz@1333FSB. Core er altså ikke så svært avhengig av høy FSB.

 

http://www.tomshardware.com/2006/09/10/fou...on_the_rampage/

 

Nå vil jeg se 4x4

Endret 10. september 2006 av el_salvad

[Revox]

Så spørs det hvor seriøst man skal ta tomshardware

[el_salvad]

Så spørs det hvor seriøst man skal ta tomshardware

6840963[/snapback]

 

Vel, det var vel akkurat det folk sa om THG etter at de testet Conroe. Du ser hva det ble til. Alle andre som testet Conroe fikk det samme. Så tror ikke THG lyver om Kentsfield, iallefall ikke i Intels flytsone