Förvillad: Intel eller inte?

Intel eller AMD är sak samma OM processorn har 64bitars instruktioner (AMD64) eller (EM64T).

AMD är rent generellt bättre på spel och flyttalsberäkningar , Intel är bäst på heltalsadditioner...........

Detta och AMD:s integrerade minneskontroller är de skillnader du till viss del kan märka.
Annat är att AMD prollar nuförtiden är stabilare än intel prollar med microsofts produkter.
Slutligen kan det även sägas att AMD är RISC processor.......enbart så ingen annan kan anmärka på mig......

Mvh

Ursäkta?

Jaha. RISC-processor är ju P4:an också, så vad har det med saken att göra?

Angående valet så hade jag tagit P4:an om jag skulle hålla på med mycket tunga grejor samtidigt. Athlon64 är ju annars rätt bra på kompilering, om du sysslar en del med det och dessutom lättare att kyla, alternativt "få tyst".

Lite svårt val, med andra ord. Multitasking med tunga grejor = P4, annars kanske Athlon passar bättre med de grejor du skall syssla med.

Kan inte hålla med om svamlet Mikael har skrivit.

Multitasking och tunga grejor......rent nonsens.

Ingen har någonsin lyckats påvisa att P4 med hyperthreading klarar multipla program bättre än AMD64.

Tunga grejor kan definieras lite hur som helst, jag definierar tunga grejor som minneskrävande, alla vet att AMD64 är bäst vad gäller minneshantering.

Vissa MPEG prylar gör dock Intel bäst både som ett program och när flera köärs samtidigt.
Detta har inget med Hyperthreading att göra utan är ett resultat av Intels blixtsnabba heltalsenhet, vilket gör den till ett överlägset val för den som rippar CD-skivor och DVD-filmer.............

P4 är också till viss del en RISC processor, kunde inte låta bli att utmana med min kommentar, Intels standard kritik mot konkurrenter var ju tidigare att de pysslade med codemorphing och inte var genuina x86 maskiner, nu pysslar ju alla med codemorphing..............

Mvh

om man ska köra många program och har flera fönster uppe så är det inget som slår en p4a, det är skillnad,

Båda omvandlar CISC-intruktioner till RISC-instruktioner i realtid via speciella enheter i hårdvaran. Om de inte gjort detta hade det inte gått att göra de pipelinade (kräver lika långa instruktioner). Vad menar du med att Athlon64 "emulerar" CISC-instruktioner? Den tar emot CISC-instruktioner precis som P4:an och måste precis som P4:an bryta ner dessa till kortare instruktioner.

Det vet jag också. Däremot blir ett P4-system mer responsivt än ett AMD-system när man kör flera grejor samtidigt. Behövs inte mycket för att en AthlonXP/Athlon64 skall bli riktigt jobbig att använda. Sedan att P4:an inte utför särskilt mycket mer arbete än en A64 under samma tid är en annan sak, men det påstod jag ju heller aldrig.

P4:an är fortfarande ofta starkare på rendering, även om skillnaden är så liten att jag personligen troligtvis inte hade brytt mig. Videokomprimering och i viss mån ljud är väl trots allt överlag något bättre på P4:an fortfarande?

Som jag har förstått är en AMD 3000 lätt att klocka upp en bit. Medan en varmare P4 kräver mer kylning.
Därom kan man tvista i evigheter, de tidiga Prescottarna tålde mer värme, och började inte tappa prestanda förens de var mer än lite varma, vilket gav dem en väldigt god överklocknings potensial, redan med standard kylningen. tyvärr har senare versioner av samma cpu fått värre o värre siffror på när de börjar klocka ner sig och annat, så det kan vara tufft. Med en vettig chassi lösning, och normal rumstemp, kommer man sanolikt kunna klocka P4'an en bit den med, hur långt vågar jag inte ge mig på att gissa, då jag själv sitter på en av de tidiga prescottsen, som glatt värmer hela lägenheten, är klipstabil, och glödhet.

