Slå av HyperThreading

[john.einar]

Flere instruksjoner per tråd, flere tråder per kjerne, flere kjerner per CPU, flere CPUer per system.

Kan vel slenge med 'Flere system per cluster' også da.

Men du har helt rett at all denne flere-per-enhet teknologien ikke egner seg for oppgaver som f.eks. spill. I bunn og grunn vil en cpu som er en fet pipe som er så bra laget at den ikke staller grunnet memory fetch og slik alltid være bedre enn en HT/multi-coret/multi-chip'et/multi-systemet løsning grunnet deres behov.

Eneste multi-instruksjon som et spill kan sies å ha behov for.

[Knick Knack]

Flere instruksjoner per tråd, flere tråder per kjerne, flere kjerner per CPU, flere CPUer per system.

Kan vel slenge med 'Flere system per cluster' også da.

Men du har helt rett at all denne flere-per-enhet teknologien ikke egner seg for oppgaver som f.eks. spill. I bunn og grunn vil en cpu som er en fet pipe som er så bra laget at den ikke staller grunnet memory fetch og slik alltid være bedre enn en HT/multi-coret/multi-chip'et/multi-systemet løsning grunnet deres behov.

Eneste multi-instruksjon som et spill kan sies å ha behov for.

Vi får håpe at cpu produsentene ikke blir så gira på slik thread level parallelism (TLP) at de helt glemmer instruction level parallelism (ILP) og klokke frekvens. ILP, høy klokkefrekvens og lav minne forsinkelse er den eneste måten å øke ytelsen i ALLE typer programmer på. Det jeg frykter er at disse blir glemt til fordel for TLP og multicore prinsipper siden dette vil kunne gi ekstreme ytelsesforbedringer om en bare velger "riktig" benchmark.

[balleklorin]

For å få god ytelse ut av TLP så er det også nødvendig at de tenker ILP så det tror jeg ikke du trenger å bekymre deg for

[Knick Knack]

For å få god ytelse ut av TLP så er det også nødvendig at de tenker ILP så det tror jeg ikke du trenger å bekymre deg for

Nei den koblingen ser jeg ikke. Niagara er jo et perfekt eksempel på det motsatte! Nesten ingen ILP masse TLP og "kun" brukbar til webserver.

[balleklorin]

Måtte bare komme med en kommentar til at spill ikke egner seg til smp, det er til dels sant i den form at det er vanskelig.. men det vel få vanlige applikasjoner som trenger mer prosessorkraft enn akkurat spill, og slik det ser ut nå med stagnasjon i klokkefrekvens og andre kreative løsninger... så blir det multicore å forholde seg til fremover. Det finnes flere måter å programmere multiprosessorssytemer på enn vanlige windows threader, og kanskje det er det vi begynner å skimte konturene av etterhvert.. Jeg vil tro at det er behov for andre modeller enn treading når det gjelder spill, men det er ikke dermed sagt at dualcore/smp ikke egner seg til spill (om noen år).

[snorreh]

Knick Knack: ILP "brønnen" nærmer seg tom, noe også Intel har innsett, derfor blir det nå TLP for alle penga. Det er jo ikke helt uten grunn at Itanium også får SMT-støtte nå

[balleklorin]

For å få god ytelse ut av TLP så er det også nødvendig at de tenker ILP så det tror jeg ikke du trenger å bekymre deg for 

Nei den koblingen ser jeg ikke. Niagara er jo et perfekt eksempel på det motsatte! Nesten ingen ILP masse TLP og "kun" brukbar til webserver.

Ja, hvis den kun er brukbar til webserver så er det vel å anse som en "mangel" at den ikke har god ILP da eller hva? Dessuten så kommer multicore til desktop markedet også, med andre behov og andre applikasjoner og benchmarks, noe som jeg tror setter fokus på begge deler.

[Simen1]

Ja, hvis den kun er brukbar til webserver så er det vel å anse som en "mangel" at den ikke har god ILP da eller hva?

