Intel Nehalem ger ordentlig prestandaskjuts

Ja postade tidigare upp två länkar som visar på Intels problem, förstår du dessa länkar?

http://www.nehalemnews.com/2008/05/editorial-need-for-imc-and...
http://www.intel.com/technology/quickpath/demo/demo.htm

Jag tänker inte sitta och leta tester bara för att övertyga dig, du får helt enkelt lära dig tekniken eller fortsätta tro vad du tycker är rätt.

För egen del så brukar jag inte leta tester, ibland läser jag någon men det är sällsynt. Det är svårt och dra slutsatser från diverse tester någon sajt gjort eftersom man inte får reda på hur koden är utformad.

Jag skulle själv lätt kunna skriva två olika program där det ena går bra på intel medan det andra går bra på amd, bara man vet lite vad respektive processorer är bra på.

I ingen av länkarna nämns ens trådar och processer. Du kanske länkade fel?

Däremot nämner de behovet av snabbare I/O för framtida system, vilket säkert är riktigt.

Jag föreslår att om du inte vill ta fram stöd för dina påståenden så ska du inte heller presentera dem som fakt här på forumet. Många medlemmar är förvirrade nog som det är och skulle fler komma med påhittade teorier om saker och ting så skulle det väl inte till förmån för någon? Även om en del kan vara riktiga, inklusive denna.

Skriva program som gör både det ena och det andra kan vem som helst klara av med lite träning. Det är inte så att programmering är en svår konst precis.

Eftersom jag inte äger en phenom än så undrar jag om ditt påstående också inbegriper Athlon X2? Jag äger nämligen en sådan och kan testa själv på den eftersom du verkar oförmögen att skaka fram relevant underlag. Har jag tolkat dig rätt att det märks redan på dagligt bruk med en "sweclockares" normala last kört under windows? Lite mp3-kodning, xvid-kodning och samtidigt youtubetittande exempelvis? Här ska amdlägret "flyta" på bättre? Vad menas med flyta på bättre? Att byte mellan applikationer är mjukare/snabbare och/eller att ju fler jobb man slänger på maskinen ju mer skulle intelburken tappa i utfört arbete per tidsenhet?
Eller enklare uttryckt, om jag på exempelvis en dubbelkärnig intelhink skulle koda om fyra filmer samtidigt och det skulle ta 1 timme så skulle 12 samtidiga omkodningar ta exempelvis 3,5 timmar? Samma manöver på min amdhink skulle ta kanske 3,2 timmar? Tiderna är bara symboliska och ingen hänsyn har tagits till processorernas olika prestanda, bara åskådliggörandet av tappad cpukraft är intressant här.

Ok, men då förstår du inte tekniken.

Här kan du se förklarat varför Nehalem löser en hel del problem som funnits på intels quad. http://en.wikipedia.org/wiki/Cache_coherency

Problemet vid många trådar blir nämligen synkroniseringen av minne, även flödet av minne. 4 trådar som kör samtidigt kan tugga i sig mycket mer minne jämfört med en. FSB'n (som du kanske märkt är just det som är problemet) hinner inte leverera. Läste på någon sajt att en cachemiss på Intel innebär i runda slängar 250 klockcykler om det är "fri" passage för att gå ut och hämta nytt (inte alls påläst där så ta siffran med en nypa salt).

Denna fördröjning sker även när Intels quad skall synkronisera sina trådar och trådarna ligger på olika kärnpar. Det är bl.a. därför som det är mycket osmart och göra "små" trådar på Intel processorer idag, snarare tvingas man till och göra stora separata trådar som jobbar självständigt.

Tar du tiden på en längre operation som skall utföras så vinner Intel för det mesta idag. Låt säga att det tar 15 minuter på Intel och kanske 17 minuter på en AMD. Men vad du inte kan mäta med tiden är hur processorerna jobbar under tiden och det är där "flytet" kommer in. Drar du igång fler program så ogillar intel att bli "störd", möjligen blir den snabbare klar ändå om det andra programmet inte kräver så mycket kraft men det blir sämre flyt.
Om det är märkbart eller inte för användaren beror säkert på, framförallt vilka typer av program man kör och behovet av flyt.