Detta och AMD:s integrerade minneskontroller är de skillnader du till viss del kan märka
AMD's integrerade minneskontroller ger onekligen bättre minnes prestanda, eftersom de spar tid på att inte ta det via chipset.

Annat är att AMD prollar nuförtiden är stabilare än intel prollar med microsofts produkter.
Vad det gäller stabilitet, är det inte relaterat till någon mjukvarutillverkare, då är det mjukvarubuggar, det som har varit AMD's problem med stabilitet, och som om jag inte minns fel, var som värst runt K6 / K6-2 tiden, var deras chipsets, som tog en annars hyfsad cpu, och körde den i väggen. Lite trist, men knappast AMD's fel (utöver att de kunde ha producerat ett eget chipset, eller ha ett nära samarbete med nåns om skulle producera deras chipset.) Det är inte längre ett problem. Visst finns det fortfarande bättre och sämre chipset, men det gör det till båda platformerna.

Ingen har någonsin lyckats påvisa att P4 med hyperthreading klarar multipla program bättre än AMD64.
lustigt, det beräknas på tex F@H's forum att man tjänar mellan 0 och 25% på att löra två instanser jämfört med en på HT'cpu, beroände på mer exakt vilka olika protein, och vilka manipulationer som utförs. det bör väll ganska bra visa att man "tjänar" upp till 25% cpu kraft, altså får bättre multitasking egenskaper. (observera, man tjänar upp till, och bara jämfört med samma cpu, utan hyperthreading).
Detta kan sen betraktas i ljuset av att en A64'a och en P4 utan HT hävdas vara jämlika vad det gäller multitasking.
Till det bör även tillägas, att du kommer inte märka någon natt och dag skillnad, och knappt någon alls om du inte har full last, och alt+tabar en massa, ur användar synpunkt. Visst ger det Prescotten en extra knuff i ryggen, men det är inte magi.

Mycket tunga saker samtidigt, vad menar du med det? Multitasking eller? I ett fåtal applikationer blir P4 snabbare tack vare Hyperthreading, men HT är annars egentligen bara ett sätt att fylla den långa instruktions-pipeline som P4 har, speciellt Prescott. HT kommer aldrig i närheten av den prestanda man får med dubbla processorer (eller dubbla kärnor).
Det här är delvis sant, men ändån inte hela saningen, den mest effektiva cpu'n just nu användbar till nånting vettigt, Dothan, skulle även den tjäna på att upgraderas med HT, det här inte bara med långa pipelines att göra. det handlar om att minimera förluster, som alltid kommer att inträffa, så länge pipelinen inte är ett steg lång. Den rena prestanda förtjänsten krymper, visst, men den finns kvar. Den skillnad det gör på multitasking att ha två virituella cpu'er, den kvarstår. I alla fall i teorin.

Avslutande, det är lustigt, han bad om Pro intel snack, för att få en möjlighet att höra båda sidornas fördelar, båda lägernas synpunkter på vad som är de starka punkterna, och redan första svaret visar 'vissa' teken på att vara en rekomendation av AMD, det var inte vad han ville ha, han bad specifikt om fördelar och anledningar till att välja en P4'a över AMD. om det då bestrids rena lögner, det kan jag köpa, men om det framförs som fördel att "köp P4'a för att de e koolare, mer status" får det stå för talaren, han är Intel Fan, och som sådan är det hans åsikt, precis vad Makatech bad om.

Personligen, skulle jag köra en liknande server, skulle jag satsa på en Intel. Jag hade antagligen väntat på dual core lösningen, som hävdas skulla komma runt hörnet. Skulle jag bygga en ren spelburk, hade jag antagligen byggt på en AMD, skulle jag bygga en allt i allo burk, hade det blivit en Intel. Jag kan inte riktigt försvara varför, eftersom det i huvudsak baseras på personliga preferenser, tidigare erfarenheter, och (sanolikt) fördommar. Jag tycker du ska satsa på det du känner du litar mest på, prestanda och stabilitet ska vara i stort sett den samma. Visst tror jag att Intelen har mer beräkningskapacitet kvar efter att ha dragit runt dina grejer, och visst tror jag att det kan gå nån hundradels sekund fortare att alt+tab'a, men det är dels marginelt, och dels återigen färgat av en personlig åsikt. Det VAR ju det du ville ha? ;- )