På ingen måte! Niagara er kun ment å kjøre typiske webserveroppgaver. Så lenge den gjør jobben sin glimrende så skjønner jeg ikke at du kritiserer den for å ikke gjøre andre sine jobber bra nok.

[Simen1]

Slik jeg ser det så går utviklingen innen single-thread ytelse på x86 stadig saktere. Det tyder på at det meste av ytelse allerede er hentet ut fra ILP og nesten den eneste ytelseforbedringen kommer fra økt klokkefrekvens (som resultat av bedre produksjonsprosesser)

 

På x86 er det derimot et potensiale som ikke har vært hentet ut nevneverdig før, og det er multitråd-ytelse. Dette kommer nok til å bli en stor opptur de nærmeste årene. Det er jo synd at ytelsen i hver tråd ikke følger med i samme takt, men det får man bare svelge når man har møtt veggen.

 

På andre arkitekturer enn x86 er det ennå mye ytelse å hente fra ILP, så der kan enkelttråd-ytelsen øke ennå en god stund. Noen av disse arkitekturene vil helt sikkert bli vidreutviklet for bedre enkettråd-ytelse, mens andre (som Niagara) fokuserer på flertrådytelse. Sånn som arkitekturene er bygget opp så må van velge om man vil satse på glimrende ytelse innen det ene eller det andre. Man får ikke i både pose og sekk. Prøver man på det så får man en løsning som er halvgod på begge deler.

[balleklorin]

Jeg tenkte på en mangel i forhold til desktop markedet, selv om det kanskje ikke kom klart nok frem. At niagara ikke hadde hatt en ytelsesgivinst med optimering av ILP i tillegg hvis du kjører flere tråder samtidig som i SMT, er for meg uforståelig men det er nå så.

 

"With insufficient TLP, processors in an MP will be idle; with insufficient ILP, multiple-issue hardware on a superscalar is wasted."

 

http://www.cs.washington.edu/research/smt/...lpabstract.html

[snorreh]

Man får ikke i både pose og sekk. Prøver man på det så får man en løsning som er halvgod på begge deler.

Itanium? :!:

[balleklorin]

PS. Det går fint å programmere singletread på multicore prosessorer på en del andre OS enn Windows i alle fall, og da vil fortsatt ILP ha mye å si for å få den enkelte kjernen til å yte maks.

 

VLIW som Itanium har er en spennende teknologi, som er veldig kompiler avhengig for å få full utnyttelse. Instruksjonsrekkefølgen er jo helt spesifisert av kompilatoren og det er ikke bortkasta transistorer på out of order superscalar design som de fleste andre cpu'er har i dag, dvs ILP blir like bra som kompilatoren.

[Richie]

