Gå til innhold

Intel-firekjerne kommer i år


Anbefalte innlegg

Kanskje mange som sier det ihvertfall, men i den posten jeg linka er det ingen bilder, og heller ingen info om hvordan han har fått tak i denne cpu'en, så jeg velger å ta det med en klype salt.

6524526[/snapback]

 

 

http://www.xtremesystems.org/forums/showthread.php?t=107773

 

Kanskje ikke bilder av CPUen, men folka er kjente og respekterte og ville neppe funnet på noe tull.

 

 

@Efikkan

 

Rykte har det vel heller til at K8L skal ha hound i slutten av navnet. Deerhound, greyhound.

Lenke til kommentar
Videoannonse
Annonse
Det er nok mye det de tenker på. Intels ledelse liker ikke å være senere ute enn AMD med noe som helst

 

Nei hvem vil vel det??

Det gjelder vel neppe bare Intel, vil tro AMD også kjemper en hård kamp for å være først, det er da ganske naturlig . :cool:

Lenke til kommentar

Kentsfield har vært på Xtremesystems.org lenge.

 

De har klart 4Ghz på ekstremkjøling, fra 2,67Ghz Stock

 

De klarte 3,3Ghz med Stock Vcore på TuniqTower luftkjøling tror jeg jeg så.

 

Ytelsen som ble vist der var iallefall ikke mindre enn imponerende. Bra at Intel hiver de her ut før 2007.

 

Ang AMD K8L .65nm så tror jeg selv ikke den kommer før enten 2Q'07 eller midten av 2007.

Lenke til kommentar
Blir det en cpu med fire kjerner?, eller et hovedkort med plass til to cpuer?

6525340[/snapback]

Det første.

 

Dette kan godt være min neste CPU slik at jeg slipper å gå via 2xDC og dyrere hovedkort med mindre AMD får en QC med bedre interconnect ut til konkurrerende pris om ~12-14 mnd når mitt Xeon skal byttes ut.

Lenke til kommentar
Vil tippe de svakeste av Kentsfield'ene vil starte på rundt en 1100-1300$.

 

My guess.

6525567[/snapback]

Ja det virker logisk. De blir nok ganske dyre ei stund. AMD vil nok svare med "4x4"-greiene sine, altså to cpuer på hovedkort. Om det blir vanlige cpuer så blir det nok langt billigere.
Lenke til kommentar

Da kan man snart kjøre doble nedlastings programmer, dekode en DVD film og spille samtidig:)

 

Det blir vel ikke for ofte og meg.

 

Syntes kanskje overgangen til 4 kjerner kommer litt tidlig, doble kjerner har jo så vidt fått plass på markedet. Og programmere får jo ikke utnyttet de skikkelig enda heller.

 

Men moro blir det. Det er moro å se at det endelig går litt på skinner for Intel om dagen.

Lenke til kommentar

Programmessig er det vel mye mindre endringer som skal til for å utnytte fire kjerner istedet for to, enn det er fra å ikke støtte flere kjerner til å støtte to ?

 

Slik at når programmer og spill først utnytter to kjerner, så er støtten for fire kjerner i praksis alledrede på plass ?

Endret av Sigurd2
Lenke til kommentar
Programmessig er det vel mye mindre endringer som skal til for å utnytte fire kjerner istedet for to, enn det er fra å ikke støtte flere kjerner til å støtte to ?

 

Slik at når programmer og spill først utnytter to kjerner, så er støtten for fire kjerner i praksis alledrede på plass ?

6525958[/snapback]

 

vet ikke helt hvordan intel og amd lager sine prosessorer, men det vi lærte på skolen var at det var 2 måter å lage prosessorer med flere kjerner. enten kan du ha ei felles kø til prosessene, eller du kan ha en kø til hver kjerne. har du en felles kø er det ingen ting programmereren kan gjøre for å bestemme hvilken kjerne som skal kjøre hva, da bestemmes alt av prosessoren etter hvilken algoritme den bruker for å fordele prosessene. men dersom det er en kø pr kjerne, da bestemmer programmereren, og da er det like stor forskjell på 1 og 2 kjerner som på 2 og 4.

Lenke til kommentar

Men poenget er at dersom et program blir skrevet fra en tråd med last til to tråder med last vil nok programereren i alle tilfeller hvor det er praktisk legge inn støtte for n tråder med last i stedet for å binde det til to, som IMO vil være tåpelig. Så dersom en datakomprimeringsalgoritme blir utvidet til to tråder og vil kunne arbeide med to tråder i parallell er det ganske stor sjanse for at du også vil kunne jobbe med fire, fem, åtte, ni osv i parallell.

Det er selvsagt unntak hvor praktiske hensyn kommer inn og det kan nok godt være at i programmer hvor lik last ikke blir kjørt i parallell, men at de forskjellige oppgavene blir delt inn i separate kategorier og hver kategori utført av en tråd blir det klart begrensinger på hvor hvor mange tråder du kan legge lasten på. Et eksempel på det siste er Q3 motorens SMP hvor bildeprosessering blir kjørt i en tråd og lydprosessering blir kjørt i en annen. Selv om fysikk, AI, lys og VoIP blir lagt til i listen er det en begrenset liste og lasten blir nok veldig ugjevn og fordelene med mange-veis CPU blir mindre.

 