När det "stockar" sig i FSB'n för Intel så stannar det upp lite, men så fort minnet ligger i cachen så gasar den igen. Du vet broms,gas,broms,gas, broms,gas. Medan det på AMD mer handlar om glid,glid,glid,glid eller hur man kan säga

Jag förstår tekniken mycket väl. Det jag ställer mig frågande till är om det verkligen märks så mycket som du ger sken av.

Skulle mitt förslagna test på min Athlon X2 kunna ha en teoretisk chans att påvisa problemet? Jag säger inte att det måste det, bara undrar om det är i en sådan situation som det kan uppkomma? Har du något annat förslag på test?
Är en Athlon X2 och en phenom tillräckligt lika i detta perspektivet för att vara jämförbara enligt dig?

Om du kollar här så kanske det skulle kunna vara något som ger indikation om hur du skulle kunna testa.
http://www.xtremesystems.org/forums/showpost.php?p=3008637&po...

Har gjort ett enkelt test nu där jag jämför min e6550 som kör vista på "huvudburken" här hemma och den jämför jag mot en testmaskin som för tillfället kör 2008 server som labburk. Jag drog igång ett gäng olika rarsessioner där den komprimerade filer från min filserver ner mot lokal disk. Varje rarsession kör två trådar för komprimeringen och jag testade 1,2,4,8 och 16 samtidiga "rarar" på varje maskin.

Resultaten är båda tämligen linjära med en liten tendens till att visa upp ett sådant beteende som du påstår skall finnas. Dock är det bara synligt om man sitter med stoppur och inget som märks för blotta ögat. Att sista resultatet för amdburken ser konstigt ut tror jag beror på att maskinen bara har 1 GB minne och den ligger väldigt nära max utnyttjande när 16 rarar är igång samtidigt.

Körde med max kompression och max ordlistestorlek så det borde vara ganska minnesintensivt.

Ska peta i mer minne senare och försöka köra 32 och 64 också.

Testresultat

Var det detta du menade när du skrev
"Nehalem har mycket färre klocks för att läsa från L3 än vad Phenom har" ?

Du skrev även att det inte gick och klocka upp L3 cachen mer, men nu skriver du att man kan försöka men att den då störtdyker.

Känner du till ordet "efterkonstruktion" ?

Har uppdaterat mitt test med nya siffror gjorda med tillräckligt med minne. Ser ut som om varken intel eller amd lider någon nämnvärd skada av att köra många lastade trådar.

Bra nyheter för AMD kanske? Vem behöver egentligen all denna kraft som Nehalem för med sig? Inte många. Vem är villig att betala allt vad det kostar för att få ett sådant system? Inte många. Intel lägger säkerligen enorma resurser på att utveckla denna platform, medans AMD just nu förbättrar nuvarande teknologier. Jag tror i alla fall att AMD har en enorm möjlighet att satsa på processor som intresserar den större massan av oss datoranvändare, samt de stora tillverkarna av datorer.

Det kan jag kalla full load. Det coola är ju att allt bara flöt på hur bra som helst utan lagg enligt honom. Ett sånt test ska jag också försöka testa när jag får igång min Phenom 9850 (fick den billigt) som jag har liggande i brist på moderkort än så länge.

Iaf, om jag har förstått det rätt så är Phenom bättre än C2Q på massiv multitasking med extrema mängder data som ska flyttas runt (typ det som behövs i servrar). C2Q styrka är däremot dess starkare beräkningsprestanda (vilket spel tjänar mer på).

Och Nehalem kommer alltså kombinera både massiv multitasking och extrem beräkningsprestanda, eller? Och Nehalems HT lär ju ytterligare öka dess prestanda i multitasking.

