Intel Core Duo full av feil

[Muffinman]

Æsj, HT er vel ingen nødvendighet med dualcore cpu. Da får man EKTE smp...

[Anders Jensen]

Da var det vel kanskje på tide med fasiten. Har fått svar per PM og El-asso har jo prøvd seg live her i tråden. Om en legger sarkasmen hans til grunn så tror jeg muligens det ble sånn ca. full pott. Ingen av de nevnte punktene medfører nemlig riktighet. Tenker den satt. Her er de igjen: (noen endringer i #9 er gjort for å gjøre punktet mer presist)

 

1) Transistorene i Dothan er varmere enn de i Prescott.

2) P4 arkitekturen liker båndbredde bedre enn K8, mens K8 liker lavere forsinkelse bedre enn P4.

3) FSB er en flaskehals for kommunikasjon fra GPU og I/O til RAM.

4) Integrert minnekontroller på CPU gir lavere forsinkelse mellom GPU og RAM.

5) To dobbelkanals minnekontrollere har samme ytelse som en firekanals minnekontroller. Gitt at de har samme karakteristikk på kanalene.

6) Stor cache yter alltid bedre enn liten cache.

7) Inclusive cache yter alltid bedre enn exclusive cache fordi en får større kapasitet gitt samme transistorbudsjett.

8) Hyperthreading (SMT, Altså ikke slik som på Montecito) er generelt bedre på kjerner med dyp pipeline enn på kjerner med kort pipeline.

9) SMT bidrar kun til to ting; å gjemme forsinkelse til minnehierarkiet (RAM + cache) samt utnytte ledige ressurser i kjernen der det er mulig.

10) Det finnes systemer som skalerer lineært. (F. eks Opteron og SGI Altix.)

Endret 26. januar 2006 av Anders Jensen

[cybervision_]

Dette synes jeg etter å ha lest litt her var en snodig artikkel, har litt peil på data, men kjente ikke til disse feilratene. Umiddelbart etter å ha lest artikkel var reaksjonen: "Shit, og jeg som hadde tenkt å kjøpe ny mac etterhvert, visste det var for godt til å være sant." Men ser jo nå at med nyanserte og objektive øyne er saken mildt sagt litt annerledes...

[balleklorin]

Jeg håper AMD kommer med HyperThreading selv.

 

PS Jeg er AMD fanboy og kjøper ikke annet enn AMD men HyperThreading virker veldig NICE når virusscan/spywarescan kjører og du gjør noe annet med PC.

 

HyperThreading er UT, dualcore er IN!

[Anders Jensen]

Jeg håper AMD kommer med HyperThreading selv.

 

PS Jeg er AMD fanboy og kjøper ikke annet enn AMD men HyperThreading virker veldig NICE når virusscan/spywarescan kjører og du gjør noe annet med PC.

 

HyperThreading er UT, dualcore er IN!

5501840[/snapback]

Det ser ut til å være den midlertidige situasjonen ja. Flertråding vil nok trenge seg på igjen med tid og stunder. Det evig økende CPU/minne ytelsesgapet sørger for det, men det er godt mulig SMT går av moten for alltid... om noen år.

[Del]

Morsom liste AJ, stoff for mange kvelder med kverulering der... Det at ingen så langt har angrepet lista, enda flere punkter er et spark i sida til AMD-tilhengerne, tar jeg som et tegn på at forumet er mye mindre AMD-vennlig enn hva som tidvis påståes.

 

Vil ikke gå så langt som til å si at "alle var feil" er en fasit, som du vet bør alle svar begrunnes, og det kunne vært veldig interessant å hørt begrunnelsene på en del av punktene her. Tenker da spesielt på 2,3,4 og 5.

[Lucifer89]

hva me HT og Dualcore på samme cpu altså to logiske og to ekte elns

[mar]

Morsom liste AJ, stoff for mange kvelder med kverulering der... Det at ingen så langt har angrepet lista, enda flere punkter er et spark i sida til AMD-tilhengerne, tar jeg som et tegn på at forumet er mye mindre AMD-vennlig enn hva som tidvis påståes.

 

