Bilder av Tejas - Pentium V

[Raider]

BOXED versionene kommer sikkert med SLK900

[LoS]

BOXED versionene kommer sikkert med SLK900

Og det er ille fordi??

 

Knick Knack: leser linken din i morra/senere idag, for jeg skjønte ikke bæret

Endret 12. januar 2004 av LoS

[rlz]

BOXED versionene kommer sikkert med SLK900

Og det er ille fordi??

 

Tror ikke han mener at det er ille, men heller kewlt

[Knick Knack]

BOXED versionene kommer sikkert med SLK900

Og det er ille fordi??

 

Knick Knack: leser linken din i morra/senere idag, for jeg skjønte ikke bæret

Nei, Jeg innrømmer at jeg slet litt selv. Uansett så er det sånn at lengre pipelines på samme frekvens gir dårligere ytelse så lenge det kun er en tråd som kjøres. Bare for å ha det klart! Altså ikke noe hokus pokus og annen svart magi.

 

Lengre pipelines er et resultat av å gjøre prosessoren bredere. Se for deg at du kjører til jobben hver dag på en kort smal vei. Det går fint så lenge det bare er du som kjører på den veien. Med en gang det begynner å bli mye trafikk, så blir det kø og du må bruke lengre tid på kjøring. Alternativet Intel presenterer er å gjøre veien bredere, men for å spare penger(transistorer) så velges en løsning der en legger veien i en lengre sløyfe. Så nå har vi en bred vei (6 felt) som er noe lengre en den forige veien. Dette er helt klart ikke noen fordel så lenge du er den eneste som kjører på denne veien, siden du bruker lengre tid fra A til B. Siden det nå er flere filer i hver retning skulle altså tro at det burde gå kjappere å komme fra A til B på dager med mye trafikk, men vi er ennå på Netburst, Willamette stadiet og det viser seg at veien har bare en innkjøring og denne er valgt av Intel til å være 3 filer bred siden de har regnet ut at det i gjennomsnitt bare vil komme 2.5 biler (instruksjoner) sammtidig (per klokkesyklus). Neste byggetrinn er Northwood og etter hvert kommer mer avansert veinett i forbindelse med innkjøringen (HT) slik at flere biler kan kjøre inn på veien sammtidig (og her begynner vei sammenligningen å slite ja så vi går over til dataspråk)..

 

Altså status er nå Northwood og HT er implementert. Vi vet at det magiske tallet for en tråd er 2.5 IPC i gjennomsnitt og at Netburst kan håndtere max 6 instruksjoner sammtidig (teoretisk, kan f. eks. ikke benytte den samme delen av en execution unit til mer enn en instruksjon, men siden hver execution unit er delt opp i flere påfølgende deler så kan det altså være mer enn en instruksjon som benytter en execution unit til enhver tid). Vi husker også at dette er snevret inn til 3 issue ports slik at selv om instruksjonene i to tråder er slik fordelt at det ville være mulig å utføre 6 IPC (usannsynlig pga krangling om ressurser) så vil NW bare kunne utføre 3 IPC. Prescott skal få en ekstra issue port slik at max er 4 IPC for to tråder. Ved kjøring av en tråd vil en også kunne oppnå 4 IPC og dermed øke ytelsen noe av den grunn, men som sagt i snitt vil IPC for en x86 tråd ligge på 2.5.

Endret 12. januar 2004 av Knick Knack

[LoS]

BOXED versionene kommer sikkert med SLK900

Og det er ille fordi??

 

Tror ikke han mener at det er ille, men heller kewlt

I say no more

 

Knick Knack; tror nesten jeg klarte å holde følge denne gangen her

 

Edit: OMG den avataren var svææææææææær!!!

Endret 12. januar 2004 av LoS

[Martin Lie]

Ser Dell kjører en dansk kampanje for sine datamaskiner der de gjør et stort poeng ut av å ikke oppgi frekvenser og annen teknisk informasjon kundene likevell ikke kan nyttegjøre seg av.

Bare av nysgjerrighet: Hva er det de oppgir da? "Bra PC", "Bedre PC, "Best PC"? Litt morsomt å vite hvordan de tenker å posisjonere maskiner i forhold til hverandre, og hva de gjør når nye, oppdaterte maskiner kommer...

[Knick Knack]

Ser Dell kjører en dansk kampanje for sine datamaskiner der de gjør et stort poeng ut av å ikke oppgi frekvenser og annen teknisk informasjon kundene likevell ikke kan nyttegjøre seg av.

