Test: AMD FX-8350

[Del]

Bare en kommentar: Husker du for et par sider tilbake hvor jeg argumenterte for at kompilering ikke skalerte så bra som du gav uttrykk for?

Ta en pille. Kompilering er typisk godt egnet til å bruke flere kjerner, det skalerer meget godt med antall kjerner. I tilfellet her så taper du drøyt ti prosent ytelse fra 2 til 8 kjerner med FX-8350, hvorav knapt sju prosent fra 4 til 8 kjerner. Ikke legg ord i munnen min er du snill.

i5-3570 som burde være sammenligningskandidaten er dessverre ikke med i diagrammet, men vi vet at den er 200 MHz raskere enn i5-3470, så all fornuft skulle vel tilsi rundt 90-100 i grafen der?

Godt muliig, men i5-3470 har omtrent samme pris, og er derfor riktig sammenligning. Hvordan du kan få 90-100 (altså omlag 20% ytelses hopp med omlag 6% frekvensøkning) er en myte for meg. Den vil nok lande på omlag 107 sekunder, eller drøyt 30% mer enn FX-8350.

Vennligst forklar meg hvor den store fordelen av de åtte kjernene vises i komplileringen.

Som sagt knapt 7% mistes fra 4 til 8 kjerner på grunn av manglende skalering. Du har de harde tallene her:

http://www.phoronix....multicore&num=3

som du ser er alle åtte kjernene med å sørge for at ytelsen blir høy.

Hvis Phoronix hadde hatt en i7-3930K disponibel, hadde den fremdeles blitt slått av en FX-8350?

Jeg har nå skrudd sammen mitt nye system med nytt hovedkort, 32GB ram fra Corsair og FX-8350. Totalt kostet dette nøyaktig 3000,- (riktignok uten frakt). Du sammenligner dette med en CPU som alene koster 4000,- Ja, du får like god eller bedre ytelse med i7-3930 omtrent over hele linja, men regn ikke med at kompileringen vil utgjøre noe mer enn 30-40%, altså den samme gevinsten jeg nå innkasserer over likeprisede Intel CPU'er.

Du har vel prøvd ny BIOS?

Nei, får se om jeg tar en titt på det når jeg får tid. Endret 26. februar 2013 av Del

[siDDis]

Vi veit alle godt at Intel er raskare per kjerne. Men for servere så er ytelsen til Bulldozer betre og den har støtte for ECC. Og du trenger ikkje å dra inn Cinebench som er eit Windows program som er troleg kompilert med GENERIC CPU Type og Intel kompilator.

 

GCC 4.6 har ikkje støtte for bdver på vanlig vis heller i følgje dokumentasjonen http://gcc.gnu.org/o...64-Options.html

[efikkan]

Som sagt knapt 7% mistes fra 4 til 8 kjerner på grunn av manglende skalering. Du har de harde tallene her:

http://www.phoronix....multicore&num=3

som du ser er alle åtte kjernene med å sørge for at ytelsen blir høy.

Testen spesifiserer ikke hvilke kjerner som er i bruk, som også ble etterspurt i forumet til Phoronix. Det er forskjell på 2 fullt aktiverte moduler og 4 aktive moduler med én aktiv kjerne i hver.

Hvis den reelle ytelsen skulle være slik du impliserer så vil én Intel-kjerne være nesten dobbelt så kraftig som én AMD-kjerne (siden i7-3770K ~ FX-8350, pris irrelevant i denne sammenheng), noe vi begge vet ikke stemmer. Jeg ville ha med kraftigere Intel-CPUer som referanse i sammenligningen, pris er irrelevant til det.

 

Nei, får se om jeg tar en titt på det når jeg får tid.

Du bør i det minste sjekke hvilken BIOS-versjon som følgte med, produsenten bruker typisk ikke å bytte dette etter lansering med mindre de må, så den kan gjerne være opp mot et år gammel.

 

Vi veit alle godt at Intel er raskare per kjerne. Men for servere så er ytelsen til Bulldozer betre og den har støtte for ECC. Og du trenger ikkje å dra inn Cinebench som er eit Windows program som er troleg kompilert med GENERIC CPU Type og Intel kompilator.

GCC 4.6 har ikkje støtte for bdver på vanlig vis heller i følgje dokumentasjonen http://gcc.gnu.org/o...64-Options.html