Vil ikke gå så langt som til å si at "alle var feil" er en fasit, som du vet bør alle svar begrunnes, og det kunne vært veldig interessant å hørt begrunnelsene på en del av punktene her. Tenker da spesielt på 2,3,4 og 5.

5502585[/snapback]

 

Kan jo prøve å svare på 3 og 4:

 

3: FSB påvirker vell ikke trafikk mellom northbridge (hvor minnekontroller og AGP/PCI-E kontrolleren ligger) og minnet? GPU -> Northbridge -> RAM

 

4: IMC hjelper ikke så mye mellom GPU og minne, med IMC får vi:

GPU -> Northbridge (AGP/PCI-E kontroller) -> IMC (på CPU) -> RAM

[kjaks]

hva me HT og Dualcore på samme cpu altså to logiske og to ekte elns

5502643[/snapback]

 

Intel P4 XE955 har jo akkurat det. Se testen hos tomshardware eller anandtech. Synes å huske at det var en vesentlig ytelsesøkning pga. det.

Endret 26. januar 2006 av kjaks

[Anders Jensen]

Morsom liste AJ, stoff for mange kvelder med kverulering der... Det at ingen så langt har angrepet lista, enda flere punkter er et spark i sida til AMD-tilhengerne, tar jeg som et tegn på at forumet er mye mindre AMD-vennlig enn hva som tidvis påståes.

5502585[/snapback]

Det kan se ut som om pendelen har svingt litt tilbake i det siste. For ca 1/2 - 1 år siden var det helt andre tilstander. Det er vel neppe siste gangen det vil svinge heller.. husker vi som frontet AMD rundt 1996 var å regne for pionerer med bakoversveis. Mener å huske jeg bygde min første AMD maskin da. Ellers er det definitivt rom for kverrulering og tolkning her. Enkelte av punktene er mer å kategorisere som vage eller bare missforståelser heller enn feil.

Vil ikke gå så langt som til å si at "alle var feil" er en fasit, som du vet bør alle svar begrunnes, og det kunne vært veldig interessant å hørt begrunnelsene på en del av punktene her. Tenker da spesielt på 2,3,4 og 5.

5502585[/snapback]

Det var kanskje med hensikt at jeg var noe knapp. Regna med det kunne provosere de rette.

 

Her er min spinn på 2 og 5, siden mar har svart bra på 3 og 4 allerede:

 

"2) P4 arkitekturen liker båndbredde bedre enn K8, mens K8 liker lavere forsinkelse bedre enn P4."

 

Dette er egentlig bare upresist vissvass. Det som er av betydning er alltid forsinkelse, men en må huske å skille mellom "loaded latency" og "unloaded/idle latency". sistnevnte er målbar, men akk så ubrukelig. Førstnevnte er også målbar men ikke konsistent over flere typer belastning og kan endatil endre seg mellom to kjøringer av samme test. Saken er at minnehierarkiet i et P4 system er noe lengre med flere ledd og flere køer enn det til K8. Ved å øke gjennomstrømningen reduserer en kølengder og dermed også forsinkelsen. I et P4 system er altså det å øke båndbredden en relativt sett bedre måte å redusere loaded latency på enn i et K8 system. Det at P4 systemet har en lengre "path" (kanskje å se for seg minnehierarkiet som en lang pipeline hjelper?) gjør også at det å redusere tiden informasjonen oppholder seg på hvert enkelt steg i systemet er mer effektivt. Dette gjøres ved å øke frekvensen, som jo også øker båndbredden i tillegg til å redusere forsinkelsen direkte. Så joda, det å øke båndbredden i et P4 system har helt klart mer for seg enn i et K8 system, men det er ingenting ved kjerne arkitekturene som tilsier at den ene er mer eller mindre avhengig av noe annet en den andre. De er alle kun avhengig av loaded latency, men det er altså to måter å redusere loaded latency på, og for maskinarkitekturen i et P4 system så vil frekvensøkning på alle linkene være mer effektivt enn å kutte noen få sykluser i enden av rekka (tilsvarende å sette bedre timings på minnebrikkene), slik det lønner seg å gjøre på et K8 system. Dette er en direkte konsekvens av at K8 har en mer optimalisert og lengt enklere CPU-cache til RAM kommunikasjon.

 