Bare av nysgjerrighet: Hva er det de oppgir da? "Bra PC", "Bedre PC, "Best PC"? Litt morsomt å vite hvordan de tenker å posisjonere maskiner i forhold til hverandre, og hva de gjør når nye, oppdaterte maskiner kommer...

Husker ikke teksten nøyaktig. Reklamen går på Discovery. Det er bilde av et Dell miditower og en 15" flatskjerm. Så blir det opplyst at den benytter P4 og har CD eller DVD brenner (husker ikke). Det var stort sett det som var av tekniske detaljer. Men klart at for en kunde som vet like lite om PC som jeg vet om seilbåter så er dette mer enn nok. Er imidlertid veldig avhengig av at selgeren ikke forsøker å lure deg. Tror forøvrig dette kan bli en viktig trend i masse-markeder. Fokus går fra teknologi og ytelse til funksjonalitet, design, støy ol. Ytelsen er uansett god nok for en kunde som ikke vet forskjellen på prosessorer fra Intel, AMD eller Creative.

Endret 12. januar 2004 av Knick Knack

[[Protus]]

Det sies at nen nye LGA 775 sokkelen skal brukes i overskuelig framtid.

Der røk håpet om intregrert minnekontroller i fremtidige Intel-CPUer.

Tragisk, både for ytelsen (AMD`s løsning har vist seg å være svært så vellyket) og for oss som liker å oppgradere (For med en intregrert løsning kan man jo bare kjøpe ny CPU og minne og ikke tenke på hva hk`et støtter, så fremst man klarer å bruke en standard for minne-DIMMer (eeler hva det nå het)) i lengre tid.

[Simen1]

' date='12/01/2004 : 23:30'] Det sies at nen nye LGA 775 sokkelen skal brukes i overskuelig framtid.

Der røk håpet om intregrert minnekontroller i fremtidige Intel-CPUer....

.. i overskuelig fremtid. Og overskuelig fremtid i databransjen er ikke så veldig lenge. Jeg tipper det er rundt 2 år de mener.

[Knick Knack]

Kan ikke se at LGA775 utelukker integrert minnekontroller. Nå er det også slik at håndtering av minne delay kan gjøres på flere måter. Flytte minnekontrolleren til CPU die er ett tiltak, HT og dualcore er eksempler på andre tiltak. Intel ser ut til å velge HT og dualcore, mens AMD ser ut til å velge flytting av minnekontroller og dualcore. Throughput computing teknikker som HT og dualcore vil skalere bedre med frekvens, mens flytting av minnekontroller bidrar til å løse problemet på en måte de to andre metodene ikke kan konkurrere med når CPU last er skjevt fordelt på en tråd. Det beste hadde vært å benytte alle tre teknikker, men det vil medføre at Intel må gjøre radikale endringer i sin chipset/minne arkitektur, mens AMD måtte endre CPU arkitektur for å kunne benytte HT. Jeg tror ikke AMD tar seg bryet med å legge inn HT lignende løsninger siden gevinsten ikke blir veldig stor i kombinasjon med dualcore. Jeg tror heller ikke Intel kommer til å flytte minnekontrolleren, men dette er mer sannsynlig, særlig hvis det viser seg at multithreaded programvare ikke blir særlig utbrett.

Endret 12. januar 2004 av Knick Knack

[Boralis]

BOXED versionene kommer sikkert med SLK900

Og det er ille fordi??

 

Tror ikke han mener at det er ille, men heller kewlt

I say no more

 

Knick Knack; tror nesten jeg klarte å holde følge denne gangen her

 

Edit: OMG den avataren var svææææææææær!!!

Vel den er ikke akkurat frozen, men kan fortelle at en A64 3000 ligger på 36 grader idle med boxed kjølern dette ved ca 22 grader i rommet, vifta er forholdsvis støysvak.

Bare som en orientering om noen lurte.