Jeg tror changelog er mer presis enn medfølgende dokumentasjon. Testene til phoronix er klare beviser, med mindre du mener disse er forfalskninger?

 

ECC-støtte fra Intel var ikke så dyrt som jeg trodde:

Intel Xeon E3-1245

Intel Xeon E3-1230

 

Det skal sies at Linux har den fordelen at mye av programvaren kan rekompileres med optimaliseringer, mens en del Windows-programmer gjerne henger et par år bak.

[Del]

Testen spesifiserer ikke hvilke kjerner som er i bruk, som også ble etterspurt i forumet til Phoronix. Det er forskjell på 2 fullt aktiverte moduler og 4 aktive moduler med én aktiv kjerne i hver.

Jaggu, du har et poeng. Ser det er en tendens til at skaleringen fra en til to tråder er dårlig. Dette gjelder også i7 2630QM. Jeg får teste dette litt når jeg får anledning. Spørs om Siddis har et godt poeng da, det er rimelig lett å endre scheduling.

[efikkan]

Det er viktig å sjekke om nummereringen internt i Linux er den samme som i BIOS også, f.eks. for Intel-CPUer med HT kommer én pipeline fra hver kjerne først, deretter den sekundære fra hver. Dvs. kjerne 1 og 7 hører fysisk sammen for i7-3930K, 1 og 5 for f.eks. i7-3770K. Jeg har ikke sjekket mappingen fra det som vises i Linux ned på maskinvare-nivå.

 

Edit: Jeg har ikke studert schedulingen i Linux nok på kode-nivå, men i utgangspunktet tror jeg den skiller mellom primær- og sekunder-kjerne på HT-CPUer. Her er et bilde jeg akkurat tok fra en av mine PCer, med mange programmer kjørende. De røde strekene er HT, så du ser tydelig hvor mye eller lite HT hjelper, og det er tydelig at kernelen favorerer de 6 første "kjernene".

BTW: Lasten må over 40% før noen av kjernene mine klokkes over 1.2 GHz, så selv med denne lasten er alt rolig og kjølig. Dette er lasten fra én VM, to nettlesere (100 faner), gimp, xbmc(web-TV), totem, transmission og en rekke andre programmer samtidig.

Endret 26. februar 2013 av efikkan

[Chiron]

Det er vel for å ha minst mulig variert hardware utenom prosessoren, slik at det ikke kommer andre faktorer inn og forstyrrer resultatet.

 

"Forstyrrer resultatet"? Det er jo resultatet som teller, og da helst med CPU'ens minnehastighetsstøtte etc. med den raskeste RAM'en?

[Chiron]

 

VELDIG bra! Og knusende i forhold til Intel's CPU'er b¨de mht resultat og pris. ;-)

Multithreading er vel ikke så utbredt i Windows enda (utenom i konvertering/transcoding etc), men det kommer! Og da er de med FX-8350 klar til dyst!

[Chiron]

Etter litt refleksjon ender jeg opp med å tenke følgende :

 

*Det er ganske imponerende at Amd greier å forbedre ytelsen med ca 20% på 32nm mens intel sin Ivy Bridge ikke er så langt unna, da blir det morsomt å se hvilke resultater man kan få med lavere nm.

 

*Ytelsen har hovedsakelig blitt testet i Windows 7 home på 1333Mhz og man har ikke prøvd å teste ytelsen i Windows 8 hvor scheduleren skal sørge for noe bedre ytelse. Windows 7 med hotfixes kan yte alt fra noen få % til opp mot 10% bedre avhengig av tester som jeg forstår det.

 

Sånn sett så føler jeg at FX 8350 er et godt steg videre i riktig rettning, lavere nm vil sannsynligvis øke hastigheten og ytelse per kjerne samtidlig som TDP synker noe. Nå er jeg ikke noe ekspert på krymping men jeg antar at krympingen til 22nm tillater en videre økning av antall transistorer og ytelse per kjerne.

 

Jeg sitter uansett på et 990FX hovedkort og sånn sett så vil dette være en grei oppgradering fra min 1055T.

 

Samme her, kjøpte AMD FX-8350,ASUS M5A99FX Pro R2.0 med AM3+, og Corsair Vengeance 2x4Gb DDR3 istedenfor FM2-sokkel, da jeg kan bytte frem og tilbake cpu'er, og rambrikker etter hvor de behøves. ;-) Praktisk. ;-) Og BILLIG! Og...... KRAFTIG! :-D

 