"5) To dobbelkanals minnekontrollere har samme ytelse som en firekanals minnekontroller. Gitt at de har samme karakteristikk på kanalene."

 

Denne er enkel. Systemene har samme teoretiske båndbredde, men for å kunne utnytte to minnekontrollere like effektivt som en så må du annta perfekt lastbalansering. Dette er selvfølgelig aldri tilfellet og ofte er ubalansen signifikant. Trivielt parallelliserbare oppgaver kan i noen tilfeller bindes til CPU og minne slik at en får svært god balanse. Dette er en av grunnene til at NUMA (og cluster for den saks skyld om vi trekker det hele litt lengre) gjerne komer litt bedre ut i blodtrimmede benchmarks enn de strengt tatt fortjenersammenlignet med UMA systemer.

Endret 26. januar 2006 av Anders Jensen

[Simen1]

A.J.: Ang. 2. Har ikke branch predicton og prefetch enhetene i P4 og K8 helt forskjellige taktikker med tanke på gjetting? Jeg tenker på at P4 henter på forhånd opp mye mer fra minnet enn den trenger bare for å høyne sansynligheten for at den henter noe riktig og dermed minker sansynligheten for stopp i pipelinen? Mens K8 forhåndshenter ikke så mye informasjon fra minnet som P4. Dermed blir minnetrafikken relativt høyere på P4 enn på K8 når man sammenligner en gitt kode. Altså at P4 bruker mer av minnebåndbredden enn K8 for en gitt oppgave. Dvs. begge henter akkurat like mye nyttig fra minnet, men P4 henter større deler unyttig data for å bidra til å skjule "bobler". Uten denne aggressive prefetch-taktikken så hadde vel P4 hatt dårligere ytelse. Hvis de hadde hatt akkurat samme branch prediction og prefetch så hadde de vel bruk akkurat like mye minnebåndbredde til en gitt kode.

 

Hvis man hadde funnet frem en test der K8 2,0GHz yter nøyaktig like bra som P4 3,0GHz så kunne man vel målt seg frem til at P4 bruker mer minnebåndbredde under testen.

[Anders Jensen]

Ja en kan justere noe for prefetch og en kan justere noe for cache kapasitet. Jeg tipper sistnevnte som oftest dominerer førstnevnte på de produktene en ser i dag, men det er jo mye forskjellig å velge i her.

[Anders Jensen]

"Errata articles are the current rage"

http://theinquirer.net/?article=29321

 

Noen burde lese denne. De hadde spart oss for mye søppel på internett.

[Del]

Takker, mange gode svar og avklaringer her. Mine kommentarer punktvis:

2) Med begrunnelse på plass og innspill fra Simen, var alle mine innvendinger borte..

3) og 4) Sant nok, men minne-bussen kan være en flaskehals, så dette punktet er vel mest en understrekning av at minne-buss og front side buss ofte forveksles. Kan også tilføye at CPU ofte er involvert i denne trafikken (i hvor stor grad vet jeg ikke, men det er helt sikkert applikasjonsavhengig), og når data i minne trenger en sving innom CPU før den går til GPU, vil IMC ha en latency effekt skulle jeg tro, men jeg vet ikke hva latency til dagens PCIe kontrollere ligger på, så for alt jeg vet kan effekten av IMC være neglisjerbar.

5) Godt poeng AJ, teoretisk ytelse under ideelle forhold, og reell ytelse er to forskjellige ting, blir spennende og se om dette kan gi FSB-baserte løsninger for Xeon et løft.

[Anders Jensen]

Minnebuss og FSB er to fysisk adskilte ting ja. CPU er selvfølgelig inne å orkestrerer det hele selv når GPU skal aksessere minnet, i allefall inledningsvis. Å laste opp en tekstur til GPU skjer vel ved noen få bytes med kommandoer og data sendes til GPU etterfulgt av noen megabytes med DMA trafikk. Om noen år kan du bytte ut MB med GB, men fortsatt anta noen få bytes kommando + data fra CPU. Klart det er en god del realtime oppdateringer som går fra CPU til GPU også, men desse har ikke noe direkte med GPU minne kommunikasjonen å gjøre.

 