Håller med. Prestanda kan man aldrig få nog av så länge det inte är för dyrt eller drar för mycket effekt.

ta av dig intelglasögonen och fokusera på tekniken.

Den myten slog jag ju nyss hål på om du läser mitt test några inlägg "upp". Under 2-64 trådar med winrar på max kompression så skalade mina intelburkar i princip linjärt med lasten precis som min Amdburk. Winrar är som vi vet tungt på både minne och cpu.

http://www.dynga.com/bench.htm

Diskussion? har vi en diskussion tycker du?

Du kan nog lätt se själv vad detta är för typ av "diskussion".

måste bara fråga, förstår du själv vad du testat? Hur stor del av de testen du gjort handlar om diskaktivitet? Även om du sätter kompressionen på max för winrar så pratar du ändå om väldigt enkla komprimeringalgoritmer, den är exempelvis inte i närheten av om du komprimerar film och liknande.

Du får gärna ge en mer utförlig förklaring på dina test så man förstår vad du du testat. du har inte ens enheter i graferna

Men det är väl skillnad på att köra flera likadana trådor som är helt oberoende av varandra (som du gjort) och att köra trådar som delar data (då det tydligen ska vara viktigt med cache coherency som gosh pratar så mycket om). C2D, Phenom och Nehalem har väl delad cache så då behöver man ju bara gå ut i cachen för att synkronisera data. C2Q måste väl dock använda sig av den slöa FSB:en (och gå ut i minnet) för att synkronisera cache mellan de två dubbelkärnorna så det blir ju lite jobbigare. Athlon64 X2 har ju heller inget delat cache, men eftersom den har lite kortare väg till minnet så kanske den inte förlorar lika mycket som C2Q.

Å andra sidan så ska man väl göra sina trådar så oberoende som möjligt så att såna problem inte ens uppstår överhuvudtaget.

Nu är jag ingen programmerare och kan inte dessa saker så mycket utan jag har mest försökt läsa lite här och var om detta.

Intressant test, även om jag undrar vad det är du egentligen har testat. Som jag tolkar testet så ska tydligen din C2D vara klart snabbare än din X2 oavsett antalet trådar. Såg dock att prestandan med 2 trådar bara var lite snabbare (i båda fallen) än med 1 tråd (de är ju ändå dubbelkärniga), men det kan ju vara minnesbandbredden som begränsar. Iaf, med flera instanser så verkar din C2D tappa något mer prestanda än din X2.

Förresten, skulle du kunna normalisera körtiden dvs körtiden för 1 instans är lika med 1?

edit: squonk, tänkte bara säga att jag håller med dig i allt det du sagt hittills.

Rar är multitrådat och kör på flera kärnor. Att jag tog rar var dels på grund av detta och dels för att det var lättast att sätta upp en skapligt kontrollerad miljö där jag kunde upprepa förhållandena vid varje test. Det som inte var detsamma mellan testobjekten och som kan ha påverkat en aning är måldisken för arkiven. På min intelburk är det en 2.5" satadisk och på amdburken är det en 3.5" av skapligt modernt snitt. Det kan som sagt ha påverkat lite.

Det är inte snabbheten mellan processorerna som testas då man ju kan utgå från att en e6550 ska vara snabbare än en X2 3600+

X2an tog jag med bara för att testa någon annan arkitektur mest för skojs skull.

Det jag ville testa var om påståendet som Gosh framfört att intels processorer skulle tappa mer och mer prestanda ju fler trådar som kördes. Om så vore fallet så skulle vi inte få en näst intill rät linje på intelgraferna utan den skulle böja av mer och mer. Enligt Gosh skulle "böjningen" dessutom vara hiskeligt påtaglig, vilket den inte är. Den är snarare i det närmaste obefintlig.

Att normalisera skulle nog inte ge så mycket då det endast var linjäriteten inom samma processor ställt mot antalet trådar jag ville testa. E6550 är ruskigt linjär när man passerat 2 instanser (varje instans kör ju två trådar på den). Anledningen till att det skiljer mellan 1 och 2 instanser på samtliga är att det inte går att få maximalt utnyttjande av kärnorna med endast en instans körande.

