"Nehalem" - først for spillere

[int20h]

Den første utgaven av Intels kommende "Nehalem"-prosessor rettes mot spillere og lanseres mot slutten av 2008.

Les mer

[VolcomStone]

Unskyld at eg ikkje har så mykje peiling, men Core 3 ? Altså tre kjerner ? Var det ikkje intel som var så skeptisk til AMDs trekjerne ?

 

Erlend

[Darth Kjell]

Nei, 3-tallet har ikke noe med antall kjerner å gjøre. Du har f.eks Core 2 med både 2 og 4 kjerner i dag. Core 3 betyr bare at det er "oppfølgeren" til Core 2. Altså litt annen produksjonsteknikk osv. Akkurat som forskjellen mellom Pentium 1,2,3 og 4.

[Espen Skoglund]

Unskyld at eg ikkje har så mykje peiling, men Core 3 ? Altså tre kjerner ? Var det ikkje intel som var så skeptisk til AMDs trekjerne ?

 

Med Core 3 menes det neste generasjon prosessorarkitektur (etterfølgeren av Core og Core 2). "Dual", "Quad", osv. brukes for å betegne antall kjerner (f.eks. Quad Core 2).

[Nator]

Bra spent å se hvordan de skal klare å få mer faktisk ytelse ut av en CPU med 8 cores eller mer!

[OnetroM]

Bra spent å se hvordan de skal klare å få mer faktisk ytelse ut av en CPU med 8 cores eller mer!

Økning av antall kjerner setter større krav til softwareindustrien. Det er de som skal klare å lage applikasjoner som klarer å nyttekjøre seg av parallellprosessering, noe som ikke er like lett eller fornuftig for alle programmer.

[Anders Jensen]

Egentlig er vel ikke mikroarkitekturen i Nehalem så veldig ny i forhold til Core 2. Det er først og fremst SMT som er nytt på den kanten og det tror jeg ikke vil ha veldig stor betydning for desktop maskiner. Det som virkelig er nytt med Nehalem i forhold til dagens Core 2 er jo maskinarkitekturen, som vil by på noe høyere båndbredde og vesentlig lavere forsinkelse i de fleste ledd. Eneste unntaket er GPU - RAM kommunikasjonen som kan få litt høyere forsinkelse.

[Halvt horn ost skinka piffi varmt]

Er jo fryktelig liten støtte for firekjerneprosessore idag, så jeg håper at de skjerper seg til da (de som utvikler spill og programmer altså). Lite vits med 8 kjerner hvis kun to av dem utnyttes.

Endret 29. oktober 2007 av heanwi

[Anders Jensen]

Er jo fryktelig liten støtte for firekjerneprosessore idag, så jeg håper at de skjerper seg til da (de som utvikler spill og programmer altså). Lite vits med 8 kjerner hvis kun to av dem utnyttes.

Sant nok, men utviklingsverktøyene blir stadig bedre og fokuset på flertråding er veldig høyt. Det er også andre paradigmer som det spilles høyt på for tiden. Spesielt stream prosessorer (finner de i GPU) som er en slags hybrid av SIMD og vanlig CPU (SISD), men bruksområdet for disse er sterkt begrenset til dataparallelle oppgaver med dagens implementering.

 

Et av de store problemene vi står ovenfor i dag er jo at CPU kjernene ikke skalerer lengre så en må begynne å lage flere av de, og det er jo som du sier ikke mye vits i de ekstra kjernene hvis de ikke blir brukt av programmene. Om ikke lenge vil nok fokuset bli skiftet tilbake til å forbedre CPU kjernene mer dramatisk, men enn så lenge er det multicore som er hypen så vi får bare leve med det inntil videre. Det skal imidlertid bli interessant å se resultatene av at pendelen svinger tilbake. Jeg vil tro viljen til å gå mer drastisk til verks er noe større når det skjer. F.eks er jo de fleste moderne prosessorer basert på et 30 år gammelt ISA som ikke ble designet med moderne superskalare kjerner i tankene. Faktisk ble det utviklet etter "Shit, IBM dumper oss om vi ikke har noe innen 6 måneder" prinsippet.

Endret 29. oktober 2007 av Anders Jensen

[Stigma]

Mange misforstår multithreading. Det er ikke sånn at et spill må lages for å støtte akkurat 4 kjerner. Enten er koden multithreaded eller ikke. Hvis den er så kan den kan som regel flere kjerner taes i bruk. Det er selvfølgelig noe forskjell i det at du selvfølgleig må ha mist like mange mulige tråder som CPUer dersom du skal kunne fordele lasten, men fra en programmørs synspunkt er det ikke noe stor forskjell å paralellisere et program for bruk med 8 eller 16 kjerner over 4.

 

med andre ord så trengs det mest bare å komme seg over "kneiken". Det har vi ikke helt enda fordi flesteparten av vanlige mennesker fremdeles henger tilbake med gammel enkelt-kjerne tenologi. Det er først når den gemene hop tar oss igjen at vi kan forvente å se multihreading støtte i "alt" og da vil det ikke være noen kjempeforskjell å kode støtte for 16 kjerner over 4.

 