Mvh

Chiron

[Del]

Det er viktig å sjekke om nummereringen internt i Linux er den samme som i BIOS også, f.eks. for Intel-CPUer med HT kommer én pipeline fra hver kjerne først, deretter den sekundære fra hver. Dvs. kjerne 1 og 7 hører fysisk sammen for i7-3930K, 1 og 5 for f.eks. i7-3770K. Jeg har ikke sjekket mappingen fra det som vises i Linux ned på maskinvare-nivå.

 

Edit: Jeg har ikke studert schedulingen i Linux nok på kode-nivå, men i utgangspunktet tror jeg den skiller mellom primær- og sekunder-kjerne på HT-CPUer. Her er et bilde jeg akkurat tok fra en av mine PCer, med mange programmer kjørende. De røde strekene er HT, så du ser tydelig hvor mye eller lite HT hjelper, og det er tydelig at kernelen favorerer de 6 første "kjernene".

Da har jeg testet. Modulene befinner seg i rekkefølge. Altså kjerne 0 og 1 er i en modul, kjerne 2 og 3 i neste osv. Da har jeg fått et brukbart bilde av performance hit ved å kjøre på en modul fremfor å spre trådene på flere også.

 

Lasted ned Stream og Nasa parallel benchmarks (NAS NPB som Phoronix bruker). Litt morsomt å se at alle ti benker i NPB kompilerte på til sammen under ti sekunder på FX-8350

 

Så til svarene, minnebåndbredde gir beskjeden hit (uoptimalisert gcc kompilert, med open64 får jeg mye bedre ytelse, men den velger selv kjerner). På samme modul:

Function Rate (MB/s) Avg time Min time Max time

Copy: 6667.3817 0.0194 0.0192 0.0196

Scale: 8118.7852 0.0159 0.0158 0.0160

Add: 8460.0780 0.0228 0.0227 0.0230

Triad: 8851.9524 0.0218 0.0217 0.0220

 

På forskjellige moduler (fortsatt to tråder):

Function Rate (MB/s) Avg time Min time Max time

Copy: 6485.5931 0.0198 0.0197 0.0199

Scale: 8727.6215 0.0147 0.0147 0.0148

Add: 8293.4066 0.0232 0.0232 0.0232

Triad: 10922.6667 0.0176 0.0176 0.0177

 

Ellers er det varierende. Nasa sin ep.A som burde være beregningsmessig tett viser faktisk samme tendens, altså kun fem prosent forskjell. Store utslag får jeg derimot med konjugert gradient metoden (som i utgangspunktet burde ligne ganske mye på stream siden kjernen er multiplikasjon med glissen matrise):

To tråder samme modul: Mop/s total = 1278.09

To tråder forskjellig modul: Mop/s total = 1875.63

 

Så dette er rimelig uforutsigbart. Til orientering kjørte jeg O2 optimalisering for NPB med gfortran for å stresse flyttallsberegning ekstra (Phoronix bruker ingen optimalisering).

 

Kan også nevne at linux sin scheduling virker meget godt. Den sprer lasten over flere moduler, så med to tråder får jeg samme ytelse uten å gjøre noen ting, som jeg får ved å tvinge lasten på to forskjellige moduler.

 

Når det gjelder en-trådytelse (som sikkert er fristende å bruke her), så kan den ikke brukes for sammenligningen, rett og slett fordi AMD prosessorer fra og med første quad core phenom trenger to tråder for å makse ut minnebåndbredden.

Endret 27. februar 2013 av Del

[Del]

Hm, dette ser ut til å ha lite med delt flyttallsenhet å gjøre. Testen is.A som er en integer test gir forholdsvis stort utslag:

Samme modul: 155 Mop/s

Forskjellig modul: 226 Mop/s

 

Ser ut til at det er dekoding, issue vidde, eller evt.. OoO motoren som har noen delte ressurser per modul.

[efikkan]

