Förvillad: Intel eller 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."

-VAD JAG MENADE VAR ATT DU DIREKT VID SHIFTNING AV PROGRAM FÅR LITE EXTRA CPUTID TILL DET UPPSTARTADE/VÄXLADE PROGRAMMET VIA HT.
OVERALL TJÄNAR DU INGET TIDSMÄSSIGT PÅ DETTA MEN FÅR UPP SKÄRMEN SNABBT OCH KAN ÖRJA ARBETA.

Appropå DOTHAN och HT kan det ju sägas direkt att HT är rena fjanteriet jämfört med den sänkta latensen i L1 cachen (P4 3 clockcyclers latens -dothan 1 clockcyckel).
Hyperthreading är ju uppenbart även rena fjanteriet jämfört med Dualcore och Hypertransport.

Ja som att jaga flugor med ett tennisrack utan nät.

och jag påstår att det visst ger en prestandaskillnad, särskilt om du har flera program igång

hört talas om Power-processorerna? hört att de också har HT... trots att pipelinen på dom är mycket kortare än på någon P4...
(Prescott = 3-4klock latens, dothan =2 klock latens, endast Northwood har 1klock)

sen att du nämner Hypertransport som något bättre får en att undra.. det är ju bara en j*la buss... det skulle klassats som FSB om inte minneskontrollern varit inbyggd

FrostyFog Finns inget lägre än low priority.

Man sitter ju inte direkt och ändrar i priorities dagligen, jag gör det i princip aldrig och behöver inte göra det heller. Men om man ska leka multitaskinghjälte och köra så mycket som möjligt så hjälper det.

MR_BB. För att få dig att sucka ännu djupare så får gärna bidra med länk till en kommande Dothan med HT.
Och hursomhelst nyttan HT kan tänkas göra på prollar som A64 och Dothan är betydligt mindre än på P4.

Lustigt, titta här i artiklen du själv klistrade in, de ser upp till 21% ökning i prestanda, det är en hel del, för nånting som enligt utalad åsikt tydligen inte ger ett skit "over all". Som jag skrev tidigare, så ser man ofta upp till 25% ökning i output om man kör dubbla instanser F@H, och som FrostyFrog påpekade ofta mer. Det är mer cpu kraft till att göra saker samtidigt, men inte på långa vägar lika mycket som ur en dual core, sant, men det gör nytta, en hel del. Själv väntar jag på Dual core, baserad på Dothan, med HT. sen e det julafton. Skulle inte bli förvånad om det kommer till Xeon platformen först, så mycket bättre, en dual, med dual core, med ht, 8'a virituella cpu'er.

Och, apropå ingenting, så finns inte Dothan med HT, i nuläget, men vad får dig att tro att HT skulle vara mindre effektivt, för att det sitter en snabbare cache i cpu'n...

B!

Lustigt, Förväntas komma, gick visst att missförstå ?

BTW, Priority här

spekulationer angående Dothan med HT finns/nämns här: http://www.hwzone.co.il/reviewseng.php?file=centrino2g-eng
(länken finns även på swecs framsida)

det spelar ingen roll om det är en processor med hög IPC som förlorar 10 cykler eller om det är en med låg IPC som förlorar 30 - det är endå en hel del kraft som förblir outnytjad, HT är till för att den "förlorade prestandan" ska bli mindre

I vilket fall som helst blir den mindre, och AMD valde ju att gå direkt till dualcore istället vilket lär vara mycket bättre.

Om du inte såg det Avicenna, så en Yonah cpu var demonstrerad i Frostyfrogs länk, en evolutionsgrej på Dothan, till dual core, som det spekuleras i ska vara utrustad med HT.
För Desktop platformen, ska P4'an heta Smithfield, i EE utförande ska den ha HT, icke EE uten, och det e sanolikt all skillnad där blir på de cpu'erna... med lite tur kanske även högre FSB, men det har det inte läckt nån info om... Altså är Smithfield en Dual core lösning, med HT, som man bara måste pröjsa nog för att kunna glädjas åt.

Nu har vi dock lämnat det för dagen tillgängliga...
B!