Windows 2000 ble lansert 17 Februar 2000 (noen arrester meg om jeg bommer

Hmm... Kunne sverge på at det var i 1999. Husker en kompis av meg kom løpendes inn på hybelen min før juletider i 99 og forkynte høylydt at "Nå kjører jeg Win2k! Og det er ikke beta!". Og det var det ikke heller. Men det kan godt være at den offisielle lanseringen var i 2000 da.

Jeg hadde en lignende opplevelse. Men det var like etter semesterstart i 2000. Jeg husker at vi plagdes fordi PC'n hans bare hadde 64MB ram, og gikk skuffet tilbake til Windows Me fordi Win2000 var for krevende på mengde ram.

 

Windows Me ble forøvrlig lansert mye tidligere enn 2000. Så vidt jeg husker var det rundt sommeren 1999.

Ja, Win 2k ble lansert 17. februar 2000 (på bursdagen min faktisk )

Se på denne linken fra DinSide Data

 

Edit: Og forresten Win Me ble lansert 14. september 2000, altså etter Win 2k! Link

Edit2: Hehe det er faktisk 4-års jubileum for Me i dag da

Endret 14. september 2004 av Richie

[Simen1]

Richie: Jeg tok visst storslått feil angående Windows ME.. Skjønner ikke hvorfor jeg har inpretnet at Windows Me kom lenge før 2000. Jaja alle kan ta feil.

 

Jeg tenkte på en mangel i forhold til desktop markedet, selv om det kanskje ikke kom klart nok frem. At niagara ikke hadde hatt en ytelsesgivinst med optimering av ILP i tillegg hvis du kjører flere tråder samtidig som i SMT, er for meg uforståelig men det er nå så.

Nå er ikke niagara rettet inn mot desktop markedet i det hele tatt.

Faktisk er dette noe av det dårligste kjøpet du kan gjøre til desktop:

* Sikkert veldig høy pris

* Sikkert veldig lav singelthread-ytelse

* Ikke kompatibel med over 99% av desktopOS og desktopprogramvare

 

Niagara er helt klart rettet inn mot webservermarkedet. Det er der det har sin styrke i ytelse, pris/ytelse, fysisk størrelse/ytelse, kompatiblitet med typiske server-OS og server-programvare.

 

Niagara for desktop må være like skivebom som semitrailer for sportsbilbruk.

[Knick Knack]

Simen1: det er ingen ting i veien for å optimalisere for både ILP og TLP. Niagara kan optimaliseres for ILP, men det vil gjøre kjernene større og effektforbruket vil øke en god del. Med fremtidige CMOS prosesser som har mer effektive transistorer så vil nok etterkommere av Niagara få større grad av ILP optimalisering. Det er imidlertid slik at med dagens CMOS prosesser så er dette ikke lønnsomt, men dette betyr ikke at det om et par år ikke vil være lønnsomt. Faktisk tyder alt på at fremtidige multicore prosesorer vil være optimalisert for ILP, men utviklingen må naturlig nok ligge noe etter singel core produkter av effektmessige hensyn.

 

Når det gjelder Itanium så er situasjonen på sett og vis motsatt av hva situasjonen er for Niagara. Her er optimalisering av ILP de som er mest naturlig å starte med grunnet at ILP er et av hovedpoengene med EPIC. Det er imidlertid ingen ting i veien for å optimalisere for TLP ettersom dette kommer innenfor det effektbudsjettet en arbeider med. Om Montecito er et godt eksempel på at TLP er kommet til IPF er litt som en ser det. Montecito kjører ikke mer enn to tråder (en per core) sammtidig, men kan bytte til en annen tråd når det oppstår en minne referanse som bommer på L3 cache. Siden Montecito også er optimalisert for bruk i monster maskiner av typen SGI Altix 3000 med 512 prosessorer og dermed 128 minne kontrollere som kan være optil flere meter unna, så kan en slik referanse ta mange tusen klokkesykluser. Da er det greit å kunne bytte til en annen tråd mens en venter på data.

 

Kommentar til at ILP brønnen er tom: Dette er 100% BS. Den bredeste prosessoren som er i komersialt bruk i dag er Itanium 2 og den kan kjøre 6 instruksjoner per klokke syklus. En grundig analyse av alle programmene som ble valgt ut til å inkluderes i SPEC95 test suiten viste at den teoretiske maksimale IPC en kunne oppnå med en ideell CPU (uendelig mange registre og perfekt ILP deteksjon) ga en worst case på IPC=11 (i snitt) for det merst sekvensielle integer programet. De fleste lå rundt 20-30 mens worst case for FP var rundt 20 om jeg ikke husker feil og snittet var mer i størrelsesorden 50-60 og det mest parallelle FP programmet kunne kjøres med en gjenomsnittlig IPC på 150. Om en antok mer reelle prosessorarkitekturer (128 reg og redusert regnekraft for å finne avhengiheter) så kunne en oppnå 90% IPC i Integer programmene og ca 80%-60% IPC i FP programmene (lavere utnyttelse i FP pga register mangel når IPC blir stor). Nå er jo SPEC95 ganske gamle programmer så en kan jo spørre seg om moderne programmer er blitt mer sekvensielle eller mer parallelle. Jeg føler meg rimelig sikker på at de er blitt mer parallelle siden det er bevist at større datasett medfører mer parallellitet. (nokså intuitivt!)

 

Konklusjonen er veldig opplagt. IPF vil dra i fra alle de andre ettersom effektbudsjettet vil tillate det fordi en kan utnytte mer ILP enn superscalare prosessorer til en langt lavere kostnad (kostnad i form av effektforbruk og pipeline steg og/eller klokkefrekvens) mens TLP kan implementeres i like stor grad som alle andre arkitekturer hvor ILP også blir utnyttet til en viss grad. IPF får rett og slett masse ILP "gratis" ved runtime fordi den regneintensive jobben det er å finne avhengiheter mellom instruksjonene gjøres ved kompileringstid. Det det hele vil konvergere mot etter som tiden går er at IPF vil ha egenskaper som er rimelig identisk med alle andre med unntak av ILP hvor den vil utnytte minst dobbelt så mye. Dette resultatet er delvis grunnen til at Intel påstår at de skal kunne levere dobbel ytelse på IPF i forhold til x86 innen 2007 til samme kostnad. Det er ikke en vill påstand det er et rimelig grei logisk tankerekke med usikkerheter innenfor hva en kan håndtere.

 

Montecito er jo et godt eksempel på hvilken retning IPF beveger seg. De reduserer effektforbruket med ~20%, dobler antall kjerner, legger til switch-on-event-MT, øker on-chip cache med ~150% per kjerne (~75% per tråd) og øker frekvensen med ~15%. Det som virkelig mangler i IPF rekken for 2005 lansering er en singel core med ca 6MB L3 cache og ~2.5GHz frekvens. Det hadde vårt en drøm for 2-way workstations.

Endret 15. september 2004 av Knick Knack

[snorreh]

Knick Knack: Det at Itanium skal erstatte x86 ser jeg som mer tvilsomt nå enn noensinne, spesielt siden Itanium virker å være dømt til å bli et nisjeprodukt kun for spesielt interesserte.

 

AMD Opteron outsold Intel Itanium by 10X

 

Sier det meste egentlig...

Endret 15. september 2004 av snorreh

[Smirnoff]

Edit: Og forresten Win Me ble lansert 14. september 2000, altså etter Win 2k! Link

Edit2: Hehe det er faktisk 4-års jubileum for Me i dag da

Jubileum ja...

 

Det møkka-OS'et får ingen gratulasjoner fra min side! :!:

[Knick Knack]

Knick Knack: Det at Itanium skal erstatte x86 ser jeg som mer tvilsomt nå enn noensinne, spesielt siden Itanium virker å være dømt til å bli et nisjeprodukt kun for spesielt interesserte.

 

AMD Opteron outsold Intel Itanium by 10X

 

Sier det meste egentlig...

Jeg sa ikke at Itanium skulle erstatte noe som helst. Men det hadde vært fint fra et teknisk ståsted! Tror heller de kommer til å konkurrere med hverandre. porting til flere platformer blir mer og mer vanlig så det er ikke lengre nødvendig å ha samme ISA for å kunne konkurrere.

 

IPF har selvsagt en stor ulempe for tiden, nemlig at programmvare er litt vanskelig å finne. Tror det er bare ca 2000 programmer for IPF for tiden. OS er det masse av, men en mangler jo fortsat Solaris.

 

x86 vil imidlertid ikke ha en realistisk mulighet til å henge med IPF på ytelse. Det vil i beste fall bli veldig dyrt å produsere de x86 maskinene.

[snorreh]

x86 vil imidlertid ikke ha en realistisk mulighet til å henge med IPF på ytelse. Det vil i beste fall bli veldig dyrt å produsere de x86 maskinene.

Ingenting tyder på at dette kommer til å stemme nå eller i de neste par årene, per i dag er x86-maskinvare både vesentlig rimeligere og yter bedre på den programvaren industrien bruker

[Knick Knack]

x86 vil imidlertid ikke ha en realistisk mulighet til å henge med IPF på ytelse. Det vil i beste fall bli veldig dyrt å produsere de x86 maskinene.

Ingenting tyder på at dette kommer til å stemme nå eller i de neste par årene, per i dag er x86-maskinvare både vesentlig rimeligere og yter bedre på den programvaren industrien bruker

Var det meningen at jeg nå skulle si johoho?