Det blir interessant lesestoff om du benchmarker mer, men du må omtrent programmere testene og tilegne riktige kjerner for å få frem interessante tester. Som nevnt er benchmarks som C-Ray dårlig, og Smallpt helt ubrukelig, siden de er så elendig designet at de ikke får frem de egenskapene ved CPUene vi vil teste. Pov-Ray er et godt hakk bedre. Problemet med de som har designet de to nevnte testene er at de har kun tenkt på å lage noe som er tungt, uten forståelse for at så enorm branching vil gjøre at kjernene er "ubrukt" trolig over 90% av tiden. Når Bulldozer har en fordel akkurat her, så er det riktig nok en fordel pga. flere kjerner, men fremdeles irrelevant siden dette ikke er et realistisk bruksscenario. Del du er trolig voksen nok til å forstå hva jeg mener her, og at dette ikke er noe fanboyisme. Bulldozer sin teoretiske regnekraft er ikke det som redder den her, det er rett og slett kode som er så dårlig at Bulldozer får litt for stor fordel i forhold til et realistisk scenario (Pov-Ray er litt bedre referanse).

 

Jeg tror du og jeg har en relativt lik formening om hva Bulldozer burde være, for på papiret ser den veldig lovende ut. Jeg hadde stor entusiasme før Bulldozer kom på markedet, for jeg mener absolutt det ligger en nøkkel i prinsippet om at ikke alle kjerner bør ha 100% dedikerte ressurser for optimal utnyttelse. Bulldozer-konseptet hadde faktisk 4 integer pipelines i én modul, så det blir spennende om dette er noe som kommer etterhvert. Og jeg er absolutt ening i at Bulldozer burde være kongen over kompilering, spesielt siden FPUen ikke skal stresses i det hele tatt der. Selv med AMDs litt underlegne prefetcher og lengre pipeline så burde det i teorien være et potensiale her med flere kjerner. Men når AMD bruker to kjerner og så vidt slår én Intel-kjerne(med HT) så er det tydelig at praksis skiller seg fra teori. Jeg tror en kraftigere prefetcher kunne gjort at AMD virkelig kunne sprintet fra Intel her, såpass at de kunne hamlet opp med Intels sekskjerner. Jeg håper du forstår hvorfor jeg reagerer når folk sier de anbefaler FX-8350 over i5-3570 fordi Bulldozer har 8 kjerner, det blir liksom litt som å argumentere for en sportsbil som har fartssperre på 90 km/h. Det er ytelsen i praksis som teller, om den ene CPUen har 4 kjerner og den andre har 40 er for kunden irrelevant med mindre dette påvirker ytelsen tydelig, spesielt hvis det ikke skalerer som forventet og det svis av "unødvendig" effekt. Hadde Bulldozer fungert som jeg ønsker hadde den vært en superprosessor til arbeidsstasjoner, og da hadde den selvsagt vært et kupp for denne målgruppen selv om den er varm.

 

Vishera rev. 2 kommer vel samtidig som Haswell? Jeg er spent på hva AMD bringer til bordet denne gangen, for hvis de får ytelsen jevnt over litt bedre (eller CPUen kjøligere) så spriket til Intel minker litt, og fikser der Bulldozer burde skinne, så hadde FX-prosessorene i det minste vært et riktig godt valg for noen. Både AMD og programvareutviklere har en jobb å gjøre for at Bulldozer skal fungere bedre, og AMDs design er mer avhengig av tilpasninger enn det Intels design er. Igjen Linux har en fordel her, siden generelle optimaliseringer kan relativt lett brukes i mye programvare, pluss at optimaliseringer på kjernenivå kan komme raskere. Linux er allerede god på scheduling, men jeg tror at den kan bli ennå mer bevisst på hva hver enkelt thread gjør slik at den kan fordele dette ennå bedre. Hvis en thread hadde et flagg som sa noen om f.eks. FPU-last så kunne den lettere fordelt denne lasten slik at kjerner hadde minst mulig dødtid. En Bulldozer-modul med sine to logiske kjerner har riktig nok "tre" pipelines, derav de to int-pipelinene deler den tredje FPU-pipelinen med scheduler. Her mener jeg det er større potensiale for operativsystemer. I tillegg har som sagt AMD en jobb å gjøre med prefetcheren. Selv om de har lengre pipeline så kostnaden med branch misprediction er større, så er jeg veldig sikker på at de kunne med en kraftigere prefetcher mer enn veid opp for dette i programmer som har veldig mange threads, slik at de ikke bare er litt bedre enn Intel, men blir mye bedre. Gjør de dette, så mener jeg fremtidige Bulldozer-derivater kan bli en kanon-CPU til visse bruksområder.

 