Det verkar faktiskt som att HT-motståndarna i denna tråd egentligen inte vet vad de skriver om... Jag skall försöka förklara så gott jag kan!

En modern processor exekverar flera instruktioner per klockcykel. Den använder sig desutom av out-of-order execution, vilket betyder att instruktioner kastas om så att processorns olika beräkningsenheter kan användas så effektivt som möjligt. Om vi har ett gäng ALU-operationer på gång, så betyder det ju att FPU:n kommer stå oanvänd. En god idé är då att leta efter FPU-operationer och gruppera dessa tillsammans med ALU-operationerna, så att man använder varje cykel optimalt. Tyvärr kan det vara rätt svårt att gruppera samman tillräckligt många instruktioner så att processorns enheter används fullt ut. Vi får hål, där instruktioner potentiellt skulle kunna placeras, men där vår tråd inte har något passande att erbjuda.

Vore det inte då en bra idé att köra en tråd till, parallellt med den första? Då skulle man ju nämligen kunna kolla denna efter lämpliga instruktioner och tillsammans kunde de (förhoppningsvis) fylla upp all plats optimalt. Jo, det är en bra idé och det är också detta som sker i en processor med HyperThreading. Det intressanta är att vi då inte får någon thread-swapping på samma sätt som i en vanlig processor, utan båda trådarna behandlas faktiskt samtidigt. Detta kommer att göra systemet mer responsivt, MEN det kommer också att leda till att mer arbete blir gjort totalt.

Exempel: Vi har ett flertrådat program som skall utföra två beräkningsuppgifter, där de båda uppgifterna är oberoende av varandras resultat. Med en "vanlig" processor kan vi göra detta på två sätt, antingen köra det hela som en tråd och beräkna först den ena uppgiften och sedan den andra, eller så kör vi två trådar samtidigt. Det senare fallet leder till att processorn måste byta mellan de båda trådarna kontinuerligt och i slutändan kommer det sannolikt att resultera i något längre beräkningstid. Att exekvera uppgifterna i en tråd i serie är alltså troligtvis optimalt.

Vi tänker oss nu istället att vi aktiverar HyperThreading. Vad händer då? Jo, båda trådarna körs parallellt, men processorn behöver inte byta mellan dem. Istället har den tillgång till instruktionerna som båda uppgifterna består av och kan kombinera dessa för att optimera användingen av beräkningsenheterna genom att fylla ut de hål som sannolikt annars funnits. Det krävs nu inte allt för mycket tankearbete för att inse att detta kan ge ganska stora förbättringar i processorns effektivitet. Den totala beräkningstiden för båda uppgifterna kommer att minska. Samtidigt beror ju också slutresultatet på hur de individuella uppgifterna använder processorns olika delar.

Det borde nu också vara tämligen enkelt att inse att ändring av prioritet på intet sätt kan vara ett substitut för HyperThreading (eller "simultaneous multithreading", som kanske är mer generellt). HT arbetar samtidigt med två trådar och får dessutom totalt mer beräkningar gjort än om HT inte varit aktiverat.

Hoppas detta gav lite "food for thought".

HT arbetar INTE samtidigt, cpun använder trace cachen för att fylla i luckor som uppstått i pipelinen pga stallningar.
Detta innebär att cpun kan göra mer än annars, vanligen ger detta bara en ökning på några procent dock.
Dual Core innebär samtidig execution och det är en helt annan femma, och prestanda.

Ingen har påstått att ändring av prio är ett substitut för HT heller.

Du har fel. HT innebär visst att två trådar exekveras samtidigt. Det du pratar om är inte riktigt samma sak. Pipeline-hazards beroende på beroenden instruktioner emellan är inte vad HT handlar om.
----------------------------------------------------------------
EDIT: Eller, jo, beroenden kan hindra processorn från att planera in tillräckligt många instruktioner för att fylla kärnan i nästa klockcykel. Där kommer HT in, i och med att det kan låta processorn välja instruktioner från en helt annan tråd och på så sätt fylla upp resterande platser. Bara ett litet förtydligande av vad som kommer nedan:
----------------------------------------------------------------
Däremot handlar det om att låta processorns interna planeringsenhet lägga om instruktioner så effektivt som möjligt, grundat på vilken typ av exekveringsenhet som krävs. Instruktionerna går sedan igenom processorns pipeline parallellt, men kommer att passera olika exekveringsenheter. Hazards kommer naturligtvis kunna uppstå precis som vanligt och måste tas om hand. HT gör dock att så många som möjligt av det maximala antalet platser för instruktioner som kommer exekveras samtidigt i nästkommande klockcykel är använda.