X2an visar ett lite udda beteende till att dubbla antalet trådar kan vara aningens lite snabbare än dubbla tiden. Det känns ju lite udda egentligen, men skillnaderna är så små så för detta ändamålet kan det kvitta. Det kanske kan hänga ihop med den långsammare disken i intelhinken.

Slutsatsen är att alla processorerna är linjära med antalet trådar, oavsett antal kärnor, inklusive intels "fuskquad" som påståddes ha enorma problem då trådarna dessutom delar arbetsdata mellan cacharna och minnet.

Möjligt att sanningen är en annan om man kör fyra quad xeon på samma moderkort och gör samma sak? En singel "fuskquad" har i alla fall inte det problemet som påståddes.

Ingen som fortfarande läser denna tråden som kan ha en idé om vad för typ av test som skulle kunna ge ett sådant beteende som Gosh framhärdar? Gärna ett test som är oberoende av grafikprestanda då min esx bara stödjer rudimentär 2D.

Du menar att du tror att du skall kunna se någon skillnad om du räknar in diskaktivitet? Du kan i princip sätta vilken skitprocessor som helst i datorn om programmet samtidigt jobbar mot disk eftersom det tar så mycket mer tid.

Utöver det så angående problem med "cache coherency" så gäller det Intels Quad, det problemet finns vad jag vet inte på c2d, en c2d är en "riktig" tvåkärnig (det är lättare och synkronisera två kärnor jämfört med 4). "Enda" problemet som finns vid c2d är eventuellt flaskhalsar mot det vanliga minnet men det skulle förvåna mycket om man kan se det när man samtidigt jobbar mot disk. Möjligen att du däremot kan få mätbara skillnader om du har någon slags ramdisk.

Utöver det så är WinRAR en typ av hantering som i princip helt kan utesluta synkronisering av trådar. Nu vet jag inte riktigt hur de kodat men om du har en fil på 10 GB, så kan du teoretiskt skapa upp två trådar som kör helt separat och som betar av 5GB var med minimalt av "prat" mellan trådarna. Endast vid skrivning/läsning till disk krävs det en del mixning.

när man utvecklar databasapplikationer så kan man i princip utveckla dessa i vilket språk som helst, även om språket är seeegt som ... så spelar det ingen roll då hela applikationens prestanda avgörs av koppling till dator som har databas samt hur snabb databasen är vilket beror mycket på diskarna.

Då alla instanserna komprimerar samma data så läses denna endast en gång från disk, resterande gånger läses den från diskcachen. Då är det bara skrivprestanda som skulle kunna påverka.
Nu är det så att arbetet inom processorn är några magnituder större än arbetet med att skriva ut datat till disk så det kan vi nog försumma.

Tittar du noga så ser du även tester med min Q9450 och den visar inga problem heller.

Vi gör så här. Föreslå Du ett program som kan påvisa denna mytomspunna effekt så kan jag testa det också. Du behöver inte göra mer än att ge mig programnamnet och så kan jag gräva upp det själv.

Om det glädjer dig så kan jag även testa att köra komprimeringarna i en ramdisk? Det börjar verka komiskt dock att man måste ta till väldigt specialiserade testmetoder för att ens se en skymt av problemet som du påstod var så grovt och så allvarligt att du kände dig tvingad att varna folk i olika trådar för det.

En diskcache har liten betydelse. möjligen om operativet kan cacha upp data och helt struntar och gå ut på disken. Diskaktiviteter fungerar inte riktigt som en processor, loopar m.m. är mycket vanligt på en processor (man använder samma data om och om igen från litet område) , när det gäller disk så är det nästan bara inlässning/skrivning och sedan är det klart. Och även om det finns på diskens cache så gissar jag att hastighet mellan disk och minne inte är den bästa.

