Quad-kjerne, AMD eller Intel?

[invariant]

5285317[/snapback]

5286362[/snapback]

5286981[/snapback]

Nå er det jo i utgangspunktet slik at det ikke er spesielt effektivt å bruke java til spill eller andre prosesser med høye krav til responstid, IO osv pga. at det rett og slett er for tregt. Men, for å svare på spørsmålet ditt, det finnes allerede metoder i java som er behjelpelige med samtidige operasjoner. Har ingen erfaring med disse, men tviler på at de kan være nyttige for multikjerneprosessorer. Skulle tro at de hadde mer for seg inenfor enkle distribuerte systemer.

 

Edit: Java har selvfølgelig godt implementert metoder for samtidighet mtp multithreadede prosesser mot én enkelt kjerne. Kan ikke si at jeg kjenner godt til Fortran, men skulle tro at de fleste moderne språk har dette godt innarbeidet.

5287292[/snapback]

 

Tusen takk for nyttig svar Ola. Tenkt meg nok det ja. Kan opplyse om at Fortran egner seg utmerket til tallknusing, og med litt tankearbeid kan vi sikkert bruke openmp på en lur måte for å bruke mange kjerner. Men lett er det ikke.

 

Invariant.

[Toddy]

Spørs jo på hva en skal tallknuse, ikke alle problemer kan løses med Divide and Conquer.

[Anders Jensen]

Spørs jo på hva en skal tallknuse, ikke alle problemer kan løses med Divide and Conquer.

5287538[/snapback]

Det er vel litt av poenget i slike diskusjoner. Hver gang noen påstår at parallellisering er utelukkende enkelt/vanskelig så er det eneste de egentlig forteller at de ikke har lest seg opp på algoritmer og datastrukturer. Også er det jo forskjell på parallelisering og skalering... Å kjøre på n tråder gir ikke n ganger ytelsen selv på en multiprosessormaskin med >n kjerner. Serlig for store verdier av n.

[snorreh]

Duellen mellom AMD og Intel ser desverre ikke ut til å bli avholdt, men de to prosessorgigantene vil fortsette å kjempe om prosessorkundene.

Er det noen som seriøst hadde forhåpninger om og tro på at duellen skulle bli gjennomført?

5284423[/snapback]

Ja, jeg hadde faktisk håpet at det skulle bli noe av. Jeg har iallefall sett det for meg:

 

"In the left corner, Iiiiinnnteeeeeelll - the 800-pound gorilla from Satan Clara, USA versus Aaaammmmddd - the chimpzilla from Sunnyvale, USA, in the right corner. Get ready to RUUUMBLE!!"

 

 

En smule utdatert kanskje...men pen illustrasjon fortsatt

 

Den enkleste måten å lage en quad-CPU er trolig å sette to dobbelkjernebrikker på én sokkel. Strategisk er dette en fordel ettersom man vinner tid, men teknisk er ikke dette den beste måten siden man ikke får "ekte" quad-kjerne-CPU

Skal la det med ”ekte” eller ikke ligge, men vet vi med sikkerhet hva som er den beste løsningen? Vet vi om produsentene vil fortsette å bruke de løsningene de har i dag? Og hva menes med best? Best med tanke på skalering? Med tanke på kommunikasjon mellom kjernene? I forhold til båndbredde mot andre enheter på hovedkortet?

5284217[/snapback]

Eller hva som er best med tanke på yield og binning?

5284423[/snapback]

I Intel sin verden så er det nok sistnevnte som teller, ettersom de baserer seg på volumsalg og markedsføring først og fremst. Skalering og rå ytelse, som jeg antar artikkelforfatteren mener, kommer tydeligvis i annen rekke hos Intel enn så lenge.

 

AMD rapporteres å bytte til en fullstendig ny, skalerbar prosessorarkitektur i 2008/2009, men detaljene er ikke kjent.

Er det noen som har noe mer informasjon om dette? Hva menes med "fullstendig ny"? Er dette noe annet enn en ny modifikasjon av den aldrende K7-kjernen?

5284423[/snapback]

Touché!

 

Få detaljer har så langt lekket ut, men ettersom det tar minst 4 år å utvikle et helt nytt kjernedesign så kan man regne med at dette faktisk vil være det. K7 kom i 1999, K8 kom i 2003, så det er på tide med noe nytt nå

Endret 13. desember 2005 av snorreh

[Simen1]

Den enkleste måten å lage en quad-CPU er trolig å sette to dobbelkjernebrikker på én sokkel. Strategisk er dette en fordel ettersom man vinner tid, men teknisk er ikke dette den beste måten siden man ikke får "ekte" quad-kjerne-CPU