Denna behandling av flera trådar samtidigt kommer, som nämnt, inte att vara lika snabb som att göra samma sak med flera processorkärnor. Båda instruktionsströmmarna kommer fortfarande inte att gå att planera perfekt och processorkärnan kommer därför inte att nå 100% effektivitet. Detta är dock inte den enda begränsande faktorn. Värt att komma ihåg är dock att HT inte är ett "fusk" i den mening att det faktiskt är två trådar som exekveras samtidigt.

Jag rekommenderar alla som deltar i denna diskussion att studera nedanstående artikel:

http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars

Nä, det kan ju omöjligtvis utföras saker samtidigt, så gör ju inte AMD, altså möste det vara omöjligt. Och här Ljuger intel en massa bara.

B!

Den utför fortfarande inte sakerna samtidigt, utan den gör som jag redan nämnde. Cpun behandlar fortfarande bara en sak åt gången, och om du läst din citerade text lite mer noga så hade du förstått själv att Intel påstår inte ens att den gör flera saker samtidigt.
Osis!

Mikael Jag har läst dom där Arstechnica artiklarna för länge sen. Och det du pratar om nu är precis det jag sagt hela tiden.

Du förstår fortfarande tydligen inte vad vi pratar om. Och du glömde att feta in det viktigaste, att HT är en form av SMT.
Att köra 2 trådar paralellt innebär inte att processorn bearbetar trådarna samtidigt, krävs fortfarfande 2 cpus eller dual core for det, sorry.

Och du vägrar inse att poängen med HT är att olika delar av CPU'n som annars hade varit oanvända används simultant. Vad som vore intressant är varifrån du annars tror den "extra" processorkraften kommer från.

Jag fetade för övrigt in att HT är en form för SMT, var i låg ditt klagomål?

Den fyller upp oanvända delar i pipelineflödet ja, som annars gått oanvända.
Fortfarande så bearbetar den av allt en åt gången, inte samtidigt.

Du lämnade ute "a form", för HT är inte äkta SMT och har aldrig varit och Intel försöker inte påstå det heller som däremot den där artikeln som Mikael länkade till nästan verkar göra.
Ska granska det noggrannare senare, verkar vara en del rent vilsedelande saker i den.

Mr_B och Mikael har med största sannolikhet missat hela konceptet med Hyperthreading.
Instruktionerna utförs fortfarande 1 åt gången men olika trådar tillåts mera frihet i pipelinen (En av anledningarna till P4:ans 35 olösta major bugs)...

Mr_B och Mikael verkar även ha missuppfattat det jag skrev om fjanterier:
Jag skall förtydliga mig kortfattat:
Dothans sänkta latens ger Dothan en mångdubbelt större ökning av performance jämfört med Hyperthreading.
Hypertransport skulle definitivt ge en P4 eller Dothan en betydligt större ökning av performance jämfört med Hyperthreading.
Hyperthreading är snarare ett "Stödhjul" än en performance ökning.
Som att förse regalskeppet VASA med två katamaraner på var sida för att kungen krävde för hög höjd och för många kanoner i förhållande till skeppets längd, bredd och övriga beställda specifikationer.

Mvh

Det intressanta är att du missat att moderna processorer överhuvudtaget inte utför en instruktion åt gången. De kallas superskalära processorer och exekverar flera samtidigt. Detta är möjligt eftersom det finns en mängd exekveringsenheter (ALU, FP, m.m.). Processorn har en planeringsenhet som försöker lägga ut instruktionerna så att beroenden minskar och därmed minimera pipelinehazards (för att undvika stalling, m.m.). Kan den inte planera ut så många instruktioner som hårdvaran tillåter så finns det outnyttjad kapacitet. Detta drar HT nytta av genom extra hårdvara som möjliggör att instruktioner från två trådar kan användas och planeras in för exekvering.