Jag tror det är svårt och dra några som helst slutsatser med de processorer du har så länge man inte har kontroll på källkoden (vet hur programmen är programmerade). Det är ju trots allt en 3600+ du sitter med och det är ju AMD's slöaste. Och det går nog inte genom att mäta tid, det handlar ju snarare om "små hack", alltså sämre flyt.

Har du någon databas och kan göra en tabell eller flera som ligger i minnet? Känner du till "memory tables" för MySQL exempelvis. Det skulle kunna vara ett sätt och testa skyffling av minne men jag tror ändå det är svårt och se något eftersom processorn är lite långsammare, möjligen är minnet också inte det snabbaste?

Läs lite av vad gosh har skrivit så fattar du nog att du omöjligt kan ha nåt problem i dina rar-tester. Dels har du en Core2Duo som inte har nåt problem med cache coherency och dels är dina instanser oberoende av varandra. Så du måste alltså ha en Core2Quad och ett program med trådar som är något beroende av varandra för att se stor skillnad mot Phenom.

I vilket fall som helst så är det sällan såna problem med vanliga spel och program, men visst finns det speciella fall där C2Q verkligen presterar kasst mot Phenom och det är ju ganska allmänt känt att Phenom skalar bättre med fler trådar. Se det som att Phenom och C2Q har olika styrkor helt enkelt.

Grafen längst till höger är på en Q9450 och oavsett om ni ogillar rar så är det också allmänt känt att windows i all sin visdom flyttar runt processer mellan kärnor för att fördela lasten och det i sig påtvingar också cachesynkroniseringar, dock inte lika ofta som man skulle vilja för att se problemet antar jag.

Nämn ett sådant speciellt fall. Tolka det inte som någon aggresiv utmaning eftersom jag verkligen är intresserad av att testa.

Som en parantes så påpekade herren Gosh i några länkar längre upp att just winrar fick fina resultat på phenom (tror jag det var) och att det indirekt skulle visa på att den där var märkbart bättre. Det var också därför jag valde rar som test. Skillnaden kanske är så liten att den försvinner i felmarginalen?

Problemet jag har haft innan här är att det är väldigt lätt att få folks åsikter, men det är mindre lätt att få konkreta fakta och länkar som berör min frågeställning och påståendet jag ifrågasätter.

Jag blev beskylld för att bara vilja höra att Intel är guds gåva till mänskligheten och att jag inte ville höra något annat. Jag börjar snart tro att beskyllningen borde returneras till avsändaren.

Angående att Windows flyttar trådar till bästa ledig processor så är det inte alls samma sak som synkronisering av cache utan det sker som du säger hela tiden. Alla operativ med SMP gör så. Något som ibland sägs när man kollar av spel och hur många kärnor de stödjer så brukar man ibland höra "det stödjer 4 kärnor" eller liknande. Det är ju inte helt korrekt utan bättre vore isåfall och säga att spelet använder sig av X antal trådar som mest, operativet kommer sedan placera tråden där den uppfattar att det finns ledig plats. Men om tråden kör ostört från andra trådar så behöver man inte bry sig speciellt mycket mer om den tråden, enda är och kolla av när den är färdig om det är maximalt fristående trådar.

Om du däremot har ett spel och det exempelvis skulle vara 10 gubbar som springer omkring, varje gubbe påverkar de andra beroende på vad de gör. Om varje gubbe även kördes i sin egen tråd (så skulle nog aldrig ett spel implementera gubbar men bara för att exemplifiera) så skulle alla trådar behöva accessa samma minne för var gubbarna befinner sig och vad de gör står i minnet. Eftersom varje kärna har sin egen lilla cache så när den kärnan läser in minne om vad någon annan gubbe befinner sig, under tiden så rör sig gubben vilket betyder att minnet förändras. då måste minnena synkroniseras eftersom varje kärna har sin kopia och en annan kärna har förändrat datat vilket gör att minnet inte är lika i de andra kärnorna som har samma kopia.
En annan sak som måste synkroniseras mellan kärnor är detta API'tEnterCriticalSection. Det är så man vanligen gör för att just skydda minne som används av flera trådar. Det underlättar för programmeraren eftersom den då kan försäkra sig om att ingen annan rör minnet just då aktuell tråd jobbar med det. desto fler sånna anrop desto mer ont i magen för en Intel Quad. Den typen av anrop tror jag knappt finns på Winrar.
läs om spinlock's här