På drømme-ønskelisten min er også instruksjoner som kan sammenligne flere registre samtidig. Med kompilator-optimalisering så kunne slike instruksjoner drastisk redusert antall branches og dermed økt ytelsen deretter i kode med flere klausuler i if-statements, som er den største kilden til uforutsigbar branching. (Fy! Fy! Dårlige kodere!)

 

Litt på sidelinjen så er det én ting som ofte har forbauset meg i møte med andre programmerere som har lært det i høyskole-/universitetssammenheng at de ukritisk bruker floats straks de skal behandle et desimaltall. Hvis du skal kode med desimaltall innenfor et relativt begrenset tallområde og ønsker konstant presisjon så er float en veldig dårlig idé, og det er heller ikke det det er designet til. Folk tenker ikke over at de kan bare behandle int som om det var dividert med en konstant, eller som at x antall bits representerer desimaler. Interessant nok så har jeg funnet ut at en del kyb-folk fra NTNU vet mer om slikt enn typisk datateknikere, og jeg vet at jeg vil fornærme mange jeg har gått i klasse med når jeg sier det, men jeg tør påstå at mange av de som går kyb lærer mer nyttig om programmering. Men hvorfor nevner jeg dette her, selvsagt vil alle CPUer ha fordel av at int brukes der det kan. Jeg mener at mange programmer unødvendig mye flyttall med float som datatype, og selv om dette koster for alle CPUer så blir det en liten ekstra bremsekloss for at Bulldozer får vise sitt fulle potensiale. Jeg tør påstå at om flere programmer var slik jeg ønsker, så hadde Bulldozer hatt større fordel over Intel enn de har i praksis i dag.

[Del]

Det blir interessant lesestoff om du benchmarker mer, men du må omtrent programmere testene og tilegne riktige kjerner for å få frem interessante tester.

Det er jo det jeg har gjort. Svarene er ganske tydelige. Bare spør hvis det er noe jeg bør forklare bedre.

Del du er trolig voksen nok til å forstå hva jeg mener her,

Joa, men det kan virke som om du er litt ivrig etter å diskreditere AMD. For meg var det mye frem og tilbake før jeg tok beslutning om hva jeg skulle kjøpe, og det avgjørende var AMD's ledelse på en del vesentlige oppgaver som var viktige for meg.

Bulldozer-konseptet hadde faktisk 4 integer pipelines i én modul, så det blir spennende om dette er noe som kommer etterhvert. Og jeg er absolutt ening i at Bulldozer burde være kongen over kompilering, spesielt siden FPUen ikke skal stresses i det hele tatt der.

Se på tallene for is.A, det er åpenbart ikke bare FPU som er delt. Faktisk tyder det på at FPU ikke er stort mer delt enn integer ressursene, så her er det mer ute og går.

Men når AMD bruker to kjerner og så vidt slår én Intel-kjerne(med HT) så er det tydelig at praksis skiller seg fra teori.

Både Sandy bridge og i enda større grad Ivy bridge har flere transistorer enn Bulldozer, da gir det liten mening å sammenligne som du gjør her. Med HT så rapporterer Intel også åtte kjerner til OS, og bruker enda flere transistorer for å få det til. Du ha en antagelse her om at de åtte kjernene i bulldozer deler mindre enn de åtte i i7. Utfra det vi ser på benkene er ikke den forskjellen all verden. Det som skjer med i5-3570 er at den grunnet mangel på HT havner langt bak FX-8350 i en rekke relevante tester (kompilering er langt fra den eneste). På enkeltråd og spill er derimot i5 3570 kvassere, med varierende utslag.

[N o r e n g]

Både Sandy bridge og i enda større grad Ivy bridge har flere transistorer enn Bulldozer, da gir det liten mening å sammenligne som du gjør her. Med HT så rapporterer Intel også åtte kjerner til OS, og bruker enda flere transistorer for å få det til. Du ha en antagelse her om at de åtte kjernene i bulldozer deler mindre enn de åtte i i7. Utfra det vi ser på benkene er ikke den forskjellen all verden. Det som skjer med i5-3570 er at den grunnet mangel på HT havner langt bak FX-8350 i en rekke relevante tester (kompilering er langt fra den eneste). På enkeltråd og spill er derimot i5 3570 kvassere, med varierende utslag.

Sikter du til at en Ivy Bridge-quad er på 1400 millioner og en Bulldozer-octa er på 1200 millioner transistorer?

