AMD med fire kjerner i 2007

[Coffie=JavaCode]

En ting er å lage en multithreaded kontorappliasjon der du har oppgaver som er av typen "fire and forget", f.eks resize et bilde, kjøre et filter i photoshop etc. Verre er det når du har en realtime applikasjon som et spill. Dette krever en vanvittig synkronisering, og threads lever i prinsippet uavhengig av hverandre. Det er vel ikke mange spill på mac som er flertrådet på kjernelogikken i spillet heller tenker jeg.

5168590[/snapback]

 

Vel det er jo ikke så mange spill til mac heller da. Hvis min hukommelse er rett så er vel quake3 samt WOW multithreadet, og jeg ser ikke vek fra at det finnes noen andre spill der ute og. Men spill bryr jeg meg egentlig fint lite om. Det eneste er jo at eks AI kan kjøre på en tråd, fysikken på en tråd, resten av spillet på den tredje og alle maskinens andre prossesor på en fjerde tråd. IA må vel være noe av det enkeleste å lage i en egen tråd. Men du har nok helt rett, selv om jeg alvorlig ikke håper at spill er alt som driver HW fremmover for tiden. Tror nok at "kontorapplikasjoner" som krever litt mer guffe eks min far sin RNA koding da han så tester fra noen som hadde fått quadcoren så en 35-40% ytelses boost i de aller fleste tilfeller. Samme gjelder noen som skal lage tegnefilmer, eller filmeffekter. Det var da helts det jeg tengte på. Men de som spiller har vel heller fint lite å tjene på dualcore heller.

[Simen1]

Synes den synsingen om sokkel var mest spennende jeg. Har lite lyst å gå i sokkel felle igjen (ala socket 754). 

5168053[/snapback]

Sokkel 754 er jo glimrende fortsatt. Putt inn en Turion64 så er du langt på vei. Turion64 dobbeltkjerne dukker sikkert også opp snart. Den ene minnekanalen den har til forskjell fra sokkel 939 er en ytelsemessig bagatell.

 

Det kan jo være så lett at det ikke finnes noe særlig med multithredet software grunnet at det ikke akkurat har vært så mange med dualcore/ dual CPU oppsett gjennom tidene heller. Etterspørsel og tilbud.

5168486[/snapback]

Det er ikke fullt så simpelt. Det er tenkisk vanskelig å få enkeltprogrammer til å utnytte to eller flere CPU'er optimalt. Noen type programvare er lettere å parallellisere enn andre, men noe er rett og slett umulig å parallellisere effektivt.

[umy]

rett meg hvis jeg tar feil, men vil ikke dette hjelpe kraftig på multitasking? slippe at spillet plutselig henger/lagger fordi norton finner ut at nå skal jeg jaggu meg ta en dyp virusscan på hele pcn.. eller at du fint kan kjøre phshop,en mediaspiller, en browser, osv.. generelt en haug programmer samtidig uten at det går ulidelig tregt.

eller må du ty til dual-cpu for det skal hjelpe... (ikke dobbel-kjerne, men to prosessorer)

[balleklorin]

rett meg hvis jeg tar feil, men vil ikke dette hjelpe kraftig på multitasking? slippe at spillet plutselig henger/lagger fordi norton finner ut at nå skal jeg jaggu meg ta en dyp virusscan på hele pcn.. eller at du fint kan kjøre phshop,en mediaspiller, en browser, osv.. generelt en haug programmer samtidig uten at det går ulidelig tregt.

eller må du ty til dual-cpu for det skal hjelpe... (ikke dobbel-kjerne, men to prosessorer)

5169140[/snapback]

 

Det vil jo hjelpe hvis du er av typen som kjører flere programmer samtidig selvsagt, om det er dual prosessor eller dual kjerne spiller ingen rolle, nytten er den samme, og for operativsystemet er de to løsningene logisk lik.

 

Men å scanne harddisken med virusprogram vil nok gjøre at spillet hakker fordi spillet og virusprogrammet kranger om de samme harddiskressursene, da hjelper det ikke å så mye å ha to cpu'er når det er harddisken og ikke cpu-kraft som er flaskehalsen.

[scarface15]

Pleier å si at all utvikling er positiv, jeg. Slår meg som om prossessorprodusentene tilrettelegger for at forbruker skal bruke mer og mer kraftige programmer, ikke spill som godt over 50% av alle som eier en pc (kraftig pc vil det si) bruker den til.

Men nå er det Otto Jespersen, så snakkes senere =)

 

Simen1, nydelige innlegg, men sjeldent skriver sj ikke skj. bare la merke til at dette var en feil som gikk om igjen

[Simen1]

