Log In
Home
April 4, 2008
Offline
Mean Machine wrote: Jag har inga problem att erkänna att AMD gör bra processorer, problemet är bara att Intel är bättre som det är just nu, åtminstone om man sneglar det minsta mot överklockning. Förhoppningsvis kommer även Bloomfield överklocka riktigt fint, likt dagens E8xxx och Q9xxx.
Det är två olika arkitekturer och de är bra på olika saker. Vilken som är bäst beror på vilken typ av program man kör.
Problemet är att de som verkligen behöver prestanda brukar även behöva skalning i trådar. Medan "vanliga" program sällan behöver prestanda. Därför klarar en arkitektur som AMD's och kommande Nehalem även av vanligt användande. Men det motsatta kan innebära stora problem.
Ett spel som exempelvis skulle dra iväg 20 trådar på en Intel Quad kommer verkligen ha big problems. Nu tror jag iofs ingen skulle designa spelet på det viset för de flesta mer avancerade programemrare vet om vad som tar tid och vad som inte tar tid på en processor och anpassar koden efter det. Det är också en orsak till att Intel brukar vinna då koden är anpassad just för den typen av trådhantering som passar för äldre arkitekturer.
June 11, 2001
Offline
Det där har väl mycket med onödigheter att göra. Vet en gång då jag lekte i Visual Basic och provade med att skapa ett program som räknade ut kontrollsiffran i personnummret. För att det skulle se snyggt ut så använde jag mig av en sådan där stapel som visar hur långt en händelse har kommit och såg till att den skulle öka med 1/10 del varje gång.
För attt visa hur lång man kommit i beräkningen så användes värdet av den loop man hade och stapens min och max-värden var 0 respektive 9
För att uppdatera stapeln så behövdes koden
ProgressBar1.Value=n
Detta gjordes varje gång en siffra hade beräknats i den FOR - NEXT slinga man använde.
Sedan så beräknades värdet och när alla beräkningar var klara så var stapeln helt fylld och textfältet under var fyllt med resultatet.
Att utföra denna beräkning tog ca 45 sekunder per siffra.
När man tog bort ProgressBar1.Value=n så tog det knappt en sekund att beräkna värdet. (I princip fortare än man kunde uppfatta.)
Detta tyder på att visa hur långt man kommit tar längre tid att uppdatera än att utföra beräkningen.
Processorn som användes var en 2200+ och det var 1GB ram med en 160 GB Segate 7200.9 disk i datorn. Operativsystemet var Windows XP.
Att spara nära 7,5 minuter av att bara ta bort en rad i programmet säger en hel del om vad som är fungerande/effektiv kod.
Exempel på detta är tex när man kopiera filer. Är det små filer så öppnas inte ens fönstret som visar hur det går. Om detta beror på att det hunnit stängas före grafikkortet har uppdaterat eller om det är så att det beräknas till en viss storlek så ska fönstret öppnas.
Detta är helt klart intressant vad som beror på kärnor, operativsystem och ren programkod. Samt den mest intressanta - översätter operativsystemet programmet på olika sätt till olika processorkärnor och är översättningen olika effeektiv till AMD och Intel?
Eller är det så att AMD hackar hela tiden på en jämnt sätt som gör att vi inte uptäcker det?
April 4, 2008
Offline
Sebbe wrote:
För att uppdatera stapeln så behövdes kodenProgressBar1.Value=n
Detta gjordes varje gång en siffra hade beräknats i den FOR - NEXT slinga man använde.
Självklart så om en programmerare är "klantig" så kan något ta många gånger längre tid än vad de skulle behöva ta.
Fast om man kodar tidskritiska applikationer så tror jag de vet (annars är det illa).
Angående windows och ha diverse grafiska förändringar så är windows händelsestyrt, operativet pratar med programmen. Exempelvis så "ägs" musen av operativet, det är så windows vet vilket program det skall aktivera för windows vet var musen befinner sig och även var programmen finns samt vilket program som är "överst".
När något förändras i ett fönster så sker det i ett medelande som windows skickar och som brukar kallas för WM_PAINT (C och C++). I detta meddelande ritas fönstret om (logik för hur fönstret skall ritas finns där).
Det är en väldans komplex hantering i jämförelse med att räkna ut tal. Pågår en hel del under ytan.
August 7, 2003
Offline
Lehto wrote:
Ville bara veta om du läste tråden och ändå har den slutsatsen som du har nu.
Jag skummande igenom den. Det står en massa saker där, men inget som skulle innebära spel blir mer "hackiga". Om latency står det en hel del, som att core2 förbättrat den minst 100% jämfört med Pentium 4, för vissa storlekar flera 1000%.
K10 (som det inte står om där) har istället försämrat cache-latencyn.
OM FSB nu skulle vara så extremt viktigt och allting hängde på det så borde man se förbättringar i samma storleksordning som hastigeten ökar. Om FSB höjs från 800 -> 1333 så ska hastigheten öka med 66%? I själva verket är det kansk ett par % på sin höjd?
gosh wrote:
Det är inga marginella skillnader mellan Opteron (quad) och Xeon på servrar, speciellt inte när de har flera socklar. Intel har inget och hämta där.Att företag ändå köper har mer med tradition och reklam och göra.
Faktum är ju att AMD's äldre opteron som är tvåkärnig och tillverkats på 90nm kunde konkurrera med Intels senaste högfrekventa processorer
🙄
Så du påstår att en äldre Opteron med två stycken cores (hur många Ghz?) slår en core2 med 4 stycken cores?
Vi köpte Opteron förut när de var bättre, vi köper Intel nu när de är bättre. Snarare är det så vi köpt Opteron en stund när vi utökat befintliga miljöer, trots vi vetat de är sämre för att ha samma processorarkitektur. Alla nyare maskiner blir dock Intel och kommer fortsätta bli det ett bra tag.
Finns många fördelar med Intel, cpu-kraft har inte egentligen så mycket med det att göra utan andra saker.
Exempelvis MÅSTE man har två proppar i en AMD server för att kunna stoppa i max med minne, i en Intel så kan man ha EN quad-core propp och stoppa den full med minne (se där, en fördel med FSB istället för minnes-kontrollern på processorn 😉 ). Vmware KÄKAR minne, men inte nån cpu. Licenskostnaden för en extra propp (som inte behövs "egentligen" i 3 maskiner är sisådär 45000 (eller 60.000 eftersom man köper det i pack om 2).
Sen finns det inte några HPmaskiner med quad-core AMD-processorer att köpa (iaf inte när jag kollade för en månad sen...). Intel finns (fanns) upp till 3.16 GHz.
Hursomhelst i frågan om "hackighet" så måste man ju kunna mäta den med nåt FPS-graf-program???
April 4, 2008
Offline
Laglorden wrote:
K10 (som det inte står om där) har istället försämrat cache-latencyn.
hmm, tror du själv att det är en korrekt slutsats? varför skulle man tillverka en ny som är sämre 😉
de har en annan teknik nu, för att synkronisera cache mellan kärnorna går använder phenom chachen (L3), medan intel måste gå via minnet. gissa vad som tar längst tid?
Nehalem har samma teknik som phenom så det finns kanske en del fördelar med det..
Laglorden wrote: OM FSB nu skulle vara så extremt viktigt och allting hängde på det så borde man se förbättringar i samma storleksordning som hastigeten ökar. Om FSB höjs från 800 -> 1333 så ska hastigheten öka med 66%? I själva verket är det kansk ett par % på sin höjd?
Ja om en dator endast bestod av en FSB så skulle det antagandet stämma, nu är det några delar till innan det blir instruktioner till processorn som den sedan kan utföra som i sin tur blir något användbart för användaren.
Laglorden wrote: Så du påstår att en äldre Opteron med två stycken cores (hur många Ghz?) slår en core2 med 4 stycken cores?
det beror lite på vilken typ av applikationer man kör, Xeon har öst in cache och försöker speeda upp annat för att kompensera bristerna i kommunikation mellan de olika processorerna på kortet. Men blir det mycket "prat" mellan processorer så räcker det inte ändra fram. Är det däremot inte så mycket prat mellan processorerna så har de givetvis fördelar.
Laglorden wrote: Alla nyare maskiner blir dock Intel och kommer fortsätta bli det ett bra tag.
Opteron med fyra kärnor börjar dyka upp nu.
Exempel:
http://www.sun.com/servers/index.jsp
http://www.crn.com/hardware/206904494
http://www.pcauthority.com.au/.....rvers.aspx
De stora tillverkarna har legat och väntat på att det skulle dyka upp en buggfri (tlb buggen) opteron. Läser du på om viritualisering, databashanering m.m. så ser du fördelarna.
Laglorden wrote: Hursomhelst i frågan om "hackighet" så måste man ju kunna mäta den med nåt FPS-graf-program???
Det tror jag inte, efter lite undersökningar så tror ett problem har och göra med "thread scheduler'en". AMD stödjer en minnesteknik som kallas för NUMA och det gör även windows. Istället för att förklara vad det är så finns här några länkar.
http://technet.microsoft.com/e.....94386.aspx
http://en.wikipedia.org/wiki/N.....ory_Access
http://developer.amd.com/pages.....07106.aspx
Intel gillar inte och växla mellan trådar, dels för att fsb'n är en stor flaskhals och så länge minnet ligger i cachen så ha de sina stora fördelar. Möjligen kan det vara så att en optimering är att inte växla mellan trådar lika ofta som AMD kan göra, intelligensen för hur växlingen går till är möjligen sämre med. Om en kärna växlar till annan tråd som kräver minne och då cachen får tömmas och fylls upp med nytt så tar det längre tid än hos AMD som har snabbare minneshantering.
I/O (alltså kommunikation med andra delar förutom minnet) är också snabbare och det är även något som påverkar "thread scheduler'en". Vad jag känner till så växlar man inte gärna från en tråd till en annan för en kärna när en sådan typ av operation pågår.
April 4, 2008
Offline
Laglorden wrote: Vmware KÄKAR minne, men inte nån cpu.
OT:
Hur har ni ställt in klienterna (virtuella maskiner), alltså hur mycket minne. Känner till att vmware direkt reserverar det minne man ställt in klienten för även om det inte används av klienten.
Även så går det ju och titta på vmware's hantering för att dela minne mellan klienterna.
länk:
http://searchservervirtualizat.....64,00.html
windows server 2008 kan vara något och kolla upp
August 7, 2003
Offline
varför skulle man tillverka en ny som är sämre
de har en annan teknik nu, för att synkronisera cache mellan kärnorna går använder phenom chachen (L3)
Du svarar egentligen på din egen fråga. De har gjort det för möjligheten att kunna använda en fet L3-cache bland annat. Det ökar latencyn till L2 cachen från 12 till 15 klockcykler och det ökar L3 cache-latencyn från 44 till 48 klockcykler. Samtidigt har man minskat L2 cahcen per kärna till hälften för att slippa göra kärnan så stor/dyr. Så i vissa lägen (om man har en data-size på en meg exempelvis) så har latencyn ökat från 12 till 48 klockcykler. Jag säger inte det är sämre. Det är en kompromiss, man kan inte få allt osv osv... jag tror det är en bra "trade-off", men faktum kvarstår, cache-latencyn har ökat.
När Opteron måste gå mot L3 cachen kanske core2 hittat det redan i sin förhållandevis stora L2 cahe... Med ett dataset på 4 Meg (Penryn säkert samma upp till 6 Mb) så hittar den sitt minne vid en L1 cache-miss på 14 klockcykler medans Opteron "stallar" i sisådär 110-120 och hämta det från RAM-minnet...
Phenom är en variant av K10, så den har också denna (3 klockcykler) sämre latency även om den inte har nån L3-cache dra nytta av.
Ja om en dator endast bestod av en FSB så skulle det antagandet stämma, nu är det några delar till innan det blir instruktioner till processorn som den sedan kan utföra som i sin tur blir något användbart för användaren.
Exakt, om den enda "flaskhalsen" var FSB så skulle 66% förbättring av flaskhalsen innebära 66% bättre cpu-prestanda. Eftersom det inte är så, så stämmer inte teorin att FSBn är så extremt viktig.
Jag tror egentligen vi säger samma saker, men jag säger bara att Intel har (trots grund-tekniken kanske inte är så "snygg" som AMDs) lyckats med trix och bra tillverkningsteknologi göra processorer som trots detta är snabbare. De är så mycket snabbare så även om de förlorar några % mer än AMD när man går från 2 till 4 threads med minnesaccess så vinner de ändå.
Tycker fortfarande man borde kunna mäta/visualisera upplevd "hackighet"... Syns inte, finns inte...
(ja, jag vet vad Numa är...)
Vmware är konfad korrekt tror jag nog... Dels kan man säga hur mycket de ska använda och hur mycket reservarion de ska ha, dessutom finns det tekniker som "balooning" osv osv... men det där vill man lika lite ha i drift som swappande maskiner, så det bästa är att ha så mycket minne som maskinerna vill ha.
Det är bara det att maskiner oftast använder mer minne än cpu eller om man säger såhär maskiner innehåller oftast mer cpukraft än minneskraft. Intelmaskiner kan man stoppa 16 minneskretsar i och en cpu, i AMD-maskiner kan man inte det. Fördel Intel, i detta fall också.
April 4, 2008
Offline
Laglorden wrote: Du svarar egentligen på din egen fråga. De har gjort det för möjligheten att kunna använda en fet L3-cache bland annat.
Ja för jag fick uppfattningen att du inte kände till hur den fungerade med tanke på dina ordval.
Laglorden wrote: När Opteron måste gå mot L3 cachen kanske core2 hittat det redan i sin förhållandevis stora L2 cahe... Med ett dataset på 4 Meg (Penryn säkert samma upp till 6 Mb) så hittar den sitt minne vid en L1 cache-miss på 14 klockcykler medans Opteron "stallar" i sisådär 110-120 och hämta det från RAM-minnet...
Vad händer när det inte ligger i cachen då?
(har för mig att AMD klarar och hämta minne oavsett vad det är och om man inte har för långsamt ram under 100 klockcykler). Varje kärna har dessutom sin egen kanal. Intel har en enda kanal för alla kärnorna.
Vet du hur stor L2 cachen är på Nehalem?
Exakt, om den enda "flaskhalsen" var FSB så skulle 66% förbättring av flaskhalsen innebära 66% bättre cpu-prestanda. Eftersom det inte är så, så stämmer inte teorin att FSBn är så extremt viktig.
Jo den är fruktansvärt viktig men den är inte viktig så viktig på desktop applikationer eller applikationer som inte kräver prestanda.
Har du två trådar som måste synkronisera varandra ofta så kan du få prestandaförluster som är bra mycket mer än 66%. Sett siffror på en faktor 5, speciellt när trådar hamnar på olika kärnpar.
April 4, 2008
Offline
Intessant test
http://connexitor.com/blog/piv.....php?id=191
Kommentarer
http://www.informationweek.com.....re_ba.html
August 7, 2003
Offline
Jo, det där kan ju vara intressant. Hittar man något dataset, Linpack eller det där exempelvis som går över L2-cachen konskekvent så är klart man får prestanda som påminer om rena memory-benchmarks. Det känns som AMD letat väldigt länge och äntligen hittat nåt sånt... Alltid lite misstänksam när något fått ett system gratis av en tillverkare.
Han skulle testkört det på ett Power6-system så skulle han få sett på prestanda... 36 MB L3-cache och ingen leksaks-minnesthroughput, men då måste han nog lära sig optimera sin kod bättre och använda mer avancerade optimeringsswtichar... (han skriver hans använder -march=core2 osv, antar han även kör -O3 och motsvarande för att enabla stora cachar..)
( OT: http://www-03.ibm.com/systems/.....specs.html )
Det säger fortfarande inget om eventuell "hackighet" eller inte i spel dock.
April 4, 2008
Offline
Laglorden wrote: Det känns som AMD letat väldigt länge och äntligen hittat nåt sånt... Alltid lite misstänksam när något fått ett system gratis av en tillverkare.
Så du menar att det "känns" .. 😉
Ett tips: Vilken databasapplikation som helst kommer uppvisa samma fenomen. Försök och leta upp test som visar prestanda mot databaser, fråga dig sedan varför du har så svårt och hitta sådana tester och vad får du för "känslor" då?
Personligen så vart jag förvånad att det skiljde så mycket. En 1,9 GHz Opteron som jag gissar har patchen för TLB buggen och som utklassar en Xeon med större cache och har en frekvens på 2,4 GHz.
Men då är det samtidigt inte svårt och förstå varför Intel designat om sin processor och härmat AMD.
Laglorden wrote: Det säger fortfarande inget om eventuell "hackighet" eller inte i spel dock.
Du behöver nog inte oroa dig för så fort Intel släpper sin Nehalem så kommer du nog få se en hel del olika tester som ploppar upp för att visa på den nya generationens processorers förträfflighet. Förmodligen kommer du då även få se ett ganska snabbt teknikskifte med för hur man designar applikationer.
August 7, 2003
Offline
gosh wrote:
Ett tips: Vilken databasapplikation som helst kommer uppvisa samma fenomen. Försök och leta upp test som visar prestanda mot databaser, fråga dig sedan varför du har så svårt och hitta sådana tester och vad får du för "känslor" då?
Så, det skulle vara svårt hitta databas-prestandatester? för att? Döds-patruller från Intel letar upp de som gör såna tester? och AMD är för skraja för att göra såna tester själva?
Nja, en databasapplikation är inte bara läsning från minne, det är en del processorbelastning (samt mycket disk). Intel har ju dessutom mer cache och så länge man får träff där (i de flesta applikationer applikationer 90-99,9% av gångerna så vinner ju de, och eftersom de flesta, även databasapplikationer är såna, så vinner de) Självklart finns det enstaka undantag där AMD vinner. AMD är nog snabba på att peka ut såna (och antyda för diverse testare vad de tycker "borde" ingå i test-floran... (precis som säkert Intel är snabba på att peka ut vad de anser ska ingå för att visa sig i bäst dager...))
Om AMD skulle vara så överlägset på att vad gäller databaser så skulle de nog se till "låna ut" fler system till diverse bloggare 😉
Det finns en standard för databas-performance som heter TPC(-C). Alla värden finns på http://www.tpc.org/. Alla tillverkare publicerar sina bästa värden (och bästa pris/performance) där för att kunna skryta. Om de inte får fram bäst värden låter de bli publicera dem, för det mesta.
Det kostar dock rätt mycket hårdvara få fram bra höga värden. 40.000 diskar har jag för mig vissa tillverkare använder osv.
Hursomhelst, Ifall man kollar på HP till exempel så har de förr om åren publicerat värden för AMD-maskiner, numera publicerar de bara värden för Intel-maskiner. Det beror på att Intel är snabbare på databas (också). För tillfället är det bara Intelproppar i de maskiner de använder för att skryta med, om det ändrar sig och AMD blir snabbare igen så lär det ändra sig snabbt där. Observera att det inte är Intel eller AMD själva som gör testerna utan IBM, HP osv.
Det där är värden (likt specmarks) är saker som tillverkarna lägger massa $$$$ på att få fram. Det är inte någon hemmahacker som sitter och kör sitt eget lilla program. Nackdelen är det kostar mycket. Fördelen är just att det är standard och alla försöker verkligen optimera så mycket som möjligt för just de programmen, och om alla "fuskar" lika mycket så blir det rättvisande värden. Eftersom koden är publicerad och man måste ange exakt vad man gör så... kan man inte har några hemligheter nån längre tid.
Edit: Hittade faktiskt värden för en AMD-maskin 402,234;
http://www.tpc.org/tpcc/result.....=108033101
och en Intelmaskin med samma antal cores 516,752
http://www.tpc.org/tpcc/result.....=107101503
eller om man vill "syster-maskinen" i Hp range 407,079 (mer lika kostnad (om man tänker på ett halvår gått mellan testen av Intel till AMD) och mjukvara också)
http://www.tpc.org/tpcc/result.....=107090502
och då är det 2,93 Ghz processorerna (som väl är 1333Mhz FSB...) , inte 3,16 Ghz Penryn.
Men som sagt, peka på en kurva nån gjort som visar ett spel där en Intelmaskin droppar ned i FPS mera än en motsvarande AMD-maskin...
April 4, 2008
Offline
Laglorden wrote: Det finns en standard för databas-performance som heter TPC(-C). Alla värden finns på http://www.tpc.org/. Alla tillverkare publicerar sina bästa värden (och bästa pris/performance) där för att kunna skryta. Om de inte får fram bäst värden låter de bli publicera dem, för det mesta.
Intressant och se att en opteron på 2,3 GHz presterar som en Xeon på 2,93 GHz samt att Xeon har så mycket mer cache.
Klienterna (ingen aning hur mycket de påverkar) körde ju på halva hastigheten när AMD testades jämfört med Xeon datorn .
August 7, 2003
Offline
Klienterna har ingen betydelse då de "sitter och matar in text", simulerar användare i i bank-system typ, en klient kan simulera väldigt många användare utan att belasta. Om de skulle få bättre siffror av 20.000 quad-core klienter så skulle de köpa in det för kaffe-pengar.
Mjo, gick det att få en quad-core Opteron i typ 2,93 Ghz så skulle den säkert få bättre värden...
OT: Bara för skojs skull. 4 stycken dual-core Power6 processorer, med 8 cores 629,159 (alltså lika snabba med hälften så många cores);
http://www.tpc.org/tpcc/result.....=108032101
Jag tror man haft integrerad minneskontroller dock, sedan Power2 (tidigt 80-tal) men jag blir lite förvirrad eftersom jag har för mig Macarna använde FSB åtminstone på power4-derivaten.
April 4, 2008
Offline
Laglorden wrote: OT: Bara för skojs skull. 4 stycken dual-core Power6 processorer, med 8 cores 629,159 (alltså lika snabba med hälften så många cores);
http://www.tpc.org/tpcc/result.....=108032101
Jo fast den är gjord med databasen DB2, tänk på att TPC testen i första hand är ett test för mjukvara och det är väldigt mycket diskhantering vid databaser med. Processorns förbättringar är inga 1-1 förhållande eftersom annat tas med. Angående DB2 och om de kör på mer "konstiga" operativ så vet jag att den ibland kunde lagra position på disken i själva databasposten vilket gav extremt snabb access. Vet inte om de kan göra det fortfarande, den databasen har en del fördelar där men den är rätt kass i andra avseenden.
August 7, 2003
Offline
gosh wrote: Jo fast den är gjord med databasen DB2, tänk på att TPC testen i första hand är ett test för mjukvara och det är väldigt mycket diskhantering vid databaser med. Processorns förbättringar är inga 1-1 förhållande eftersom annat tas med. Angående DB2 och om de kör på mer "konstiga" operativ så vet jag att den ibland kunde lagra position på disken i själva databasposten vilket gav extremt snabb access. Vet inte om de kan göra det fortfarande, den databasen har en del fördelar där men den är rätt kass i andra avseenden.
Eftersom man använder typ en tusendel av varje disk och man har SAN med flera TB cache och maskiner man ibland flera TB minne osv osv...
När det gäller skillnader mellan mjukvara så kan det stämma, men även där funkar det på samma sätt, ifall DB2 hittar ett sätt var x procent snabbare så kopieras det av Oracle och av SQL osv så det blir paritet rätt snabbt där med, iaf så växlar det vem som för tillfället är snabbast.
April 4, 2008
Offline
Laglorden wrote: När det gäller skillnader mellan mjukvara så kan det stämma, men även där funkar det på samma sätt, ifall DB2 hittar ett sätt var x procent snabbare så kopieras det av Oracle och av SQL osv så det blir paritet rätt snabbt där med, iaf så växlar det vem som för tillfället är snabbast.
Att Oracle, MS SQL Server (samt andra) skulle kopiera IBM gamla lösning om att lagra diskposition i posten finns inte på kartan. Vid vissa typer av applikationer så är denna lösning extremt effektiv. Jobbade för många år sedan med ett mailsystem som kallas för memo, redan då kunde en enda dator serva tusentals användare. Men fy helvete vilket jobb och koda kring det systemet.
Det är en typisk gammal stordatorlösning.
Hur snabb en databas är beror väldigt mycket på hur den är designad. En dålig designad databas kan slå i taket direkt med lite användare. Det är rätt förvånande hur illa design det är på databaser ute hos företag. Till och med kända databaser för standardsystem kan ibland vara helt värdelöst designade.
När det gäller databaser (mjukvara) så är det som processorer, det är sällan det går och få det bästa av två världar. Vill man ha bra hastighet på ett område så får man eventuellt offra funktionalitet i något annat.
March 25, 2008
Offline
känner igen dedär,
på denna intel "e2140 @ 3,07" så hackar det ibland.. inte ofta
men det händer.. stannar upp en halvsekund eller så, lagom så man ska komma av sig och krocka i bilspel tex.
Det händer aldrig med min athlon 6000+ iofs är väl dom bättre än den prollen ja har nu 😛
1 Guest(s)