dundermuppen:

FEAR gillar visst Phenom:

http://www.hothardware.com/Articles/AMD_Phenom_X4_9850_B3_Rev...

Lite WinRAR:

http://www.sharkyextreme.com/hardware/cpu/article.php/3261_37...

http://www.techspot.com/review/93-amd-phenom-9850-black-editi...

Här kommer en benchmark som visar att Phenom är 3,88 gånger snabbare med fyra trådar än samma beräkning med en tråd. Inte så långt ifrån vad det kan vara teoretiskt iaf. Rätt bra skalning.

http://www.techwarelabs.com/reviews/processors/amd_phenom_985...

Alltid nåt. Men annars är det svårt att hitta benchmarks som Phenom presterar bra i :(.

edit:

Nu blev jag lite gladare:

http://forums.techpowerup.com/showthread.php?t=58746

Testade lite cinebench i min virtuella server. Av tekniska skäl skulle det bli väldigt missvisande om jag körde med fyra kärnor så jag testade en variant. Jag gav maskinen två kärnor och förlade dem på vars en delkärna så att säga. Resultaten blev identiska med 1.93x skillnad.
Anledningen till att fyra kärnor i en virtuell maskin är dåligt på en esx som bara har fyra kärnor tillgängliga beror på att en virtuell maskin kan bara köra om alla fyra kärnorna är tillgängliga samtidigt. På denna esxkärra så finns det vissa serverfunktioner som inte får stängas av, bland annat mitt företags ena DNS Lasten är väldigt liten på helgerna på de andra programmen, men det skulle ändå bli "skevt".

När jag ställde in vilka kärnor den skulle använda noterade jag också att när jag sist körde mina rartest så var hela den virtuella maskinen begränsad till cirka 4000 MHz. Ska göra om och se om det blir någon skillnad.

Synd att bara kan testa på 2 kärnor max men 1,93 ggr är ju rätt bra. Känner mig rätt överbevisad nu egentligen och orkar knappt hålla på mer men jag vill fortsätta kolla på dina tester. Annars har du den outtröttliga gosh iaf.

edit:

Thomas, jag tittade inte så noga på SuperPI direkt. Men det kul att se hur bra det gick att köra Phenom på så låg spänning i hög klock iaf.

Jag upplever superpi som ett av de mer meningslösa programmen i världshistorien. Anledningen till att det är så poppis är nog mer att intelfolk gillar att se låga siffror än att det testar något viktigt. Då är cinebench och andra lite mer verklighetsnära tester bättre.

kanske skulle övertyga jobbet om att vi verkligen behöver en quad till i servern, då borde man kunna pressa den hårt nog så att fsb blir ett problem. Det är ju trots allt för sådana miljöer som intel tar inspiration från Amd till nästa generation.
Ett önsketänkade vore ju att ha två sorters fyrvägssystem, ett med qpi och ett med fsb. Där borde man kunna framkalla problemet betydligt lättare.

Problemet finns nog, men inte på singelprocessorsburkar. Åtminstone är det tämligen svårt att påvisa det där. Framför allt så är det inte så uttalat som det har gjorts gällande här och i andra trådar.

En variant som kanske skulle kunna framkalla det vore en qx-processor där man sänker fsbn så mycket det bara går utan att sänka processorhastigheten, då kanske man lättare kunde framkallat det hela.

Jag har varken qx-processorer eller fyrvägssystem som jag kan leka med så det får bli rena spekulationer från min sida.