(jag avstod från att namnge någon citerad talare, då jag inte på någotvis utalar mig om personen i fråga, utan enbart avser att poängtera den i min åsikt felaktiga, eller kanske felaktigt formulerade åsikten talaren utrycker.)
B!

Okej, har kollat upp detta nu och Athlon utför ingen "emulering". Både K7 och K8 plockar CISC-instruktioner och översätter dessa till RISC. Detta görs på två sätt, beroende på hur stora instruktionerna är. Om det är små instruktioner, som kan översättas till en eller två RISC-instruktioner (som alltså är exakt lika långa), så körs de genom Athlon-processorns Fastpath decoder. Denna översätter instruktionerna hårdvarumässigt och gör det mycket snabbt. Krångligare instruktioner (vilka också är lite ovanligare) går genom processorns microcode decoder. Denna letar i en tabell för att ta reda på vilka RISC-instruktioner som kan ersätta CISC-instruktionerna. Av naturliga skäl går detta segare och därför försöker man få så många instruktioner som möjligt att åka igenom Fastpath-decodern.

Vad jag vet använder P4:an bara en microop decoder för att decoda CISC-instruktioner (men det borde jag nog kolla upp). Effekten av båda sätten är ju dock exakt lika, nämligen att översätta CISC-instruktioner till RISC-instruktioner. Med andra ord finns det inga principmässiga skillnader mellan Athlon och P4 på detta plan. Båda är i grunden RISC-processorer som använder ganska komplicerade metoder för att omvandla de lätt osmidiga CISC-instruktionerna till något som kärnan kan läsa.

När jag ändå skriver så kan jag påpeka att jag gjorde ett litet misstag i mitt förra inlägg. Hyperthreading ökar visst processorns produktivitet, eftersom detta är en naturlig bieffekt av att pipelinen hålls full. Den största fördelen för de flesta användare är nog dock att systemet i regel känns någorlunda responsivt även om någon (eventuellt några) relativt tunga processor körs i bakgrunden.

Är det fortfarande någon som tycker att jag hade fel med vad jag skrev mitt första inlägg? Ge gärna lite länkar och liknande i så fall, så att jag kan läsa på.

Hehe... Jo, emulering handlar ju egentligen om översättning.

Dock undvek du snyggt att förtydliga vad du försökte säga innan:

P4 är i grunden en CISC-processor. Athlon64 är en RISC, som emulerar CISC-instruktioner. Sen har båda extra instruktionsuppsättningar, t ex MMX, SSE och 3Dnow.

Enligt mig är det mest goja, men jag vill gärna veta om det finns något seriöst bakom det.

EDIT:

Allså, det jag undrar över är påståendet att P4:an i grunden är CISC och att det skulle vara någon principiell skillnad mellan den och Athlon. Båda är RISC, som konverterar till CISC på ungefär samma sätt, så var i ligger skillnaden?

EDIT2:

Kan ju också nämna att jag studerar en del om pipelining, CISC/RISC, m.m. för tillfället, så därför är diskussionen rätt intressant. Vi har även talat lite om just P4:an och hur den fungerar och varför man inte kan använda CISC-intruktioner i en pipeline. Intressant område!

"lustigt, det beräknas på tex F@H's forum att man tjänar mellan 0 och 25% på att löra två instanser jämfört med en på HT'cpu, beroände på mer exakt vilka olika protein, och vilka manipulationer som utförs. det bör väll ganska bra visa att man "tjänar" upp till 25% cpu kraft, altså får bättre multitasking egenskaper. (observera, man tjänar upp till, och bara jämfört med samma cpu, utan hyperthreading).
Detta kan sen betraktas i ljuset av att en A64'a och en P4 utan HT hävdas vara jämlika vad det gäller multitasking.
Till det bör även tillägas, att du kommer inte märka någon natt och dag skillnad, och knappt någon alls om du inte har full last, och alt+tabar en massa, ur användar synpunkt. Visst ger det Prescotten en extra knuff i ryggen, men det är inte magi."