Endret 13. januar 2004 av Snekker`n

[Martin Lie]

Forstår godt at du ikke skjønner hva jeg snakker om. Jeg var av nøyaktig samme oppfattning som deg inntil jeg blandt annet leste denne artikkelen

Det virker på meg som om denne siden for det meste snakker om SMT og SMP, pluss halvveis-SMT-formen "super-threading". Jeg savner en artikkel som forklarer mer om forholdet mellom lange pipelines og SMT. Har du referanser til det også?

 

Selve artikkelen var god og oppklarende, men jeg synes ikke den stilte HT i et veldig godt lys, egentlig. Den påpeker derimot at HTs eventuelle ytelsesforbedringer avhenger av sammensetningen av applikasjonene som kjøres, og at HT kanskje helst bør ses på som et kopliment til SMP, og ikke som en selvstendig velgjører. Videre viser artikkelen de tekniske detaljene som grunngir hvorfor HT faktisk kan redusere ytelsen hvis man har en uheldig sammensetning av programmer kjørende.

[Knick Knack]

Hmm. Pussig at du kom til den konklusjonen. Jeg skal se på det i kveld.

[Simen1]

Kan ikke se at LGA775 utelukker integrert minnekontroller....

Netburst-arkitekturen har vist seg å være veldig avhengig av høy båndbredde, og ikke så veldig mye av lav latency, dermed bør doble minnekanaler være en selvfølge for en eventuell integrert minnekontroller på netburst.

 

Fordelen med integrert minnekontroller er stort sett at latencyen blir langt lavere og ikke så mye at båndbredden blir høyere. Dermed vil nok ikke netburst tjene nært like mye på integrert minnekontroller som K7/K8-arkitekturten.

 

En annen ting er også at dobla minnekanaler vil kreve rundt 300 ekstra pinner på coren. 128 av disse til selve databussen, og mange flere til kontrollbussene, avbrudds-og konfigurasjons-pinner og sikkert ennå mer som jeg ikke aner hva er. Dette er neppe noe de har gjort plass til på LGA775-sokkelen. Dermed kan man egentlig glemme integrert minnekontroller så lenge den sokkelen er i bruk.

 

Vi får se hva som skjer når intel går over til neste CPU-arkitektur... *håpe*

[Knick Knack]

Netburst-arkitekturen har vist seg å være veldig avhengig av høy båndbredde...

Jeg er vel sånn delvis enig. Netburst er minst like følsom for latency mot minne som AMD64 under to omstendigheter: Enten er HT skrudd av eller så er all last på en tråd, noe som er vanlig i dag.

 

Det blir nok heller ikke aktuelt med doble minnekanaler på LGA775, som du sier, men jeg vil presisere at det gjelder for DDR SDRAM. For ODR (8 x clk) Rambus minne (kalles vel XDR minne?) vil dette være fullt mulig sien det er lavere pin count. Det spørs bare om minneindustrien kommer til å boikotte Rambus en gang til.

 

Har forøvrig ikke tro på at Intel vil flytte Xeon over på en løsning med intern minnekontroller. Det ville gjort mange systemintegratorer svært oppgitte fordi de måtte kaste så mye knowhow og komponenter på dynga. Derfor blir det vel tidligst ved neste generasjon (Nehalem) at intern minnekontroller kan bli en realitet. Innen den tid kan muligens Deerfield (IA64) etterfølgeren ha tatt over mye av Xeon markedet.

 

"Vi får se hva som skjer når Intel går over til neste CPU-arkitektur... *håpe*"

Hva enn de måtte planlegge så må de heldigvis ta høyde for konkurrentene. Da spesielt AMD og Apple som vel er de eneste som kan måle seg på ytelse.

[Turgon]

Kan ikke se at LGA775 utelukker integrert minnekontroller. Nå er det også slik at håndtering av minne delay kan gjøres på flere måter. Flytte minnekontrolleren til CPU die er ett tiltak, HT og dualcore er eksempler på andre tiltak. Intel ser ut til å velge HT og dualcore, mens AMD ser ut til å velge flytting av minnekontroller og dualcore. Throughput computing teknikker som HT og dualcore vil skalere bedre med frekvens, mens flytting av minnekontroller bidrar til å løse problemet på en måte de to andre metodene ikke kan konkurrere med når CPU last er skjevt fordelt på en tråd. Det beste hadde vært å benytte alle tre teknikker, men det vil medføre at Intel må gjøre radikale endringer i sin chipset/minne arkitektur, mens AMD måtte endre CPU arkitektur for å kunne benytte HT. Jeg tror ikke AMD tar seg bryet med å legge inn HT lignende løsninger siden gevinsten ikke blir veldig stor i kombinasjon med dualcore. Jeg tror heller ikke Intel kommer til å flytte minnekontrolleren, men dette er mer sannsynlig, særlig hvis det viser seg at multithreaded programvare ikke blir særlig utbrett.

For det første så skjønte jeg ikke bæret av den linken, men det er så sin sak.

 

Jeg tviler på at intel vil kunne imlementere en minnekontroller på cpuen med socket T, i hvertfall ikke dual channel. AMD trenger 939 pinner til å gjøre det, og jeg tror intel vil trenge omtrent det samme om de ikke finner på noe genialt. Det andre er at de allerede bruker mange pinner på å legge til rette for normalt minne oppsett. En annen ting er at det er totalt meningsløst å bruke samme socket siden det gamle (uten minnekontroller) og det nye ikke vil kunne brukes om hverandre for en femøring.

 

AMD vil ikke kunne utnytte HT i noen særlig grad siden piplinsene er ganske korte og ikke har noe særlig problemer med at prosessoren "gjetter" feil.

[Martin Lie]

Hmm. Pussig at du kom til den konklusjonen. Jeg skal se på det i kveld.

Har du fått sett på dette igjen? Så vidt jeg så var ikke det forrige du skrev direkte relatert til mine kommentarer?

[Knick Knack]

Hmm. Pussig at du kom til den konklusjonen. Jeg skal se på det i kveld.

Har du fått sett på dette igjen? Så vidt jeg så var ikke det forrige du skrev direkte relatert til mine kommentarer?

Ah! glemte det. Det var mye om HT i den artikkelen da! Leser du alt sammen så ser du hvordan det henger sammen. Forøvrig en del andre artikkler på samme stedet som er svært interessante, og tekniske.

[Martin Lie]

AMD vil ikke kunne utnytte HT i noen særlig grad siden piplinsene er ganske korte og ikke har noe særlig problemer med at prosessoren "gjetter" feil.

Hvis jeg forstod "Knick Knacks artikkel" korrekt, så vil HT også hjelpe uavhengig av lengden på pipelines. La meg prøve å forklare:

 

Ettersom en CPU er raskere klokket enn minnet, vil det uunngåelig skje at en tråd stopper å sende nye instruksjoner til utførelse (i pipelinen), fordi den venter på nødvendig data fra minnet. Her vil noen CPU-sykler gå tapt (for tråden). Det er forøvrig dette tapet som reduseres ved å velge minne som har lavere timings (CL, CAS, osv.).

 

Uten HT utføres kun én tråd på prosessoren samtidig, og ovennevnte klokkesykler går faktisk tapt. Tråden venter til minne-dataene kommer tilbake, eller til den blir kastet ut av prosessoren (i et såkalt "context switch") til fordel for en annen tråd (det er dette konseptet som gjør multitasking mulig i det hele tatt - én tråd får bare en viss tid til rådighet før den må stille seg bak i køen igjen og vente på ny kjøretid).

 

Med HT vil to tråder utføres samtidig på prosessoren. Forenklet sett, så deler de på de forskjellige enhetene som prosessoren består av. De delene av prosessoren som ikke brukes av den første tråden, kan tas i bruk av den andre tråden (og motsatt). Så mens én tråd venter noen klokkesykler på data fra minnet, så kan den andre tråden ta seg til rette, slik at prosessoren gjør mer nyttig i de klokkesyklene som ellers ville gått tapt uten HT.

 

Dette er grunnen til at HT-prosessorer er mindre latency-avhengige (i teorien hvertfall), og dette ville altså AMDs prosessorer også hatt nytte av. Men om det er verdt å implementere HT til fordel for å jobbe med andre løsninger aner jeg ikke.

 

Edit: Typo...

Endret 14. januar 2004 av Pureblade

[Martin Lie]

Det var mye om HT i den artikkelen da! Leser du alt sammen så ser du hvordan det henger sammen.

*kremt* Mener du at hvis jeg leser alt, så skjønner jeg sammenhengen og endrer mening? Altså at konklusjonen jeg dro tidligere er feil? Det er hvertfall slik jeg forstår deg nå, men rett meg gjerne om jeg tolker deg feil.

 

Nå har det seg slik at jeg faktisk leste alt, og jeg er av den oppfatning at jeg også forstod sammenhengene. Jeg leste til og med forfatterens konklusjon, der det står følgende:

 

"The fact that Intel until now has made use of hyper-threading only in its SMP Xeon line is telling. With hyper-threading's pitfalls, it's perhaps better seen as a compliment to SMP than as a replacement for it. (...) In the end, I expect SMT [HT = SMT -Pureblade] to shine mostly in SMP configurations [sMP = fler-prosessor-oppsett -Pureblade], while those who use it in a single-CPU system will see very mixed, very application-specific results."