Simen1, nydelige innlegg, men sjeldent skriver sj ikke skj. bare la merke til at dette var en feil som gikk om igjen

5169593[/snapback]

Takk for skryt

 

Det er lenge siden jeg har drevet med rettskrivning og har en del dumme feil som jeg prøver å rette opp. Blandt annet sjelden (puh), dessverre (puh) og en del andre ord. Jeg skal prøve å huske sj til neste gang. Hvis jeg glemmer det så er det bare å minen meg på det igjen

[ATWindsor]

rett meg hvis jeg tar feil, men vil ikke dette hjelpe kraftig på multitasking? slippe at spillet plutselig henger/lagger fordi norton finner ut at nå skal jeg jaggu meg ta en dyp virusscan på hele pcn.. eller at du fint kan kjøre phshop,en mediaspiller, en browser, osv.. generelt en haug programmer samtidig uten at det går ulidelig tregt.

eller må du ty til dual-cpu for det skal hjelpe... (ikke dobbel-kjerne, men to prosessorer)

5169140[/snapback]

 

Det vil jo hjelpe hvis du er av typen som kjører flere programmer samtidig selvsagt, om det er dual prosessor eller dual kjerne spiller ingen rolle, nytten er den samme, og for operativsystemet er de to løsningene logisk lik.

 

Men å scanne harddisken med virusprogram vil nok gjøre at spillet hakker fordi spillet og virusprogrammet kranger om de samme harddiskressursene, da hjelper det ikke å så mye å ha to cpu'er når det er harddisken og ikke cpu-kraft som er flaskehalsen.

5169299[/snapback]

 

Er ikek så fote spill akkseserer disk, hos meg er det ivhertfall sånn at gasnke mye av gangen lastes inn til minne. Og da går det en stund mellom hver gang HD akkseserers i noe særlig grad (kjører uten swap-fil for øyeblikket).

 

AtW

[Sceptic]

I den siste beta versjonen av POV-Ray så eksperimenterer de med rendering på flere kjerner:

Our beta page has available a beta-test version of POV-Ray for the Microsoft Windows x86 and AMD64 platforms. The most significant change from the end-user point of view between versions 3.6 and 3.7 is the addition of SMP (symmetric multiprocessing) support, which in a nutshell allows the renderer to run on as many CPU's as you have installed on your computer. This will be particularly useful for those users who intend purchasing a dual-core CPU or who already have a two (or more) processor machine. On a two-CPU system the rendering speed in some scenes almost doubles.

 

Jeg som er med i distributed-computing prosjekter, kunne godt tenke meg f.eks èn PC med 16 kjerner å kjøre klientene på enn en haug med PCer som står rundt på alle rommene i leligheten min.

Vet at det ikke er så mange som driver med DC, men har inntrykk av at det blir fokusert voldsomt på spill her i tråden (og ellers) og ender opp med en 'spill utnytter ikke multi-core så derfor trenger vi ikke det' mentalitet.

 

Det er ikke alle som spiller!

 

Sceptic

Endret 17. november 2005 av Sceptic

[iDude]

ibrotha, wotg: Utelukkende positivt er det ikke. Flere kjerner betyr lavere klokkefrekvenser og dermed mindre ytelse per tråd. Dette fordi effektbudsjettet blir delt på 2 eller 4, dermed må også kjernespenninga og klokkefrekvensen senkes for å holde seg innen fornuftig effekt. (200W CPU'er ser jeg på som svært upraktiske på mange måter.) Mye programvare er teknisk umulig å få til å bruke begge kjernene effektivt uansett hvor mye man prøver. Derfor vil doble kjerner aldri bli en fullgod erstatning for doblet klokkefrekvens. Ved økning til 4 kjerner blir det ennå vanskeligere å utnytte alle kjernene. La oss si man klarer å få de ekstra kjernene til å ta unna 10% av arbeidet og at alle kjernene må klokkes ned 10% i forhold til dobbeltkjerne. Da går vinninga opp i spinninga. Man har laget en mye dyrere kjerne som yter likt.

5167145[/snapback]

Mye programvare er teknisk vanskelig å parallellisere på en fornuftig måte, men mange tunge operasjoner i en pc er det forsket mye på hvordan man skal parallellisere. Vindusstyring og slike ting vil ikke være umiddelbart enkle å parallellisere, men så er de heller ikke spesielt tunge vanligvis. Inntil nå har parallellisering til dels vært en ukjent verden for desktop-applikasjoner, men løsningene ligger der. Om man greier å parallellisere værmodeller effektivt så ser jeg ikke helt bøygen her. Man skal gå ganske langt for å finne mer kompliserte programmer enn værvarslingsmodeller.

 

Mye av arbeidet er opp til programvare-utviklerne, de må ikke bare parallellisere kode, de må også formulere problem på en måte som lar seg parallellisere. MS har også sin del av ansvaret med å lage gode APIs (i stedet for utelukkende å klage på programvare-utviklere som ikke utnytter flere kjerner).

 

Når det gjelder 2 vs 4 kjerner; har man et problem som lar seg parallellisere, og programmereren har gjort jobben sin, så skal det være en smal sak å endre koden til å bruke flere kjerner.

 

Ang varmeutvikling, så er vel det en av hovedgrunnene til at man går over til flere kjerner? Med det tenker jeg på frekvenskappløpet som har stagnert litt.

[Opteron]

Pleier å si at all utvikling er positiv, jeg. Slår meg som om prossessorprodusentene tilrettelegger for at forbruker skal bruke mer og mer kraftige programmer, ikke spill som godt over 50% av alle som eier en pc (kraftig pc vil det si) bruker den til.

Men nå er det Otto Jespersen, så snakkes senere =)

 