Tror det har mer å gjøre med at Ivy Bridge har en iGPU og integrert PCIe-kontroller, og at Bulldozer-moduler bruker masse plass på 2MB med L2-Cache.

 

Noe jeg lurer på er hva poenget er med 2MB L2 Cache per modul og 8MB L3 Cache på brikka er, det tar jo opp en massiv andel av brikka.

[efikkan]

Joa, men det kan virke som om du er litt ivrig etter å diskreditere AMD. For meg var det mye frem og tilbake før jeg tok beslutning om hva jeg skulle kjøpe, og det avgjørende var AMD's ledelse på en del vesentlige oppgaver som var viktige for meg.

Om det er én produsent jeg har nær hjertet så er det AMD.

 

Se på tallene for is.A, det er åpenbart ikke bare FPU som er delt. Faktisk tyder det på at FPU ikke er stort mer delt enn integer ressursene, så her er det mer ute og går.

De har separate Integer-pipelines, men de sliter likevel med flere oppgaver som ikke stresser FPUen pga. "starving", dvs prefetcheren ikke er kraftig nok til å holde kjernene i arbeid. (enkelt forklart) De har delt prefetcher som kan gå veldig bra så lenge branching er under et bestemt nivå, men blir det for mye så ligger CPUen mer og mer brakk.

 

Både Sandy bridge og i enda større grad Ivy bridge har flere transistorer enn Bulldozer, da gir det liten mening å sammenligne som du gjør her.

Jeg refererte faktisk ikke til transistortall i det hele tatt, men at Bulldozer markedsføres som en 8-kjerne, og at mange anbefaler den fordi den "skalerer som en 8-kjerne". Hvis der var relevante bruksområder hvor 8-kjerne-designet hadde gitt Bulldozer en avgjørende fordel over Intel så hadde det vært et gyldig argument, men når det ikke er det så blir kjerneantallet irrelevant. Ytelse i praksis, effektforbruk i praksis osv. er det som teller, ikke hva en CPU i teorien burde klare.

 

Du ha en antagelse her om at de åtte kjernene i bulldozer deler mindre enn de åtte i i7. Utfra det vi ser på benkene er ikke den forskjellen all verden. Det som skjer med i5-3570 er at den grunnet mangel på HT havner langt bak FX-8350 i en rekke relevante tester (kompilering er langt fra den eneste). På enkeltråd og spill er derimot i5 3570 kvassere, med varierende utslag.

HT kan ikke betraktes som egne kjerner, HT og Bulldozer-moduler kan ikke sammenlignes. HT forsøker å øke ytelsen til én kjerne mot sitt teoretiske maksimale, altså mot 100%. Bulldozer har to amputerte kjerner i forsøk på å oppnå dobbel ytelse av én kjerne, altså 80-90% * 2.

 

Det er sant nok at Bulldozer gjør det bra i kompilering og NAS-testene mot Intel til samme pris, men fordelen her er ikke såpass stor som den burde være. Hadde Bulldozer-designet fungert så bra som det skulle så burde det totalt knust Intel i NAS-benchmarks.

[Del]

Sikter du til at en Ivy Bridge-quad er på 1400 millioner og en Bulldozer-octa er på 1200 millioner transistorer? Tror det har mer å gjøre med at Ivy Bridge har en iGPU og integrert PCIe-kontroller, og at Bulldozer-moduler bruker masse plass på 2MB med L2-Cache.

Sandy Bridge E eksempelvis har ingen grafikk såvidt jeg vet, så jeg sikter til at jeg oppfatter det slik at i7 bruker flere transistorer på åtte tråder enn det Bulldozer gjør. Hvorvidt det er modul (bulldozer) eller HT (i7) er ikke all verdens forskjell. I begge tilfeller deler de ressurser mellom to tråder/prosser, i ingen av tilfellene har du åtte fulle kjerner. AMD sitt design gir dårligere singeltrådytelse, men skalerer bedre. Dette gjør at Intel typisk er å foretrekke for singeltrådlast, mens på samme prisnivå er ofte AMD best på parallell last.

prefetcheren ikke er kraftig nok til å holde kjernene i arbeid. (enkelt forklart)

Godt mulig det er prefetcheren som gir utslaget, men jeg synes det er vasnkelig å konkluderer. Verken Intel eller AMD deler detaljer ved sine design, så det blir fort spekulasjon. At Intel har bedre pre-fetching er det riktignok bred enighet om.