Men som sagt, i oppgaver hvor lasten kan deles er det nok like lett å programmere for to som fire eller åtte lasttråder.

Lenke til kommentar
Programmessig er det vel mye mindre endringer som skal til for å utnytte fire kjerner istedet for to, enn det er fra å ikke støtte flere kjerner til å støtte to ?

 

Slik at når programmer og spill først utnytter to kjerner, så er støtten for fire kjerner i praksis alledrede på plass ?

6525958[/snapback]

Mange OS har støttet fordeling av last mellom to kjerner i årevis. Både windows 2000 og XP støtter dette. Men å omprogrammere et program for å bruke flere kjerner er ikke helt enkelt. Det vanskeligste er å finne ut hvilke deler av programmet som kan skilles fra andre uten at det vil bli store ytelsetap på grunn av tidkrevende synkronisering. Ofte er det nesten plent umulig å finne to eller flere krevende ting som kan kjøre på hver sin kjerne samtidig uten ytelsetap. Selv heftig omprogrammering fører ofte bare til middelmålige ytelsegevinster. Reelle ytelsegevinster på nær en dobling ved dobling av antall kjerner er ganske skjeldent, særlig innen enbrukerprogrammer. Jeg tror det vil bli vanskeligere å få f.eks 50% ytelsegevinst av overgangen mellom 2 og 4 kjerner enn mellom 1 og 2 kjerner.

Lenke til kommentar
Ettersom jeg har oppfattet er planen å få revisjon G ned på 65 nm. Rev G er altså ikke K8L, men den neste utgivelsen, som bare vil ha noen små optimaliseringer.

6526107[/snapback]

Jepp, jeg tror en av optimaliseringene er å finjustere timinger på den relativt ferske DDR2 minnekontrolleren. Det kan sikkert gi noen prosent bedre ytelse her og der sånn det skjedde ved overgangen mellom K8 130nm "newcastle" og K8 90nm "winchester". Hvis vi er heldige kanskje de åpner for høyere minnehastigheter på f.eks FX-serien. Akkurat som det kom en lite kjent støtte for DDR-500 på sokkel 939 kan det hende de velger å støtte opp til DDR2-1000 nå. SSE4 er også en ting de kan finne på å putte inn i rev. G.

Lenke til kommentar

Joda, men det er jo ingen reell flaskehals. Den gjør ikke resten av PC-en treigere. De eneste gangene en HD burde være raskere er (logisk nok) når man leser eller skriver filer til den (og det er normalt sett ikke samtidig som man kjører applikasjoner, men heller før). Klart, det hadde jo vært jævlig kult med lagring i stor skala på noe som var like raskt som f.eks. RAM, men det er antageligvis noen år unna.

Lenke til kommentar
Ettersom jeg har oppfattet er planen å få revisjon G ned på 65 nm. Rev G er altså ikke K8L, men den neste utgivelsen, som bare vil ha noen små optimaliseringer.

6526107[/snapback]

Jepp, jeg tror en av optimaliseringene er å finjustere timinger på den relativt ferske DDR2 minnekontrolleren. Det kan sikkert gi noen prosent bedre ytelse her og der sånn det skjedde ved overgangen mellom K8 130nm "newcastle" og K8 90nm "winchester". Hvis vi er heldige kanskje de åpner for høyere minnehastigheter på f.eks FX-serien. Akkurat som det kom en lite kjent støtte for DDR-500 på sokkel 939 kan det hende de velger å støtte opp til DDR2-1000 nå. SSE4 er også en ting de kan finne på å putte inn i rev. G.

6528377[/snapback]

Optimaliseringer av en fersk DDR2-kontroller virker som et naturlig steg ja. Idag har den jo en særegenhet i at den ikke støtter strammere timings enn 3-3-3, uvisst av hvilken grunn. Når det gjelder CAS ligger begrensningen i selve minnechipene (ihvertfall de aller fleste), men det finnes jo mange eksempler på at 3-2-2 virker på Intel-plattformer. AMD-prosessorer er jo også mer ømfintlige for timings pga kortere køer og mindre prefetching, så jeg ser ikke bort fra at de vil justere dette. Et annet punkt hvor det burde være rom for optimalisering, er command rate. AM2 krever ofte 2T selv med bare to dobbeltsidige brikker.

 

Jeg er forøvrig litt spent på rev G, selv om forhåndsrapportene ikke akkurat vitner om noe revolusjonerende. Det at AMD reduserer maks L2-kapasitet til 512kB (bortsett fra FX-serien), i kombinasjon med en prosesskrymping, burde jo gi litt ekstra areal å boltre seg i. Kanskje rev G vil by på en liten overraskelse?

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...