PROBLEMET ÄR ATT DU TAPPAR 25% med HT aktiverat i andra algoritmer.

PROBLEMET ÄR ATT DU TAPPAR 25% med HT aktiverat i andra algoritmer.

Källa?
Det vore intressant och veta hur någonting som i princip bara är till för att hålla en lång pipe fyld, kan göra cpu'n långsamare. Du har säkert rätt, men det gör inte det mindre intressant. (och jag förstår inte hur det skulle kunna vara så)

B!

http://www.anandtech.com/showdoc.aspx?i=1576&p=4
http://www.anandtech.com/showdoc.aspx?i=1746&p=11

Din utmaning var så lockande att jag lade ner 4 sekunder av min tid på att besvara den, hittade snabbt och excellenta referenser för dig Mikael.
Betänkvärt är att om du kan skriva en algoritm för något som blir 25% snabbare än tidigare så kan du även och mer vanligt förekommande skriva algoritmer som är mycket långsammare.

Ett klassiskt marknadsföringsknep är ju som vi alla vet att göra något långsammare än det vanligtvis är och sedan förbättra det lite och jublande visa upp stora %-satser!

I en av sidorna skrivs mycket riktigt att vissa webservrar kan bli upp till 0-30% snabbare med Hyperthreading påkopplat för en P4, vad som inte nämns är ju att AMD64 redan är så mycket snabbare.......

Mvh (Det sista tog mig 35sekunder att skriva)

Um, mistänker att det var riktat till mig, och inte Mikael, så jag tar mig för att svara. Visst går det utmärkt att medvetet skriva kod som är långsammare, det har det alltid gått, och kommer alltid att göra, men av dina trådar, för realistiska jämförelser, så som benchmarks låtsas vara, var det som absolut störst en 7%'ig skillnad på HT av/på, i den andra av dina artiklar, på den här sidan.

Vem är det du anklagar för att ha skrivit medvetet långsam kod?"klassiskt marknadsföringsknep" eller jag missförstod?

Att inte A64'n näms är kanske inte så konstigt, med tanke på datumet på artiklen. Möjligt är även att HT's siffror blivit bättre, eller sämre, eftersom det oxå utveklas längs vägen.

Som jag ade tidigare frågade han inte varför han skulle välja en amd, eller om han skulle välja en amd, han frågade efter anledningar att välja en Intel.

makatech, så länge du känner att du har gjort ett val du trivs med, är ditt val rätt, du kommer antagligen bli nöjd med den cpu'n med.
B!

Låter rimligt. Hade personligen också troligtvis valt en P4 om jag gjort många saker på en gång. Oftast begränsar det sig dock till att surfa samtidigt som jag lyssnar på MP3or, så min Athlon hänger med någorlunda i alla fall!

Hmmm... Trots det känner jag mig dock märkligt lockad av dualcore, men det är nog mest för att man är en tekniknörd.

det han glömmer i exemplet där instruktionerna "krockar" pga hyperthreading är att man inte måste utföra instruktionerna exakt samtidigt, utan det går att låta instruktion1 gå före och använda "store" samtidigt som instruktion2 utförs.. (det är väl det "out of order execution" går ut på?)
dvs istället för som han visar "klock1: ALU + L/S, klock2: ALU *krock*, klock3: L/S *krock*"
så görs det "klock 1: ALU+L/S, klock2: ALU, klock3 ALU+L/S, klock4: L/S"
vilket är snabbare än att använda 6 klockcykler för samma uppgift

och när dom skriver "upptill 25% ökning i F@H" så är dom väldigt konservativa, jag har sett snitt på ca40% ökning med slumpvist tilldelade uppgifter (tror att jag själv ligger där någonstans) och så högt som över70% (!) med "perfekta kombinationer" (2 olika "kärnor" som är igång samtidigt och använder rätt olika beräkningssätt.. tyvär är det sällan man blir tilldelad sånna trevliga kombinationer)