Ännu mer intressant är att artikeln som du, AJ, länkade till hos Anandtech beskriver precis detta. Den säger också att trådarna mycket riktigt exekveras samtidigt.

In a Hyper-Threading enabled CPU, each logical processor has its own set of registers (including a separate PC) but in order to minimize the complexity of the technology, Intel's Hyper-Threading does not attempt to simultaneously fetch/decode instructions corresponding to two threads. Instead, the CPU will alternate the fetch/decode stages between the two logical CPUs and only attempt to execute operations from two threads simultaneously thus addressing the problem of poor execution unit utilization.

Notera att fetch/decode alltså sker genom alternering, medans exekvering sker simultant.

Om ni läste de artiklar som länkats till i denna tråd så skulle ni inse att själva problemet med outnyttjade exekveringsenheter inte går att lösa om inte trådarna körs samtidigt. För varje klockcykel låter nämligen processorn flera instruktioner starta sin resa genom exekveringsstegen samtidigt. Det finns inget som hindrar processorn från att låta en eller flera av dessa instruktioner tillhöra en annan tråd.

Det intressanta är varför ni verkar tro att det är så konstigt att oanvända delar av kärnan kan delas av en annan tråd... Så länge kärnan håller reda på vilka instruktioner som hör till vilken tråd, så kommer det att kunna fungera. En ALU eller FPU vet inte vart en instruktion hör, utan gör sina beräkningar och sedan lämnar den ifrån sig resultatet.

EDIT: De flesta moderna processorer klarar alltså redan att ha igång en mängd instruktioner samtidigt (superskalära, som sagt). HyperThreading handlar bara om att låta processorn välja instruktioner från inte en, utan två instruktionsströmmar i realtid vid planeringssteget. Precis som tidigare körs alltså flera instruktioner samtidigt, men vissa tillhör en annan tråd. Effekten blir simultan exekvering av två trådar. Jag är smått imponerad över att detta inte verkar ha sjunkit in vid det här laget.

Jag har inte missuppfattat det, eftersom jag hoppade över det stycket när du började dilla om de grejorna. Svårt att missuppfatta något som man varken läst eller svarat på. Jag diskuterar hur HT fungerar. Att andra grejor kan ge större prestandaökning tvivlar jag inte på.

VIKTIG EDIT:

Jag har nu hittat information som utan tvekan talar om hur det ligger till. Dokumentet kommer från Intel och är ett s.k. whitepaper som beskriver implementationen av HyperThreading i detalj. Det är dock ganska lätt att hänga med i. Det mest intressanta för oss kommer i avsnittet om P4:ans (eller i detta fall Xeons) planeringsenheter. För de som inte vet vad planeringsenheter är så är det enheter som tar emot RISC-instruktioner (kallade microops eller uops) från en eller två trådar och sorterar dem. Det ligger alltså separata köer med instruktioner före planeringsenheterna, där en kö enbart får innehålla instruktioner från en tråd.

Hur som helst; varje klockcykel lämnar flera instruktioner planeringsenheterna samtidigt, för samtidig exekvering. De utförs alltså parallellt (viktigt att förstå). Vilka instruktioner som skall sändas iväg tillsammans avgörs genom att exempelvis avgöra beroenden mellan instruktionerna (till exempel att en instruktion måste veta svaret av en annan för att kunna exekveras). Nu till det som sätter punkt för diskussionen om att P4:an inte skulle exekvera två trådar samtidigt:

Planeringsenheterna väljer instruktioner från båda köerna (alltså från båda trådarna), utan att egentligen känna till att instruktionerna faktiskt tillhör olika trådar. Det enda de vet är att de har ett gäng instruktioner i sina buffrar och att dessa måste arrangeras så att de som sänds samtidigt använder processorkärnan så optimalt som möjligt. Att de kanske faktiskt låter flera instruktioner från olika trådar gå igenom kärnan parallellt är inget som de vare sig vet eller bryr sig om. Det får processorn hantera efter exekveringssteget.