-Stigma

[Darth Kjell]

At Celeron nå også blir dual core bør hjelpe kraftig på utbredelsen. Om et par tre år vil vi sikkert se at et flertall av applikasjonene er optimalisert for multithreading.

[OnetroM]

Jeg er novice på CPU-teknologi, men vil vi kunne se et nytt sprang i ytelse hvis vi går vekk fra den noe aldrende X86-arkitekturen og tenker nytt? Og er det da lengre mulighet for bakoverkompatibilitet på HW og SW?

[Anders Jensen]

Mange misforstår multithreading. Det er ikke sånn at et spill må lages for å støtte akkurat 4 kjerner. Enten er koden multithreaded eller ikke. Hvis den er så kan den kan som regel flere kjerner taes i bruk. Det er selvfølgelig noe forskjell i det at du selvfølgleig må ha mist like mange mulige tråder som CPUer dersom du skal kunne fordele lasten, men fra en programmørs synspunkt er det ikke noe stor forskjell å paralellisere et program for bruk med 8 eller 16 kjerner over 4.

Så enkelt er det ikke. Skalering til 8 eller 16 tråder er ikke trivielt og spesielt ikke i sanntidsystemer som moderne spill. For det første er det ikke trivielt å parallellisere generelt til n tråder. Ofte er det slik at et program kan deles opp i x antall relativt separate deler som en kan parallellisere, noen av disse delene kan kanskje parallelliseres videre til n tråder, men noen ganger kan de ikke det og da ender du opp med et program som har minimum x tråder og maksimum x*y tråder der y er antallet tråder du i snitt kunne få ut av hver del. Som oftest vil y være 1 hvis den ikke er n.

 

Det er heller ikke tilstrekkelig å ha like mange tråder som du har kjerner hvis disse trådene ikke gjør veldig mye. F.eks om et spill kjører lyd i en tråd så vil ikke denne ha stor sannsynlighet for å utnytte en hel cpu kjerne. F.eks har en standard desktop maskin gjerne 200 tråder gående uten at prosessorene behøver å være så aktive at de kommer ut av lav-energi modus en gang.

 

På toppen av det hele kommer Amdahls lov og legger en demper på hele feiringa selv om du skulle være så heldig å ha et program som skalerer til n tråder.

 

med andre ord så trengs det mest bare å komme seg over "kneiken". Det har vi ikke helt enda fordi flesteparten av vanlige mennesker fremdeles henger tilbake med gammel enkelt-kjerne tenologi. Det er først når den gemene hop tar oss igjen at vi kan forvente å se multihreading støtte i "alt" og da vil det ikke være noen kjempeforskjell å kode støtte for 16 kjerner over 4.

Har vel en følelse av at det henger mer på programmererne enn på kundene. En single core maskin kan fint dra nytte av flertrådede programmer, spesielt for å få I/O frikoblet fra andre funksjoner som f.eks GUI. Akkurat det er da også vanlig i dag og et typisk eksempel på at en deler opp antall tråder etter naturlige deloppgaver.

 

Hovedårsaken til at vi ikke har massivt flertrådede programmer er at de er ekstremt mye vanskeligere å debugge enn sine motparter med færre tråder. Race conditions, ikke-deterministisk oppførsel. Trenger jeg si mer?

[Theo343]

På spillfronten har man vel allerede opparbeidet seg solid erfaring med å programmere mot flere kjerner? Jeg tenker på PS3 og Xbox360.

 

Eller tar jeg feil?

[Anders Jensen]

På spillfronten har man vel allerede opparbeidet seg solid erfaring med å programmere mot flere kjerner? Jeg tenker på PS3 og Xbox360.

 

Eller tar jeg feil?

Xbox 360 har bare 3 kjerner og PS3 har et programmerings konsept som ikke er overførbart til dagens PC, men ja det er nødvendig å lage flertrådede applikasjoner for dagens spillkonsoller. Om det impliserer at det finnes mye erfaring på området er vel delvis riktig, men det gjør jo ikke jobben noe mindre komplisert i seg selv.

 

Mozze: Det jobbes ganske mye med å utvikle hardware som ikke er x86 kompatibel og som sikter seg inn mot veldig høy ytelse. F.eks har du Tukwila, Poulson samt en rekke prosjekter for dataparallell prosessering fra Intel. AMD har Fusion prosjektet som også er rettet mot dataparallell prosessering og Nvidia har sitt CUDA API som benytter G80, G92 osv. SUN har Niagara som er både data parallell og task parallell som er en mer generelt anvendelig form for parallellisme, men ikke fullt så kraftig som rent dataparallelle implementasjoner.

 

Noen av disse er lagd for å jobbe sammen med x86 prosessorer mens andre er lagd for å erstatte de. Felles er at de benytter mer effektive instruksjonssett for å unngå overhead og muliggjøre eksponering av parallellitet.