Simen1, nydelige innlegg, men sjeldent skriver sj ikke skj. bare la merke til at dette var en feil som gikk om igjen

5169593[/snapback]

 

 

Hei scarface15, fint at du er så flink til å skrive Norsk.

Men sjeldent SKRIVES sk ikke skj.

 

Så til deg

Endret 18. november 2005 av Opteron

[Del]

I 2008 eller 2009 vil AMD lansere en helt ny arkitektur som er spesielt rettet mot større serverløsninger.

Denne nye arkitekturen blir spennede å sette seg inn i. Jeg regner sterkt med den er basert på x86-64. Noe annet ville vært veldig oppsiktsvekkende. Men hva blir innholdet? Den er vel tenkt å konkurrere mot Intel Whitefield (4 Conroe-lignende kjerner og veldig mye L2 cache). Da lurer jeg på hva de har å stille opp med. Kanskje en ny strategi for minneallokering og en utvidelse av bussnettverket HyperTransport? På ordlyden høres det også ut som de skal bygge en ny kjerne. Hva den vil inneholde blir jo spennende. Veikartet sier noe om "on die coprocessors", og her er det vel ganske åpent hva det blir. Mine spekulasjoner går i retning av massiv parallellitet som f.eks å integrere nos som ligner en GPU eller PhysX prosessoren.

5166658[/snapback]

Tror kanskje AMD sikter spesielt til cache coherency problematikk her. Dagens håndetering av cache i Opteron gir klare begrensinger på hvor mange CPU'er du effektivt kan utnytte i en SMP løsning, problemet er sannsynligvis betydelig ved dagens største løsninger (8 sokler, 16 kjerner), så med framtidig quad-core må de nok finne på noe nytt.

[snorreh]

Veikartet sier noe om "on die coprocessors", og her er det vel ganske åpent hva det blir. Mine spekulasjoner går i retning av massiv parallellitet som f.eks å integrere nos som ligner en GPU eller PhysX prosessoren.

5166658[/snapback]

Phil Hester fra AMD utdyper litt mer om dette her:

http://www.eetimes.com/news/latest/showArt...cleID=175803862

When we look at the server side of things, we are starting to see a pretty broad mix of application types, some of them based on Java and XML. We are looking at whether there are instruction-set extensions that could provide a 2x or 3x boost. We have to decide if that is a good use of silicon. Now we are looking at the workloads, what the characteristics are, what things you can do at the microarchitecture and instruction set [levels].

 

Generally, 80 percent of the benefit from 20 percent of the silicon is a good trade. In some cases there clearly is an advantage to an attached coprocessor. We want to make it easier for people to attach a coprocessor to the coherent HyperTransport link. The options might include Java, XML, vector floating-point units or any attached processor that needs very high bandwidth and that also needs to deal with coherency. There are some problems with it. Nowadays we have JIT [just-in-time] compilers, and once you do it in silicon you are kind of stuck. We have to hit the right balance between what you do in hardware and what you do in the compiler. I don't think it ever goes as far as an XML engine in hardware.

I denne sammengeng har også vært endel snakk om AMD sitt siste Acceleration Technology-prosjekt den siste tiden, og her kommer The Inquirer med noen releavnte og interessante spekulasjoner basert på dette:

 

What are the AMD accelerators?

Basically, what I think they are going to do is use ccHT as a co-processor bus instead of a CPU interconnect.

[...]

Companies like Clearspeed and Cavium can look at the basic x86 infrastructure as things they don't have to do one their own, just concentrate on making the instructions they do need fly. In this case, x86 would be infrastructure, dull, commodity infrastructure.

 