Var hittar du info om sånt här ?? Tycker det är grymt intressant.
Skulle uppskatta en länk eller 2 ?

Jag skall fatta mig mycket kort.

99,999% av de skrivna kodraderna på planeten jorden är inte optimalt skrivna.
Just därför är det jättekul att programmera om något och rapportera snabbhetsökning.
Bara att skriva om ett program från C++ eller Pascal till assembler ger i allmänhet att koden minskar betydligt i storlek och att exekveringshastigheten vanligtvis minskar 10 fallt.
Dvs om programmet tar 20sekunder i högnivåskriven kod tar det 2 sekunder i assemblerskriven kod.
När du väl har förstått detta så kanske du först känner dig lite korkad men senare kommer du att känna dig mycket visare.

Det var väl bra för intel att AMD tog tid på sig att bygga Hammer fabrikerna, K8 1,6Ghz var klar redan 2001.....ekonomiska beslut du vet.

Rent generellt så kan man säga att tidsskillnaden mellan AMD och intel vad gäller multitasking är ickesignifikant dvs man kan inte mäta någon större skillnad.
DET finns dock en skillnad i det att Intelsystemet kan kännas mer responsivt eftersom HT ger intelsmaskiner möjligheten att styra vilket program som skall exekvera.

MVH

Jisses, det här var en av de mest faktaspäckade trådar jag läst på forumet. Njöt av varenda sekund och är imponerad av kunnandet hos många av er. Känner mej som en riktig noob när jag läser.

makatech: Mitt svar på frågan; ta det du känner för. Du lär säkert inte ångra dej vilken du än väljer. Själv använder jag både Intel och AMD i mitt arbete och tycker båda har fördelar och några SMÅ nackdelar. Dock inget som jag haft några problem med. Lycka till!

Det jag skrev ovan är till viss del tagen från en mycket uttömmande artikel hos Ars Technica.

http://arstechnica.com/articles/paedia/cpu/amd-hammer-1.ars?2...

På sidan finns också analyser av andra processorer, så är du intresserad så är det bara att göra en djupdykning! Har själv inte hunnit kolla på det så mycket än, men det tänker jag göra så fort jag får tid. Lite grundläggande principer har jag lärt mig via skolan och en bok som heter "Computer Architecture and Design" av Henessy/Patterson. Bra och relativt lättläst bok (som jag dock inte hunnit plöja igenom än heller...). Skall sätta mig in rejält i HyperThreading så fort jag hinner också. Känns som det råder en del förvirring angående detta.

EDIT: Och ja, sådant här är faktiskt riktigt intressant! Känns härligt att (börja) förstå vad som egentligen händer i maskinen under skrivbordet.

Relevent hur då? om koden är dåligt skriven är det ju ännu viktigare att cpu'n jobbar på ett smart sätt, om något bör HT göra mer nytta. Så länge den inte är medvetet skriven, för att vara direkt prestanda sänkande. Som framgick i din egen klistrade länk, fanns det verkligen tillfällen då HT var en nakdel... 1 av vad, 20 talet benchmarks? Vidare optimeras all mjukvara för dual core, och därför även delvis för HT, nu när alla tillverkarna bestämt sig för att det e nästa stora grej.

Eh, relevant hur då? Det är säkert fantastiskt bra ur AMD's synvinkel, då de kunde använda fabrikerna, och finslippa processerna, så att alting fungerade när de behövde det, men var passar det in i den pågående diskutionen? jag förstår inte?

Det är ju precis det vi/jag sagt hela tiden, ett HT system flyter smidigare när du kör multipla simultana laster, framförallt om du maximerar lasten, då HTcpu'n inte nämnvärt lider av det alls, men A64'an blir något trögare. P4'an lider inte av det på samma sätt, den klarar va att göra mer samtidigt, utan att kännas lika tungrodd, att sen en del saker faktiskt blir snabbare är bara en bonus.