Vad betyder då detta? Jo, beräkningar/operationer utförs på instruktioner från två trådar samtidigt. Under en och samma klockcykel kan alltså tråd A få en heltalsaddition gjord, medans tråd B får en flyttalsdivision gjord. Vi har med andra ord en processor som faktiskt exekverar två trådar samtidigt.

För att ni inte skall tro att jag hittar på detta så har ni nedan länken till Intels whitepaper + urklipp ur detta med särskilt relevant delar utmärkta i fet stil. Jag räknar med att ni som gång på gång läxar upp mig om hur fel jag har läser igenom detta. Om ni sedan fortfarande tycker att jag har fel så tycker jag ni skall förklara, ingående, vad som inte stämmer i mitt resonemang.

http://www.intel.com/technology/itj/2002/volume06issue01/art0...

Instruction Scheduling

The schedulers are at the heart of the out-of-order execution engine. Five uop schedulers are used to schedule different types of uops for the various execution units. Collectively, they can dispatch up to six uops each clock cycle. The schedulers determine when uops are ready to execute based on the readiness of their dependent input register operands and the availability of the execution unit resources.

The memory instruction queue and general instruction queues send uops to the five scheduler queues as fast as they can, alternating between uops for the two logical processors every clock cycle, as needed.

Each scheduler has its own scheduler queue of eight to twelve entries from which it selects uops to send to the execution units. The schedulers choose uops regardless of whether they belong to one logical processor or the other. The schedulers are effectively oblivious to logical processor distinctions. The uops are simply evaluated based on dependent inputs and availability of execution resources. For example, the schedulers could dispatch two uops from one logical processor and two uops from the other logical processor in the same clock cycle. To avoid deadlock and ensure fairness, there is a limit on the number of active entries that a logical processor can have in each scheduler's queue. This limit is dependent on the size of the scheduler queue.

MEGA FLOPP IGEN MIKAEL:

En enskild Processor kan fortfarande enbart exekvera en instruktion vid en tidpunkt t.
En instruktion tillhör 1 tråd.

Mvh

Herregud! Har jag spenderat all denna tid att svara till någon som inte ens har en grundläggande uppfattning om hur en superskalär processor fungerar (eftersom du verkar utge dig för att veta vad du skriver om)? Skärpning nu, för helsike, rent ut sagt!

Hur i hela friden tror du att en processor kan ha en IPC > 1 om den inte kan behandla flera instruktioner parallellt?

EDIT:

Vet inte vad som krävs för att övertyga dig. Du kanske kan göra en sökning på Google med "superscalar CPU"? Det gav mig i alla fall kvickt följande:

As the decoder is able to decode 3 instructions, it is interesting to be able to issue to a lot of execution units. That way it is less likely that the reservation unit can not issue a instruction because one of the needed execution units is busy.

The PII(I) can decode (maximum) 3 x86 instructions, so we say it is a 3-way superscalar CPU. Superscalar means in other words processing more than one instruction at a time.

http://www.aceshardware.com/Spades/read.php?article_id=51

IPC är ej lika med 1 t.

Vilket en logiker direkt hade insett.
En fysiker hade frågat sig om personerna som marknadsför Hyperthreading hade fel i hjärnan eftersom det enligt definitionen av parallelism är omöjligt.
#1 Man kan dela in ett tidsintervall i ett så stort antal tidsdelar att inget inträffar samtidigt.
#2 En följd av detta är att man måste få olika delar av en processor att passa tiden så att elektronerna inte hamnar fel i de olika stadierna av en klockpuls.

#3 IPC är inget universalmått utan snarare ett genomsnitt för en genomsnittslig kodmängd.
Exempelvis kan en AMD rent teoretiskt utföra 3 flyttalsoperationer per klockcyckel beroende på konstruktionen samt att den har 3 flyttalsenheter.
Intels P4 kan teoretiskt utföra 2 flyttalsoperationer beroende på kosntruktionen samt att den har två flyttalsenheter.
I verkliheten blir det sällan detta stora antal flyttalsoperationer utan det blir 1/2 för intellen och 1 för AMD:n........det är nämligen nästan omöjligt att placera isntruktionerna i sådan ordning att de utnyttjar hårdvaran optimalt.
Hyperthreading är i många fall boven i dramat och i de flesta iterativa beräkningar går det snabbare om HT stängs av.