Når det gjelder fremtidige løft på FSB arkitekturen så har vel IBM X3 chipsettet allerede lagt lista for hva en kan forvente. Selv om 4 sokkler per FSB er dømt til å være en ellendig overall løsning så er FSB som konsept så fleksibelt at det kan gjøres mye spenstig. På Xeon er vel nevnte X3 samt bensley platformen å nevne. På IPF er det i ferd med å komme veldig mye akkurat nå. Det ryktes at benchmarks med blandt annet SGI sine high bandwidth blades til Altix 4700 (10,6GB/s per kjerne i konfigurasjoner på optil 512 kjerner) skal komme om et par ukers tid (kanskje ikke akkurat den konfigen.). Også HP zx2 og sx2000 står på trappene. Det er altså en god del FSB chipset på trappene og de vil kværke mange av ulempene til dagens systemer.

[snorreh]

Jeg tar selvsagt også utfordringen!

 

1) Transistorene i Dothan er varmere enn de i Prescott.

5496224[/snapback]

Såvidt jeg vet så er "Dothan" designet til å håndtere temperaturer opptil 100 grader Celcius mens "Prescott" tåler maks 73 grader Celcius. Dette viser iallefall at "Dothan" kan kjøre vesentlig varmere enn "Prescott", noe som også ofte er tilfellet i bærbare PCer.

 

2) P4 arkitekturen liker båndbredde bedre enn K8, mens K8 liker lavere forsinkelse bedre enn P4.

5496224[/snapback]

Hvis du snakker om minne så er det liten tvil ifølge dette:

http://www.pcstats.com/articleview.cfm?articleid=873&page=6

 

3) FSB er en flaskehals for kommunikasjon fra GPU og I/O til RAM.

5496224[/snapback]

Ettersom den totale systembåndbredden i et FSB-system deles mellom minne og I/O, så kan FSB representere en flaskehals når både CPU og I/O prøver å kommunisere med minnet samtidig. F.eks. i SMP-systemer:

http://www.anandtech.com/IT/showdoc.html?i=1982&p=3

 

Hvis du tenker på DMA, så kan det også bli et problem for Intels FSB-baserte EM64T-prosessorer i 64-bit med mer enn 4GB minne:

http://www.redhat.com/docs/manuals/enterpr...-x86_64-en.html

Intel EM64T does not support an IOMMU in hardware while AMD64 processors do. This means that physical addresses above 4GB (32 bits) cannot reliably be the source or destination of DMA operations. Therefore, the Red Hat Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB at boot time. This is likely to result in lower performance for IO-intensive workloads for Intel EM64T as compared to AMD64 processors.

 

4) Integrert minnekontroller på CPU gir lavere forsinkelse mellom GPU og RAM.

5496224[/snapback]

Ikke med DMA, men i kombinasjon med en integrert HyperTransport-hub på CPU så gir det lavere forsinkelser totalt sett. Spesielt på systemer med integrert grafikk som benytter seg av system-minnet så har dette vist seg å ha en merkbar effekt.

 

5) To dobbelkanals minnekontrollere har samme ytelse som en firekanals minnekontroller. Gitt at de har samme karakteristikk på kanalene.

5496224[/snapback]

I et SMP system med Opteron der hver prosessor har dediserte minnebanker og med et operativsystem som støtter NUMA så er iallefall dette tilfellet:

http://www.gamepc.com/labs/view_content.as...onmemory&page=3

http://www.gamepc.com/labs/view_content.as...onmemory&page=6

 

Fortsettelse følger...

Endret 29. januar 2006 av snorreh

[snorreh]

6) Stor cache yter alltid bedre enn liten cache.

5496224[/snapback]

Nei, f.eks. så var "Prescott" sin 1MB cache merkbart treigere enn "Northwood" sin 512KB cache ifølge dette:

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

 