AMD on the other hand can sell reams of boxes where it never could before. Want overwhelming FP? Plug in a co-processor that does that. Render farms your thing? NVidia, can you make us a high margin version of he NV60 in a new package? The possibilities are endless.

 

Why would you want to do this on AMD? Two reasons. First, you can't on Intel, their infrastructure is woefully inadequate, and only is in the game because of brute force, so that's not an option. The other is a bit more speculative, AMD can give you the interface circuitry for free, or at least low cost, and you only build what you need to build. It saves you money, gives them bragging rights, and presents the end user with a compelling platform that only costs and arm or a leg, but not both.

Disse spekulasjonene virker å henge på greip, ettersom vi allerede i dag har PathScale sitt InfiniPath HTX-adapter som også benytter seg av HyperTransport og Newisys' kommende Horus-brikkesett med L3 cache. Spennende!

Endret 22. januar 2006 av snorreh

[Simen1]

Veikartet sier noe om "on die coprocessors", og her er det vel ganske åpent hva det blir. Mine spekulasjoner går i retning av massiv parallellitet som f.eks å integrere nos som ligner en GPU eller PhysX prosessoren.

5166658[/snapback]

Phil Hester fra AMD utdyper litt mer om dette her:

http://www.eetimes.com/news/latest/showArt...cleID=175803862

When we look at the server side of things, we are starting to see a pretty broad mix of application types, some of them based on Java and XML. We are looking at whether there are instruction-set extensions that could provide a 2x or 3x boost. We have to decide if that is a good use of silicon. Now we are looking at the workloads, what the characteristics are, what things you can do at the microarchitecture and instruction set [levels].

 

Generally, 80 percent of the benefit from 20 percent of the silicon is a good trade. In some cases there clearly is an advantage to an attached coprocessor. We want to make it easier for people to attach a coprocessor to the coherent HyperTransport link. The options might include Java, XML, vector floating-point units or any attached processor that needs very high bandwidth and that also needs to deal with coherency. There are some problems with it. Nowadays we have JIT [just-in-time] compilers, and once you do it in silicon you are kind of stuck. We have to hit the right balance between what you do in hardware and what you do in the compiler. I don't think it ever goes as far as an XML engine in hardware.

5480348[/snapback]

Interresant! Det går kanskje ikke helt veien om on-die coprosessors selv om jeg har inntrykk av at det er mye ledig minnebåndbredde på K8. Jeg har mest tro på en form for massivt parallell FP men det er kanskje nettopp krav til minnebåndbredde som presser AMD til å finne på andre løsninger enn å ha dette på kjernen. Altså at de velger å ha en egen HT-buss for tilkobling av slike enheter. Selv doble minnekanaler med DDR2-800 er å regne som dårlig minnebåndbredde sammenlignet med dagens high-end grafikkort. (12,8 vs ~60 GB/s). Men det gir AMD et nytt dillemma: Hva skal de bruke fremtidig Silisium-areal til? (Ikke noe annet enn flere kjerner og L3 cache?)

 

Det estimatet AMD gjør når de sier 2-3 ganger bedre ytelse ved integrering av en SP coprosessor har også Intel gjort. (Side 34 i den prosentasjonen du linket i går).

[Del]

Interresant! Det går kanskje ikke helt veien om on-die coprosessors selv om jeg har inntrykk av at det er mye ledig minnebåndbredde på K8. Jeg har mest tro på en form for massivt parallell FP men det er kanskje nettopp krav til minnebåndbredde som presser AMD til å finne på andre løsninger enn å ha dette på kjernen. Altså at de velger å ha en egen HT-buss for tilkobling av slike enheter. Selv doble minnekanaler med DDR2-800 er å regne som dårlig minnebåndbredde sammenlignet med dagens high-end grafikkort. (12,8 vs ~60 GB/s). Men det gir AMD et nytt dillemma: Hva skal de bruke fremtidig Silisium-areal til? (Ikke noe annet enn flere kjerner og L3 cache?)

Jupp, når du først snakker om massiv FP, er ikke minnebåndbredden til K8 tilstrekkelig i alle sammenhenger. En typisk problemstilling som er meget vanlig i FP sammenheng er håndtering av store matriser, hvor matrisene gjerne kan være på 100MB, så ingen håp om å holde alt du trenger i cache, ved multiplikasjon av slike matriser er det veldig mye data som skal fra minne til CPU. Dagens Athlon/Opteron er fullt i stand til å spise opp all ledig båndbredde på slike problem, så med massiv FP på co-prosessor er jeg usikker på om HT-buss vil være tilstrekkelig. Sammenligningen med GPU er på sin plass, bare se hvor mye penger som spyttes inn for å få kjapt grafikk minne, og høy båndbredde til GPU.