#4 Skillnaden på en pipeline med 12 och 36 stages.........kan beskrivas på flera sätt:
Om 2 processorer arbetar i samma klockfrekvens och har samma IPC men den ena har 12 stages och den andra har 36 stages, hur många trådar kan de exekvera på samma tid givet att alla trådar är lika långa?

ETT av många möjliga svar: processorn med 12 stages exekverar 3 gånger så många trådar som processorn med 36 stages på samma tid.

#5 "The PII(I) can decode (maximum) 3 x86 instructions, so we say it is a 3-way superscalar CPU. Superscalar means in other words processing more than one instruction at a time."
-PROCESSAR OCH EXEKVERAR ÄR OLIKA SAKER, PROCESSAR INNEBÄR ENBART ATT DEN UNGEFÄR HAR 3 OLIKA INSTRUKTIONER FARANDE I PIPEN SAMTIDIGT, SO WHAT?

Mvh

Eftersom procesorn har flera beräkningsenheter så kan den utföra instruktioner parallellt. Alltså samtidigt. Sedan kanske det inte blir exakt vid samma tidpunkt beroende på fördröjningar, men det kan också bli det utan att orsaka några problem. Varför? Eftersom beräkningsenheterna är skilda åt. FPU:n struntar i om ALU:n gör något eller inte gör något, den kommer att göra sitt i alla fall. Med andra ord kan båda jobba på varsin instruktion PRECIS SAMTIDIGT. Tidsintervallet mellan de båda klockcyklerna är inte uppdelat så att lite tid är tilldelad varje instruktion, utan varje instruktion har hela intervallet på sig att ta sig igenom parallellt med sina bröder och syskon. När en puls kommer så ger sig alltså alla planerade instruktioner iväg samtidigt, propagerar genom beräkningsenheterna och klockas samtidigt in i registren på andra sidan.

EDIT:

Att en processor har flera instruktioner igång samtidigt är själva definitionen av en pipelinad arkitektur. Det är inte det som avgör om processorn är superskalär eller inte. En pipelinad processor har optimalt en instruktion igång i varje steg, men det innebär ju att bara en instruktion kan hoppa ur slutet på pipelinen varje klockcykel.

EDIT2:

Det intressanta är att båda processorerna du beskriver skulle ha exakt samma prestanda i verkligheten. Om man har två processorer som båda slutför samma mängd instruktioner varje klockcykel och dessutom går på samma frekvens, ja då kommer samma arbete att utföras på samma tid.

"Eftersom procesorn har flera beräkningsenheter så kan den utföra instruktioner parallellt. Alltså samtidigt. Sedan kanske det inte blir exakt vid samma tidpunkt beroende på fördröjningar, men det kan också bli det utan att orsaka några problem. Varför? Eftersom beräkningsenheterna är skilda åt. FPU:n struntar i om ALU:n gör något eller inte gör något, den kommer att göra sitt i alla fall. Med andra ord kan båda jobba på varsin instruktion PRECIS SAMTIDIGT. Tidsintervallet mellan de båda klockcyklerna är inte uppdelat så att lite tid är tilldelad varje instruktion, utan varje instruktion har hela intervallet på sig att ta sig igenom parallellt med sina bröder och syskon. När en puls kommer så ger sig alltså alla planerade instruktioner iväg samtidigt, propagerar genom beräkningsenheterna och klockas samtidigt in i registren på andra sidan."
-DETTA ÄR INTE PARALLELISM.
Inget kan ske exakt samtidigt utan prollen måste ha väntetider för att alla delar av en processor skall kunna samverka.
VARFÖR FANTISERAR DU om mina inlägg, varför fantiserar du om att jag har skrivit om tids tilldelning?

Det intressanta är att båda processorerna du beskriver skulle ha exakt samma prestanda i verkligheten. Om man har två processorer som båda slutför samma mängd instruktioner varje klockcykel och dessutom går på samma frekvens, ja då kommer samma arbete att utföras på samma tid.
"NEJ EFTERSOM VÄNTETIDEN BLIR 36 stage förflyttning för den ena prollen och 12 för den andra.