Skal la det med ”ekte” eller ikke ligge, men vet vi med sikkerhet hva som er den beste løsningen? Vet vi om produsentene vil fortsette å bruke de løsningene de har i dag? Og hva menes med best? Best med tanke på skalering? Med tanke på kommunikasjon mellom kjernene? I forhold til båndbredde mot andre enheter på hovedkortet?

5284217[/snapback]

Eller hva som er best med tanke på yield og binning?

5284423[/snapback]

I Intel sin verden så er det nok sistnevnte som teller, ettersom de baserer seg på volumsalg og markedsføring først og fremst. Skalering og rå ytelse, som jeg antar artikkelforfatteren mener, kommer tydeligvis i annen rekke hos Intel enn så lenge.

5288185[/snapback]

Nå virker det som du mener at det å satse på yield og binning er utelukkende negativt, så jeg vil prøve å nyansere det litt:

 

Fordeler ved å produsere en brikke i en CPU med alle kjernene samlet: (eks: AMD Athlon64 X2)

- Kommunikasjonen internt mellom brikkene vil bli svært bra -> bra ytelse i tråder der synkronisering av tråder er essensiellt.

Ulempe: Høy pris p.g.a. høy feilprosent og lav generell ytelse i entrådete applikasjoner p.g.a. lav klokkefrekvens.

 

Fordeler ved å "lime sammen" brikker: (eks: Intel P4 "Presler")

- Feilprosenten går ned -> lavere priser

- Klokkefrekvensen kan økes fordi man kan lime sammen de kjernene som klokker best -> bedre tilgjengelighet og priser på de raskeste kjernene -> bra ytelse i generelle entrådete applikasjoner.

Ulempe: Dårlig ytelse i applikasjoner der synkronisering av tråder er essensiellt.

 

AMD og intel har tydeligvis valgt hver sin vei i første omgang. Begge deler har sine svakheter og styrker. For å ikke forsterke ulempene så tror jeg at de kan velge å bytte strategi ved neste dobling av kjerner. Altså at begge vil ende opp med quad-CPU'er der to og to tett sammensydde kjerner er "limt sammen".

 

Jeg gleder meg forresten å høre detaljer fra AMD's neste arkitektur.

[Del]

Beklager sent innlegg, mener ikke å pretendere som skipper Worse, desemberen ble bare litt vel travel... Sitter med en følelse av at vi alle vet for lite om koding for spill, men noen generelle betraktninger må gå an.

 

Når det gjelder parallellisering generellt er den første gevinstøkningen gjerne rimelig billig, f.eks. få 20-40% økning ved overgang fra en til to kjerner, her forundrer det meg hvis ikke spill som demonstrerer dette ankommer markedet snart. Å utnytte hundre kjerner effektivt er en helt annen butikk. Mener jeg dumpet over en test som viste at driveren til Nvidia begynner å dra litt nytte av DC, men den store potensielle gevinsten tror jeg vi må la spillutviklerne stå for. Generellt er inntrykket mitt at man med relativt enkle grep kan utnytte opp til åtte kjerner ( i betydningen at koden går fortere på åtte enn seks kjerner), men så begynner det å bli værre.

 

Som allerede nevnt er mange operasjoner nærmest trivielle å parallellisere, f.eks. har mange spill musikk, som i liten grad trenger å synkroniseres, allerede på de trivielle bitene burde man kunne hente inn noen prosent. Likevel, bud en når man skal parallellisere er å finne flaskehalsene til CPU'en, det er ikke sikkert at de trivielt parallelliserbare delene gir stor effekt. Hvis noen kan bidra med detaljert informasjon på kodesiden til noen aktuelle spill hadde det vært veldig interessant.

 

Når det gjelder OpenMP, burde det være meget enkelt å utnytte for DC og QC, det er tross alt en homogen SMP løsning, selv om jeg ser for meg at MPI er det mest naturlige valget. At all kode må skrives om igjen er tull, men ofte må man restrukturere koden for å legge til rette for parallellisering. Ofte står 10% av koden for 90% av CPU tiden, det er på denne ti-prosenten man bør legge inn kreftene. Kan godt hende vi får nye API'er eller programmeringsspråk etterhvert som vil være mye bedre tilrettelagt for parallellisering, denne utviklingen kan man allerede se på Fortran, hvor F90/95 er mer tilrettelagt for parallellisering enn F77.

 

Vanskelighetsgraden ved parallellisering avhenger ekstremt av problemet man ønsker å parallellisere, jeg kan godt se for meg at FPS-spill er utfordrende p.g.a. tidssynkronisering, et brøkdelssekund oppleves som lagging, så margingene er små. Likevel, det er ikke opplagt for meg at det skal være så fordømt vanskelig å utnytte fire kjerner effektivt her. Er det noen som kan belyse hva som sluker CPU i f.eks. UT?