Det er sant nok at Bulldozer gjør det bra i kompilering og NAS-testene mot Intel til samme pris, men fordelen her er ikke såpass stor som den burde være. Hadde Bulldozer-designet fungert så bra som det skulle så burde det totalt knust Intel i NAS-benchmarks.

Nei, delt FPU burde straffet AMD mye mer enn det gjør. NAS benkene tyder på at arkitekturen til AMD funker bedre for flyttall enn det jeg og mange andre trodde. Hvor stor fordelen burde vært kan man diskutere så lenge man vil, poenget for meg er at forskjellen er stor ved samme prispunkt. Dette gjelder også relevante benker som 7zip, parallell bzip og x264.

[efikkan]

Sandy Bridge E eksempelvis har ingen grafikk såvidt jeg vet, så jeg sikter til at jeg oppfatter det slik at i7 bruker flere transistorer på åtte tråder enn det Bulldozer gjør. Hvorvidt det er modul (bulldozer) eller HT (i7) er ikke all verdens forskjell. I begge tilfeller deler de ressurser mellom to tråder/prosser, i ingen av tilfellene har du åtte fulle kjerner. AMD sitt design gir dårligere singeltrådytelse, men skalerer bedre. Dette gjør at Intel typisk er å foretrekke for singeltrådlast, mens på samme prisnivå er ofte AMD best på parallell last.

i7-3770K er ikke Sandy Bridge-E, heller ikke i7-2600K.

 

Godt mulig det er prefetcheren som gir utslaget, men jeg synes det er vanskelig å konkludere. Verken Intel eller AMD deler detaljer ved sine design, så det blir fort spekulasjon. At Intel har bedre pre-fetching er det riktignok bred enighet om.

Intel har en god dokumentasjon om arkitekturene sine. Men du kan få vite litt om AMD her.

[Del]

Ingen av dem dokumenterer arkitekturen ordentlig, ofte er det mer for reklame å regne. Siste prosessoren som ble dokumentert ordentlig var K6 fra AMD om jeg husker riktig. Kan godt rote frem boken til deg om du er interessert. Litt irriterende når du bemerker at i7-3770K ikke er Sandy Bridge E (som om noen har påstått det). Dersom du har ny informasjon om transistorantallet er det uendelig mer interessant. Her er en link med noen datapunkt:

http://www.anandtech.com/show/6396/the-vishera-review-amd-fx8350-fx8320-fx6300-and-fx4300-tested

[efikkan]

Her er et av dokumentene jeg brukte for en stund siden, det står en del i disse dokumentene fra Intel.

 

Sammenligningen til Arni var Ivy Bridge mot Bulldozer, det var du som trekte inn Sandy Bridge-E (med opptil 8 kjerner), men poenget ditt forblir uklart for meg.

[Del]

OK, la meg ta det en gang til. Den ene har åtte kjerner i fire moduler, mens den andre åtte tråder ved fire kjerner med HT. Hvis HT bruker vel så mange transistorer, så er det kanskje ikke all verdens forskjell på disse to fremgangsmåtene. Så bemerker Arni at transistorantallet avhenger av grafikkdelen på CPU. Tallene jeg hadde inkluderte Sandy Bridge E, og ga samme bilde, altså at Intel bruker flere transistorer selv om du ekskluderer grafikkdelen. For ditt argument om at AMDs åtte kjerner burde gitt mye høyere ytelse, vel det argumentet blir jo da bare tull.

[Del]

Her er den siste boken jeg kjenner til som dokumenterer x86 CPU arkitektur utover de vanlige reklame slidene fra Intel og AMD (ok da, kompilator optimaliseringer gir litt ekstra info, men det er fortsatt snakk om reverse engineering sammenlignet med ordentlig dokumentasjon):

http://www.amazon.com/Amd-K6-3d-Processor-Howard-Kalish/dp/1557553459/ref=sr_1_1?s=books&ie=UTF8&qid=1362075361&sr=1-1&keywords=k6+amd

Legg blant annet merke til at mange liker å diskutere deocde, OoO, pipleline lengde. Alle disse begrepene er helt avhengig av hvordan microoperasjonene ser ut. Når var sist Intel fortalte oss hvilke mikrooperasjoner en av deres x86 prosessorer bruker?