Förövrigt om vi nu tar intels lilla P4 som exempel så sker inga av flyttalsoperationerna samtidgt utan en intel P4 kan under BÄSTA FÖRUTSÄTTNINGAR: ta emot resultatet från en flyttals enhet under början av en klockcyckel, skicka instruktionen till en flyttalsenhet under slutet av en klockcyckel samt givetvis skicka instruktionen i början av klockcyckeln till flyttalsenheten och ta emot resultatet till flyttalsenheten under samma klockcyckel. DVS I genomsnitt under BÄSTAFÖRUTSÄTTNINGAR 2 flyttalsoperationer per klockcyckel dock aldrig exakt samtidigt.

Problemet för dig är att du lever i en förenklad abstraktion där Klockpulser IPC och bogus parallelism är uppfunna för att personerna som säljer datorer skall slippa lära sig hur sakerna igentligen fungerar.....detta gör dem ju till bättre säljare!

LOL

Väntetiden innan resultatet för de första instruktionerna börjar dyka upp på andra sidan pipelinen är 36 klockcykler (10ns i 3,6GHz), mot 12 cykler (3,33ns i 3,6GHz). Det är alltså längre fördröjning i processorn med längre pipeline. Detta gäller dock bara i startögonblicket. Eftersom en tråd oftast har många gånger fler instruktioner att exekvera så är denna tid obetydlig i detta fall. När både den långa och den korta pipen fyllts så kommer exakt lika många instruktioner att ramla ur båda varje klockcykel. Det tar alltså som värst 6,66ns längre att exekvera en tråd i processorn med längre pipeline. Ganska obetydligt.

Som det är idag så är AMD det bästa valet. Varför?

1. Athlon64 presterar bäst i 80-90% av alla vanliga program, allt ifrån spel till 3d rendering, WinRAR, filmredigering, kompilering osv. Athlon64 tar även PentiumM i samma frekvens:

(Jämför t.ex Athlon64 3200+ 2.0Ghz Socket939 mot 2Ghz Pentium M, även priset)
http://anandtech.com/cpuchipsets/showdoc.aspx?i=2342&p=11

2. AMD's processorer utvecklar mycket mindre värme än Intel's processorer, man klarar sig alltså på ganska enkel kylning, även överclockat. Väljer man Winchester modellen av Athlon64 processorn så får man en processorn som är ännu svalare då denna kör 90nm tillverkningsprocess.

3. AMD's Athlon64 processor har alltid haft "AMD64", dvs x86-64, simultan 32 och 64-bitars kod utan problem. Nu har ju Intel också integrerat "AMD64" i sina processorer som dom kallar "EM64T", dock så är Intel's version något bantad (färre register) och får inte samma prestandaboost i 64-bitars applikationer som Athlon64.

Test:

http://www.xbitlabs.com/articles/cpu/display/x86-64-rc1_10.ht...

4. AMD's processorer är billigare och har alltid varit, ta t.ex Athlon64 3800+ dom kostar 3785Kr mot Intel's 3.8Ghz prescott som kostar 5392Kr. I DETTA test så vinner 3800+ 24 gånger av 41 mot Intel 3.8Ghz prescott (många gånger överlägset).

Sen när man kommer till 64-bitars program så har Pentium4 ingen chans.

Med andra ord, köp en Athlon64 efter plånboken, och skall du köpa 3000+, 3200+ eller 3500+ som alla är Socket939, så väljer du winchester. Kan tillägga att jag byggde en dator med en Winchester 3000+ som klockar 2.8Ghz primestabilt i 46c med CNPS7000-cu kylare.

http://buggy.no-ip.com/sok.php?f%5B%5D=Alla&k%5B%5D=Alla&n=10...

Att Intel's processorer vore mer instabila i Microsofts mjukvaror är inte sant, dock så kan man börja fundera på vilken av processorerna som rent tekniskt håller längst eller är mest instabil. Min erfarenhet är enligt tester, texter och eget testande att Athlon64 är mest stabil då den opererar på en mycket lägre temperatur och lägre frekvenser och färre erratas. Jag vill i alla fall inte säga att Intel gör instabila processorer för det gör dom inte.