B!

Nu ska vi inte överdriva det här, HT kan hjälpa upp till 2 saker.

Vad ni inte verkar förstå är att det viktigaste instrumentet för bra multitasking är fortfarande själva OSet, det är OSet som har hand om processerna och kollar ni i taskmanagern så ser ni att ni har 20+ processer igång samtidigt.

Vad gäller att AMD känns trög vid multitasking, jag har testat det där själv. Brände en skiva, körde Prime95 samtidigt, surfade osv.. och det gick utan lagg eller problem.
Vad man gör är att ställa in vilka processer som ska ha högre prioritet, ställ in att brännarprogrammet har högsta, browsern näst högsta, prime95 lägsta (vilket är default också) osv.. så kan man fortsätta sådär.
Då kan man växla mellan brännarprogrammet och browsern utan något som helst lagg trots att cpu användningen ligger på 100% hela tiden.

Men det är klart, hade ni varit Powerusers så hade ni vetat allt detta redan.;)

avicenna Hade du varit så pass bra som du vill låta framgå, hade du vetat att full last är med 2 instanser av minst normal prioritet, som kämpar om cpu tiden. att låtsas att någonting på idle prioritet e full last, gör ingen märkbar skillnad änns på en P-MMX, då det släpper cpu cykler till höger och vänster så fort det finns en gissning på att det kan behövas.

Givetvis är det OS'ett som hanterar cputrådarna, men faktum kvarstår, HT hjälper till, helt enkelt genom att det ger en tråd till att dra det genom, kör du HT på ett singelCPU OS, försvinner fördelen, eftersom där inte finns nått stöd för verken virituella, eller riktiga smp cpu'er.
B!

Vad är idle priority? finns inte något som heter så.
Du pratar förmodligen om ditt HT nu, du kanske bara får 50% last eller något löjligt med ditt system med bara en instans( vilket inte är korrekt vilket som eftersom du har iaf bara en cpu).
Så är det inte dock för oss andra, så prime95 även på low priority är full last även fast det släpper cykler till allt som har högre prioritet.
Det är det liksom som är meningen med att ha olika prioritet, att köra såndat som prime95 på högsta prio vore enbart dumt.

HT hjälper till ja (på prollar med lång pipeline), till en begränsad nivå. Skrev jag något annat?

idle priority är den prioritetsgrad som F@H, SETI och Prime använder (dvs faktiskt lägre än vanliga "low")
ja, den håller processoranvändningen på 100% hela tiden, men den har ingen "lagg-effekt"
"powerusers" som har tid och ork att ändra prioritet på processerna manuellt är dom som är 13374Z7... dom flesta andra tycker att det är för mycket meck (jag orkar inte ändra prioritet varje gång jag byter huvudsaklig sysselsättning eller öppnar ett nytt program)

och HT hjälper även på processorer med kort/normal pipeline - att hålla processorn maximalt sysselsatt hjälper alltid

*suckar tungt* Idle Prioritet = låg prioritet, vad som åsyftas är att det använder ändast cpu cykler som är "över", altså de som annars syns i "systemets vänteprocess" Väldigt få program som gör nånting, använder en låg prioritet, för att det gör att saker tar längre tid att utföra, speciellt om man sitter och väntar. Kör en prime95 i normal prioritet, och surfa lite, på HT burken märks det inte. Vilket kan jämföras med kompilera en film, och surfa, eller vad du nu har lust att göra som normalt faktiskt går i normal prioritet.

Lustigt föresten, att du oxå påstår att HT bara "hjälper" på cpu'er med lång pipeline. Du har kanske missat den biten med att dothan är utrustad med kortare pipe än A64'an, och ändån förväntas komma med HT i desktop utförande? Hur pass det stämmer att den kommer eller inte vet jag inte, men klart är att HT är inte nånting du tjänar på enbart för att du har en lång pipeline.

B!

Ack! jag var för långsam, Tackar Frosty ;- )