7) Inclusive cache yter alltid bedre enn exclusive cache fordi en får større kapasitet gitt samme transistorbudsjett.

5496224[/snapback]

Nei, men eksklusiv cache yter bedre enn inklusiv cache da det reduserer tilgangstid og båndbreddebruk ifølge dette:

http://www.ece.mtu.edu/faculty/btdavis/papers/ispass04.pdf

 

8) Hyperthreading (SMT, Altså ikke slik som på Montecito) er generelt bedre på kjerner med dyp pipeline enn på kjerner med kort pipeline.

5496224[/snapback]

Ikke nødvendigvis, men SMT har vist seg å fungere generelt bedre på kjerner med en dyp og smal pipeline fremfor kjerner med en kort og bred pipeline.

 

9) SMT bidrar kun til å utnytte til å gjemme forsinkelse til minnehierarkiet (RAM + cache) samt at en kan utnytte ledige ressurser i kjernen der det er mulig.

5496224[/snapback]

Ja, ifølge dette:

http://arstechnica.com/news/posts/1074838905.html

hyperthreading is also essentially a latency-hiding technique as well, in the sense that in the case of a cache miss the processor can (ideally) fill up the available execution slots with instructions from another thread.

 

10) Det finnes systemer som skalerer lineært. (F. eks Opteron og SGI Altix.)

5496224[/snapback]

Ja, hvis du tenker på Stream-benchmarken så gjør det absolutt det Ytelsen til den integrerte minnekontrolleren i Opteron har forøvrig vist seg å øke super-lineært med klokkefrekvensen.

 

Nå skal jeg ut å feire den ekte dual fjortis dagen min. Crossbar i taket.

5496224[/snapback]

Gratulerer, og her har du en liten vits fra meg som du kan kose deg med:

AFGHANISTAN - YBN Today it was confirmed that Osama Bin-laden was killed as a Cruise Missile, manufactured by Strongbad Industries asploded near his hideout. The Cruise Missile was equipped with an HP computer guidance system which employed an Intel Itanium processor. The missile missed the target, but Mr. Bin-laden was struck in the head by the processor's heatsink and died later from the injury.

Tenker den satt helt inne ved stolperota

Endret 29. januar 2006 av snorreh

[Gjest Slettet+6132]

Da har jeg en liten vits som du kan kose deg med:

AFGHANISTAN - YBN Today it was confirmed that Osama Bin-laden was killed as a Cruise Missile, manufactured by Strongbad Industries asploded near his hideout. The Cruise Missile was equipped with an HP computer guidance system which employed an Intel Itanium processor. The missile missed the target, but Mr. Bin-laden was struck in the head by the processor's heatsink and died later from the injury.

Tenker den satt helt inne ved stolerota

5512740[/snapback]

 

He-he...

Bra "snorreh".. bra..

Intel er da brukandes til noe.. (dersom det hadde vært sant da)..

Endret 28. januar 2006 av Slettet+6132

[Muffinman]

"Prescott" sin 2MB cache merkbart treigere enn "Northwood" sin 1MB cache

NW sine 512KB og Prescott sin 1MB vel...

 

Dette er vel avhengig av klokkefrekvens. Prescott var vel tregere på det meste enn NW helt opp til den høyeste klokkede NW på 3.4ghz, men et sted omkring 3.5-3.6ghz går det et skille hvor Prescott drar fra NW. Gapet blir større jo høyere klokkefrekvens når alle andre faktorer er like. Uansett ingen oppgradering fra NW så lenge den ikke kom klokket til 4.0 ghz + som standard...

 

Prescott for min del er en måte å få masse morro med overklokking - samt å holde liv i S478 - plattformen en stund til før jeg bytter. Frister med et skikkelig PC4000 2GB DDR-sett...og så bytter vi til s939 like før AMD går over til DDR2 slik at minnet kan brukes videre...kanskje.

[snorreh]

"Prescott" sin 2MB cache merkbart treigere enn "Northwood" sin 1MB cache

NW sine 512KB og Prescott sin 1MB vel...

5513180[/snapback]

Stemmer, rettet opp!