AMD är bättre i dom flesta program, sen om man tycker det är kul med syntetiska tester så får man tycka det, man har ändå ingen användning av det i programvaror man använder i alla fall.

AMD och Intel är inte samma sak prestandamässigt när det gäller "AMD64".

http://www.xbitlabs.com/articles/cpu/display/x86-64-rc1_10.ht...

Och det är PRAKTISKA tester, dvs hur processorerna presterar i real time.

Värt att tilläggas är att Athlon64 är bra mycket bättre på multitasking än AthlonXP och det finns många enkla orsaker till detta:

1. Athlon64 har en Hypertransport bus på 1Ghz (2Ghz i duplex) för bara I/O kommunikation, dvs kommunikationen mellan alla enheter i datorn. Tänk er vilken fördel detta är när man kommer till alla enheter som använder sig av DMA.

2. Athlon64 har integrerad minneskontroller som gör att data i minnet kan hämtas fortare och gör hela processorn mer effektiv, även i multitasking då minnesbussen (mellan minneskontroller och minnet) och hypertransport är helt separerade från varandra (dubbla bussar).

Det Intel's P4 prescott är bättre på är viss encoding i video och ljud program, dock inte alla. I 3D rendering så är Intel marginell med AMD.

Ang multitasking, hyperthreading och processorer så kan man ju alltid diskutera. En singelprocessor som saknar flertrådsteknik klarar man sig 99% av alla fall mycket bra på då en processorn är så snabb på att växla mellan olika processer. Sen så är operativsystemet mycket viktigt i denna punkt. T.ex så är Linux betydligt bättre att arbeta med simultana processer än vad Windows är. Programmerare kan ju även bestämma prioritet av processorkraft i sina progam om dom vill eller så gör operativsystemet det.

Pentium4 processorer är dock bättre på tung multitasking, dvs om du måste encoda film, packa upp .RAR paket, spela samtidigt och så vidare, i extremfall dvs. Rent teoretiskt så kan en singel processor hantera multitasking perfekt och lasten blir balanserad, men kör som som sagt Windows så blir det många gånger inte så. Ett simpelt test jag gjorde var att två processer fick prioritet "normal" och det slutade med att den ena processen drog 100% cpu load. Dåligt, det skall vara 50/50 i load.

Sledge... tack men det var inte bench AMD64 vs P4/Intel som var frågan (även om du så grundligt informerade om möjliga alternativ på AMD-sidan)

jag har ingen koll angående duplex i HTT men kan du ge en snabb länk angående påståendet tack?

Mikael en sista fråga som DU måste kunna svaret på!

Är klockfrekvensen och IPC ett resultat av pipelinen?

MVH

Jag antar att din fråga är om klockfrekvens och IPC är beroende av pipelinens utforming. I så fall:

Hur högt man kan nå i klockfrekvens beror till viss del på pipelinens längd, ja.

IPC påverkas av hur de olika pipelinestegen är utformade, exempelvis hur många beräkningsenheter som finns i exekveringssteget. Även saker som forwarding påverkar effektiviteten och det är ju defintivt en aspekt som hör till pipelinens design.

Vadå tack?

För det första så skrev jag inte till dig och för det andra så handlar tråden om AMD vs Intel. Tråden heter Intel eller inte och jag skriver varför man bör välja AMD framför Intel och kommer även med tester osv.

Sen så vet du mycket väl att HT är på 1Ghz, dvs det blir 2Ghz full duplex. Eller är 1+1 för svårt?

jag uppfattade utformningen på ditt förra inlägg som att det var från "AMD-hållet" dvs "AMD bättre än Intel" och inte "Intel är bättre än AMD" skilnaden är givetvis mest formell, men på intelforumet så verkar det snyggare att börja jämförelsen från Intelprocessorer och inte från AMDprocessorns vinkel

angående "1GHz" vet jag, det jag inte vet är om det är duplex eller inte.. jag kommer inte ihåg om det är medräknat redan i början eller ej helt enkelt... inget konstigare än så
sedan "för bara I/O-kommunikation" - räknas inte minneshantering som I/O-kommunikation i detta fallet? eller har jag missat något viktigt/grundläggande om HTT