GeForce 8800 som en vanlig CPU

[kilik]

Littt OT, men hva er raskest til å regne ut PI av PiFast og QuickPi?

7984764[/snapback]

PiFast er raskere når man vil ha over 160 millioner siffer. QuickPI er raskest for 1 million siffer som har vært standard for benchmarking. Sistnevnte program kan også kalkulere e og rota av 2.

[Del]

Det er ikke snakk om noen få titalls kilobytes. Det er snakk om noen titalls megabytes, og det å flytte ting tilbake til RAM er tregt, fordi GPU-ene (eller general purpose GPU-ene) ikke er designet for å flytte store mengder data den veien.

Her har du nok misforstått. Det er motsatt, typisk får du dobbel båndbredde når du flytter teksturer tilbake fra kortet sammenlignet med til kortet. For 8800GTX er det ca. 1GB/s den ene veien og ca. 500MB/s den andre:

http://graphics.stanford.edu/projects/gpub...s/8800GTX-0003/

Med CUDA skal visstnok dette bedres til bortimot det dobbelte, uten at jeg har sett benker på det. Det er riktig at dette er en av begrensningene knyttet til gpgpu, men det er langt i fra den eneste, Verden består heldigvis av mer enn Adobe Photoshop.

 

jeg kan ikke se hel hvorfor at det skal være raskere å flytte data den ene veien, men jeg er fullt klar over at det er titalls megabyte for et bilde, kanskje et par hundre mens man jobber med det, men hvis et skjermkort har 512MB minne eller mer så burde ikke det være noe problem i det hele tatt, selv med 256MB så burde en god del gå.

7984327[/snapback]

Faktisk er mangel på minne det største problemet med tanke på hva jeg kunne tenkt meg å bruke gpgpu til, men det er nok til å dekke en rekke områder når du begynner å komme opp i en GB. Det dios siktet til var derimot oppgaver som går så fort å utføre på GPU'en at flytting av data til og fra blir en flaskehals.

 

EDIT: rettet opp 1MB/s til 1GB/s.

Endret 21. februar 2007 av Del

[dios]

Her har du nok misforstått. Det er motsatt, typisk får du dobbel båndbredde når du flytter teksturer tilbake fra kortet sammenlignet med til kortet. For 8800GTX er det ca. 1MB/s den ene veien og ca. 500MB/s den andre:

http://graphics.stanford.edu/projects/gpub...s/8800GTX-0003/

Rent bortsett fra at den testen viser at man kan få ca. 500 MB/s begge veier, så, ja, man får nå altså 500 MB/s også tilbake til CPU, på et buffer på 512x512x4xfloat. Ikke verst.

 

Men disse båndbreddene er likevel svært lave i forhold til de som finnes for lokalt minne på en PC, forskjellen er en størrelsesorden for RAM og to størrelsesordener for cache (og dette får plass i cache), og da har vi ikke engang sett på ende-til-ende-forsinkelse.

 

Med CUDA skal visstnok dette bedres til bortimot det dobbelte, uten at jeg har sett benker på det.

Da begynner det nesten å hjelpe, vi begynner da å få båndbredde som er omtrent det den originale Athlon 1200 MHz klarte til vanlig RAM.

 

Det er riktig at dette er en av begrensningene knyttet til gpgpu, men det er langt i fra den eneste, Verden består heldigvis av mer enn Adobe Photoshop.

Jeg har ikke hevdet at verden består kun av Adobe Photoshop.

[dios]

En GPU egner seg kun til sterkt parallelliserbare oppgaver. En CPU egner seg til sterkt til ikke-parallelliserbare oppgaver og lett parallelliserbare oppgaver. Generell programkode inneholder en miks av alt fra ikke-parallelliserbare oppgaver til svært parallelliserbare oppgaver. Tidligere egnet GPU seg kun til datatrafikk den ene veien (fra CPU til skjerm), men nå begynner de å egne seg til datatrafikk andre veien også.

 

GPU yter elendig når det kommer til oppgaver eller datatransport den ikke egner seg for. Derfor har GPU hatt ganske begrenset bruksområde før. Nå utvider bruksområdet seg.

Den forklaringen var rotete og upresis.

 

Hovedårsaken til at en grafikkprosessor er raskere enn en generell CPU er at grafikkprosessoren kan spesialiseres mot et bestemt oppgavesett: den trenger ikke være en verdensmester samlet sett, men klarer seg fint med å være verdensmester på et par enkeltdistanser.

 

Parallelliserbarhet har lite med saken å gjøre,det er noe som er fint mulig også for vanlige CPU-er.

 

F.eks. har vi SUN UltraSPARC T1 (Niagara) med opptil 32 samtidige tråder, fordelt på 8 prosessorkjerner, i en brikke. Intel har også demonstrert en prototype på CPU med mange prosessorkjerner, men SUNs brikke allerede finnes i servere ute hos kunder.

 

 

Historisk sett kan vi se at oppgaver som tidligere lønte seg å "outsource" til eksterne brikker, f.eks. elementær signalbehandling (DSP), "multimedia"-instruksjoner (MMX, 3DNow!, SSE, SSE II, SSE III) har blitt flyttet inn til CPU-en for å dra nytte av den økte ytelsen de kortere fysiske avstanden kan gi. Samtidig har mer avanserte oppgaver blitt mulig å utføre eksternt, fordi de samme generelle nyvinningene i prosessteknologi (og ikke nødvendigvis prosessorteknologi) kan benyttes både til generelle og spesialiserte prosessorer.

 

Det er nok bare et tidsspørsmål før oppgavene som i dag utføres av en GeForce 8800 eller tilsvarende er nesten fullstendig integrert i CPU-en, mens andre og tøffere oppgaver gjøres i de eksterne grafikk-koprosessorene.

[ATWindsor]

Jeg skjønner ikke helt det med båndbredde inn og ut av kortet, var ikke en av tingene de skrøt av med PCIe at det skulle være samme båndbredde "begge veier"?

 

Ellers er jeg spent på hvordan dette kan utnyttes innen akustikk, da mange av de samme metodene brukes for modellering av lydbølger som lysbølger.

 

AtW

[saivert]

PCIexpress-gruppen jobber med en ny versjon som skal støtte enda høyere busshastighet. Så vi får vente i spenning....

[Prelude]

O.J: Det har ingen praktisk nytte for vanlige folk ennå. Dette er et verktøy for programvareutviklere. Dvs. at det kan komme programmer som utnytter det senere.

 

ATI har hatt noe tilsvarende i lang tid. F.eks er Folding@Home mulig å kjøre på Radeon X19xx-serien.

7983814[/snapback]

 

Hvor mye folder en x1950xtx i forhold til en core2duo @ 3ghz?

 

Sankker om forholdstall da

7983864[/snapback]

 

http://folding.stanford.edu/faq.html

Before putting out any new work unit, we benchmark it on a dedicated 2.8GHz Pentium 4 machine with SSE2 disabled (more specifically, as reported by /proc/cpuinfo on linux: vendor_id : GenuineIntel, cpu family : 15, model : 2, model name : Intel® Pentium® 4 CPU 2.80GHz, stepping : 9, cpu MHz : 2806.438, cache size : 512 KB).

GPUs have the possibility to perform an enormous number of Floating Point OPerations (FLOPs). However, they achieve this high performance by losing generality -- there are only certain types of calculations which would be well-suited to GPUs. However, after much work, we have been able to write a highly optimized molecular dynamics code for GPU's, achieving a 20x to 40x speed increase over comparable CPU code for certain types of calculations in FAH.

 

Det ikke verdens raskeste cpu dem bruker til ytelsetesting, men 20 til 40 ganger raskere på ATI's x1900 kort kontra Pentium 4 maskinen er respektabelt

nå vet jeg ikke hvor mye raskere en C2D@3Ghz er i forhold til P4'en dem bruker i sine tester, men GPUen knuser C2D lett

 

nå når Nvidia kommer med verktøy for å ta i bruk gpgpu'en til tunge matematiske jobber så tror jeg mange blir glade nå. spesielt diverse kodere for DC-sammfunn '

 

 

 

Edit:

 

ser ut til at vi snart går inn i en ny æra innen data, og å bruke gpuer som utvidelse til cpuer nyttesløst siden verdens første quantum prosessor ble demostrert nå for ett par dager siden

 

klikk på meg!

Endret 20. februar 2007 av Prelude

[stoffix]

Jeg skjønner ikke helt det med båndbredde inn og ut av kortet, var ikke en av tingene de skrøt av med PCIe at det skulle være samme båndbredde "begge veier"?

 

Ellers er jeg spent på hvordan dette kan utnyttes innen akustikk, da mange av de samme metodene brukes for modellering av lydbølger som lysbølger.

 

AtW

7986880[/snapback]

 

ekn kort forklaring som jeg håper er enkel.

 

du har en bilvei (databussen) den har en fartsgrense på 110km/t (maksimal overføringshastighet).

 

men desverre, så kjører du en gammel og sliten bil, den klarer ikke å kjøre fortere enn 70km/h.

 

det er dette som er tilfellet det er snakk om her, selv om bussen støtter høyere overføringshastighet, så trenger ikke involverte komponenter utenfor bussen å støtte disse hastighetene.

[ATWindsor]

Jeg skjønner ikke helt det med båndbredde inn og ut av kortet, var ikke en av tingene de skrøt av med PCIe at det skulle være samme båndbredde "begge veier"?

 

Ellers er jeg spent på hvordan dette kan utnyttes innen akustikk, da mange av de samme metodene brukes for modellering av lydbølger som lysbølger.

 

AtW

7986880[/snapback]

 

ekn kort forklaring som jeg håper er enkel.

 

du har en bilvei (databussen) den har en fartsgrense på 110km/t (maksimal overføringshastighet).

 

men desverre, så kjører du en gammel og sliten bil, den klarer ikke å kjøre fortere enn 70km/h.

 

det er dette som er tilfellet det er snakk om her, selv om bussen støtter høyere overføringshastighet, så trenger ikke involverte komponenter utenfor bussen å støtte disse hastighetene.

7989722[/snapback]

 

Ja, det er greit nok, men jeg klarer ikke helt å forstå hvilke komponenter det i såfall er som begrenser det mer enn bussen heller...

 

AtW

[Del]

En GPU egner seg kun til sterkt parallelliserbare oppgaver. En CPU egner seg til sterkt til ikke-parallelliserbare oppgaver og lett parallelliserbare oppgaver. Generell programkode inneholder en miks av alt fra ikke-parallelliserbare oppgaver til svært parallelliserbare oppgaver. Tidligere egnet GPU seg kun til datatrafikk den ene veien (fra CPU til skjerm), men nå begynner de å egne seg til datatrafikk andre veien også.

 

GPU yter elendig når det kommer til oppgaver eller datatransport den ikke egner seg for. Derfor har GPU hatt ganske begrenset bruksområde før. Nå utvider bruksområdet seg.

Den forklaringen var rotete og upresis.

Nei det var den ikke, ihvertfall ikke like rotete og upresis som ditt forsøk.

 

Parallelliserbarhet har lite med saken å gjøre,det er noe som er fint mulig også for vanlige CPU-er.

Det har veldig mye med saken å gjøre, som jeg sa er det flere ting enn båndbredde mellom GPU og CPU som betyr noe. En GPU kjører på vesentlig lavere klokkesyklus enn en CPU, hvilket betyr at du må distribuere oppgavene mer for å få samme ytelse som på CPU. For tungt parallelliserbare problemer kan det være en show stopper for GPU.

 

F.eks. har vi SUN UltraSPARC T1 (Niagara) med opptil 32 samtidige tråder, fordelt på 8 prosessorkjerner, i en brikke. Intel har også demonstrert en prototype på CPU med mange prosessorkjerner, men SUNs brikke allerede finnes i servere ute hos kunder.

Hvilket forteller deg at det allerede er spesialiserte CPU'er på vei for problemer som lar seg parallellisere.

 

Historisk sett kan vi se at oppgaver som tidligere lønte seg å "outsource" til eksterne brikker, f.eks. elementær signalbehandling (DSP), "multimedia"-instruksjoner (MMX, 3DNow!, SSE, SSE II, SSE III) har blitt flyttet inn til CPU-en for å dra nytte av den økte ytelsen de kortere fysiske avstanden kan gi. Samtidig har mer avanserte oppgaver blitt mulig å utføre eksternt, fordi de samme generelle nyvinningene i prosessteknologi (og ikke nødvendigvis prosessorteknologi) kan benyttes både til generelle og spesialiserte prosessorer.

 

Det er nok bare et tidsspørsmål før oppgavene som i dag utføres av en GeForce 8800 eller tilsvarende er nesten fullstendig integrert i CPU-en, mens andre og tøffere oppgaver gjøres i de eksterne grafikk-koprosessorene.

7986316[/snapback]

Som du indikerer er GPU spesialisert, og det så langt at det skal mer til enn litt ekstra silisium for å integrere den på en CPU. Det er blant annet fundamentale problemer knyttet til minne-ytelse.

 

Jeg skjønner ikke helt det med båndbredde inn og ut av kortet, var ikke en av tingene de skrøt av med PCIe at det skulle være samme båndbredde "begge veier"?

Jo, men som vi ofte har sett er teoretisk maks og faktisk benket ytelse ofte to forskjellige ting. Du må nesten spørre ATI og nVidia om hvorfor, men faktum er at de ikke er i nærheten av å ta ut maks for PCIe bussen til grafikkortet.

 

Ellers er jeg spent på hvordan dette kan utnyttes innen akustikk, da mange av de samme metodene brukes for modellering av lydbølger som lysbølger.

 

AtW

7986880[/snapback]

Jeg også, akkurat det har jeg tenkt å se nærmere på.

[Simen1]

Jeg skjønner ikke helt det med båndbredde inn og ut av kortet, var ikke en av tingene de skrøt av med PCIe at det skulle være samme båndbredde "begge veier"?

Jo, men som vi ofte har sett er teoretisk maks og faktisk benket ytelse ofte to forskjellige ting. Du må nesten spørre ATI og nVidia om hvorfor, men faktum er at de ikke er i nærheten av å ta ut maks for PCIe bussen til grafikkortet.

7989970[/snapback]

I så fall skjønner jeg ikke jaget etter å ha to PCIe-x16-porter i stedet for to PCIe-x8-porter til grafikkort i SLI. Det bør vel holde med PCIe-x4 (2veis 1GB/s) til hvert grafikkort dersom det er noe annet som begrenser trafikken til under 1GB/s.

 

PS. Del, du har en liten skrivefeil lengre opp her. 1 MB/s i stedet for 1 GB/s.

[dios]

Nei det var den ikke, ihvertfall ikke like rotete og upresis som ditt forsøk.

Nehei! Joho!

 

 

F.eks. har vi SUN UltraSPARC T1 (Niagara) med opptil 32 samtidige tråder, fordelt på 8 prosessorkjerner, i en brikke. Intel har også demonstrert en prototype på CPU med mange prosessorkjerner, men SUNs brikke allerede finnes i servere ute hos kunder.

Hvilket forteller deg at det allerede er spesialiserte CPU'er på vei for problemer som lar seg parallellisere.

Jeg tror ikke du er helt inne i fagterminologien her.

 

Når man snakker om "spesialisering", så er det snakk om å lage en prosessor som er spesialisert til å gjøre et sett med oppgaver veldig bra på bekostning av andre.

 

En grafikkprosessor er typisk spesialisert til å gjøre visse typer grafikkoperasjoner veldig bra, på bekostning av vanlige oppgaver, som altså er det en vanlig prosessor (som f.eks. UltraSPARC T1!) er laget for å håndtere.

 

Det regnes ikke som en "spesialisering" å være en prosessor som løser generelle oppgaver.

 

 

Som du indikerer er GPU spesialisert, og det så langt at det skal mer til enn litt ekstra silisium for å integrere den på en CPU. Det er blant annet fundamentale problemer knyttet til minne-ytelse.

Jeg er ikke helt sikker på hvor mye du har fulgt med på utviklingen i mikroprosessorer fra barndommen til i dag, men det kan jo virke som om du tror at disse problemene er så fundamentale at de ikke lar seg løse.

 

Historisk sett har dette vist seg å være feil.

 

Før i tiden hadde man gjerne en ekstern flyttallskoprosessor, nettopp fordi dette ikke lett lot seg integrere i den generelle prosessoren. Det ble regnet som en spesialisert oppgave.

 

De operasjonene jeg nevnte som du glatt avfeide (MMX osv.) var også operasjoner som ble gjort av grafikkoprosessorer på en PC.

 

Det er i dag svært lite i veien for at f.eks. AMD kunne laget en dual-core prosessor som hadde en del x86-64-kjerne og en annen del "R700", som i kraft av sin nærhet mellom hovedprosessor og grafikkoprosessor ville kunne oppnå vesentlig bedre ytelse.

 

Konseptene jeg snakker om er ikke spesielt umulige, heller, se f.eks. IBM og Sonys Cell-arkitektur, hvor de gjør nettopp den integreringen du mener det er fundamentale problemer knyttet til.

[Del]

Nehei! Joho!

Med slike argumenter blir jeg målløs.

F.eks. har vi SUN UltraSPARC T1 (Niagara) med opptil 32 samtidige tråder, fordelt på 8 prosessorkjerner, i en brikke. Intel har også demonstrert en prototype på CPU med mange prosessorkjerner, men SUNs brikke allerede finnes i servere ute hos kunder.

Hvilket forteller deg at det allerede er spesialiserte CPU'er på vei for problemer som lar seg parallellisere.

Jeg tror ikke du er helt inne i fagterminologien her.

Så godt at du er her for å hjelpe meg da.

Når man snakker om "spesialisering", så er det snakk om å lage en prosessor som er spesialisert til å gjøre et sett med oppgaver veldig bra på bekostning av andre.

Beklager, jeg ser ikke relevansen. La meg prøve: Fordi også andre arkitekturer enn GPU er rettet mot spesialiserte oppgaver, så var forklaringen til Simen rotete og upresis? Nei, beklager, dette blir nok litt for rotete og upresist til at jeg i det hele tatt forstår hvor du vil.

En grafikkprosessor er typisk spesialisert til å gjøre visse typer grafikkoperasjoner veldig bra, på bekostning av vanlige oppgaver, som altså er det en vanlig prosessor (som f.eks. UltraSPARC T1!) er laget for å håndtere.

Ah, nå skjønner jeg. Beklager at jeg ikke forstod det tidligere. Sun sine Niagara er faktisk meget spesialisert mot helt bestemte oppgaver, og det er nært knyttet til arkitekturen. Når det gjelder Intel sin 80 kjerne, vel så får vi se hva fremtiden bringer.

 

Det regnes ikke som en "spesialisering" å være en prosessor som løser generelle oppgaver.

Hva er egentlig generelle oppgaver? Dette blir fort litt upresist vettu. Du mener antagelig typisk prosesseringsenheter som ikke kjører OS, men som brukes til støttefunksjoner? Slik som SPE'ene i Cell?

 

Som du indikerer er GPU spesialisert, og det så langt at det skal mer til enn litt ekstra silisium for å integrere den på en CPU. Det er blant annet fundamentale problemer knyttet til minne-ytelse.

Jeg er ikke helt sikker på hvor mye du har fulgt med på utviklingen i mikroprosessorer fra barndommen til i dag, men det kan jo virke som om du tror at disse problemene er så fundamentale at de ikke lar seg løse.

 

Historisk sett har dette vist seg å være feil.

 

Før i tiden hadde man gjerne en ekstern flyttallskoprosessor, nettopp fordi dette ikke lett lot seg integrere i den generelle prosessoren. Det ble regnet som en spesialisert oppgave.

 

De operasjonene jeg nevnte som du glatt avfeide (MMX osv.) var også operasjoner som ble gjort av grafikkoprosessorer på en PC.

 

Det er i dag svært lite i veien for at f.eks. AMD kunne laget en dual-core prosessor som hadde en del x86-64-kjerne og en annen del "R700", som i kraft av sin nærhet mellom hovedprosessor og grafikkoprosessor ville kunne oppnå vesentlig bedre ytelse.

 

Konseptene jeg snakker om er ikke spesielt umulige, heller, se f.eks. IBM og Sonys Cell-arkitektur, hvor de gjør nettopp den integreringen du mener det er fundamentale problemer knyttet til.

7991493[/snapback]

Å herre, her var det mye å ta tak i. Får se om jeg finner tid i kveld.

Endret 21. februar 2007 av Del

[dios]

Nehei! Joho!

Med slike argumenter blir jeg målløs.

Skrev han, og fortsatte med argumenter som var verre, uten å engang forsøke å fatte at det ovenfor var en satire over argumentasjonen som foregikk i den øvre delen av meldingen.

 

Jeg skjønner at du har mye å ta fatt i, men kan du ikke i det minste starte med en tur til skolen for sarkasme, ironi og satire?

[G]

Det er i dag svært lite i veien for at f.eks. AMD kunne laget en dual-core prosessor som hadde en del x86-64-kjerne og en annen del "R700", som i kraft av sin nærhet mellom hovedprosessor og grafikkoprosessor ville kunne oppnå vesentlig bedre ytelse.

 

Konseptene jeg snakker om er ikke spesielt umulige, heller, se f.eks. IBM og Sonys Cell-arkitektur, hvor de gjør nettopp den integreringen du mener det er fundamentale problemer knyttet til.

7991493[/snapback]

Men det må de kanskje være litt forsiktige med. Da blir AMD vel nødt til å lage en AMD CPU med integrert ATI GPU, og en annen med integrert nVidia GPU, eller noe sånn ?? Men dette har sikkert blitt diskutert i en tråd tidligere når vi først fikk høre om AMD/ATI sammenslåingen.

[Del]

Kunne vært greit om du krydret frekkhetene dine med faglig innhold, jeg venter fortsatt på en leksjon i terminologi.

Jeg er ikke helt sikker på hvor mye du har fulgt med på utviklingen i mikroprosessorer fra barndommen til i dag, men det kan jo virke som om du tror at disse problemene er så fundamentale at de ikke lar seg løse.

Jeg har vel fulgt med sånn tålelig bra tror jeg. Jeg har ikke sagt at problemene er uløselige, bare at det ikke er fullt så rett frem som du vil ha det til.

 

Før i tiden hadde man gjerne en ekstern flyttallskoprosessor, nettopp fordi dette ikke lett lot seg integrere i den generelle prosessoren. Det ble regnet som en spesialisert oppgave.

 

De operasjonene jeg nevnte som du glatt avfeide (MMX osv.) var også operasjoner som ble gjort av grafikkoprosessorer på en PC.

Tror du er litt hårsår her, jeg avfeide ikke det, derimot prøvde jeg å utvide din horisont noe. Det er trender over tid som du antagelig ikke helt har fått med deg, referanse til minne-ytelse er et klart hint.

 

Det er i dag svært lite i veien for at f.eks. AMD kunne laget en dual-core prosessor som hadde en del x86-64-kjerne og en annen del "R700", som i kraft av sin nærhet mellom hovedprosessor og grafikkoprosessor ville kunne oppnå vesentlig bedre ytelse.

Interessant forslag, kanskje du kan dele litt mer detaljer rundt denne arkitekturen. Sikter du til en high end GPU når du sier R700?

 

Konseptene jeg snakker om er ikke spesielt umulige, heller, se f.eks. IBM og Sonys Cell-arkitektur, hvor de gjør nettopp den integreringen du mener det er fundamentale problemer knyttet til.

7991493[/snapback]

Cell ja, du mener altså SPE'ene i Cell? Ser du noen problemer med Cell? Minnekonfigurasjon kanskje? Ytelse på generell kode? Eller kanskje du ser for deg at x86 endelig er død?

Endret 21. februar 2007 av Del

[dios]

Kunne vært greit om du krydret frekkhetene dine med faglig innhold,

Pot, kettle, black.

 

jeg venter fortsatt på en leksjon i terminologi.

Jeg synes ikke det er så veldig kult å skulle legge ut med noen "leksjoner", men får nøye meg med å konstatere at din faglige bakgrunn nok er fra en annen tradisjon enn min, og at terminologien derfor er forskjellig.

 

Jeg hadde trodd at dersom du kom fra en liknende faglig tradisjon, så ville mine noe vage skrivemåter få det til å klikke og si "aha, det er dét dios mener", men sånn er det tydeligvis ikke.

 

Kan du istedenfor forklare hva din bakgrunn er, så kan jeg heller forsøke å tilpasse meg ditt fag?

 

(Min bakgrunn er informatikk og noen års aktiv deltakelse i comp.arch og på RealWorldTech.)

 

For øvrig er det neppe særlig relevant for den saklige delen av diskusjonen akkurat hva man mener med "spesialisert" og "generell" mikroprosessor, siden den i hovedsak ser ut til å dreie seg om hvorvidt det er sannsynlig at funksjoner som finnes i grafikkoprosessorer i dag i fremtiden kan integreres i den sentrale mikroprosessoren.

 

(Hvis vi ser bort fra all støyen, da.)

 

Jeg har vel fulgt med sånn tålelig bra tror jeg. Jeg har ikke sagt at problemene er uløselige, bare at det ikke er fullt så rett frem som du vil ha det til.

Hvor "rett frem" er det du tror at jeg vil ha det til å være?

 

Jeg har ikke hevdet at det i dag er trivielt å implementere funksjonene som er i f.eks. en GF 8800 på samme brikke som en x86-64-kjerne, men jeg har (mer eller mindre) hevdet at det er en naturlig utvikling for fremtiden.

 

 

Tror du er litt hårsår her, jeg avfeide ikke det, derimot prøvde jeg å utvide din horisont noe. Det er trender over tid som du antagelig ikke helt har fått med deg, referanse til minne-ytelse er et klart hint.

Her har jeg nok fått med meg litt mer enn du antar at jeg har. Det er litt vanskelig for meg å gjette på hva det er du har fått med deg, men her er noe av det jeg har forsøkt å hinte på, om enn indirekte:

 

Desto nærere komponentene er hverandre, desto raskere kan kommunikasjon mellom komponentene foregå. Transport av data til og fra minne, uavhengig av om det er cache inni komponentene, "ekstern" cache, eller systemminne er like avhengig av nærhet for høye transporthastigheter som andre komponenter er.

 

Dette er ganske opplagt så lenge vi faktisk er begrenset av lyshastigheten. Hvis vi på et eller annet tidspunkt klarer å overføre meningsbærende data pålitelig i hastigheter høyere enn det lyset klarer, ja, da får vi kanskje gjøre regnestykkene på nytt.

 

Hvis vi ser på det konkrete tilfellet vi har i dag, så er ytelsen for en ekstern grafikkoprosessor sterkt begrenset pga. dataoverføringsraten. PCIe 2.0 tillater inntil 5 Gbps i én kanal, eller 160 Gbps i 32 kanaler. 160 Gbps (snaut 16 GBps i beste tilfelle i praksis) høres ganske mye ut, men forsinkelsen for overføring ("latency") er ikke så veldig imponerende: med 8 kanaler snakker vi om 20-25 cycles latency, eller 80-100 ns. Det var veldig kult da jeg hadde en 386, men ikke så kult til min Pentium 90.

 

Det er mulig at referansen din til "minneytelse" angår det at moderne grafikkoprosessorer bruker GDDR3 som sitt lokale minne, og at det i f.eks. GeForce 8800 er høy dataoverføringsrate mellom GPU og dens eget minne, med teoretisk maksimum 86,4 GB/s. I så tilfelle forsto jeg ikke relevansen, det er mulig at forkjølelsen har spilt meg et puss her.

 

Det er i dag svært lite i veien for at f.eks. AMD kunne laget en dual-core prosessor som hadde en del x86-64-kjerne og en annen del "R700", som i kraft av sin nærhet mellom hovedprosessor og grafikkoprosessor ville kunne oppnå vesentlig bedre ytelse.

Interessant forslag, kanskje du kan dele litt mer detaljer rundt denne arkitekturen. Sikter du til en high end GPU når du sier R700?

Jeg valgte navnet "R700" for at vi kunne tenke oss en etterfølger til R600. Vi vet jo begge at det ikke finnes noen slik kombinert prosessor fra AMD i dag.

 

Cell ja, du mener altså SPE'ene i Cell? Ser du andre noen problemer med Cell? Minnekonfigurasjon kanskje? Ytelse på generell kode? Eller kanskje du ser for deg at x86 endelig er død?

Jeg mener at Cell-arkitekturen har tatt grafikkhåndteringen inn i den samme integrerte kretsen.

 

Cell har klart sine arkitekturmessige utfordringer, men det er et klart eksempel på at man har tatt en generell prosessorarkitektur (PowerPC) og integrert med grafikkhåndtering på en og samme brikke. Problemet er "løst".

 

Minnekonfigurasjon? Kan du være litt mer konkret?

 

Ytelse på generell kode: denne er jo selvsagt bundet opp til den delen av prosessoren som håndterer "generell kode", integreringen av grafikkoprosessorene gjør jo ikke at ytelsen på denne blir forholdsvis bedre.

 

At x86 endelig er død-forestillingen har jeg, så vidt jeg husker, aldri hatt, selv om jeg var med på jubelen da PowerPC-arkitekturen ble lansert, da MIPS R4000 slo til, da UltraSPARC kom, og igjen da Power 4 kom. Jeg skjønner ikke relevansen for spørsmålet, men regner med at du utdyper dersom det var seriøst ment.

 

 

(Edit: fjernet ekstra ]-tegn i sitat)

Endret 21. februar 2007 av dios

[ATWindsor]

Som en liten digresjon, så vil lys bevege seg ca 0.3 meter per nanosekund, elektriske signaler kanskje 2/3 av dette(?)

 

AtW

[Del]

Pot, kettle, black.

Kan det tenkes at du har et forbilde i Australia?

noen års aktiv deltakelse i comp.arch og på RealWorldTech.)

Kanskje du da kan dele hvilket nick du bruker der?

 

For øvrig er det neppe særlig relevant for den saklige delen av diskusjonen akkurat hva man mener med "spesialisert" og "generell" mikroprosessor, siden den i hovedsak ser ut til å dreie seg om hvorvidt det er sannsynlig at funksjoner som finnes i grafikkoprosessorer i dag i fremtiden kan integreres i den sentrale mikroprosessoren.

På dette punktet er jeg tvilende, men hvis du hadde lest mitt svar til AtWindsor ville du sett at jeg har tenkt å se på mulighetene. Nå er jo AMD sine fusion planer velkjent, så det er en trivialitet at det er konkrete planer der, men hvorvidt dette er rettet mot high end er et ganske åpent spørsmål, og om det er så sikkert at det blir i fremtiden er også en annen sak.

Jeg har ikke hevdet at det i dag er trivielt å implementere funksjonene som er i f.eks. en GF 8800 på samme brikke som en x86-64-kjerne, men jeg har (mer eller mindre) hevdet at det er en naturlig utvikling for fremtiden.

Ved å fremheve noen trender mens du ignorerer andre?

 

Her har jeg nok fått med meg litt mer enn du antar at jeg har. Det er litt vanskelig for meg å gjette på hva det er du har fått med deg, men her er noe av det jeg har forsøkt å hinte på, om enn indirekte:

 

Desto nærere komponentene er hverandre, desto raskere kan kommunikasjon mellom komponentene foregå. Transport av data til og fra minne, uavhengig av om det er cache inni komponentene, "ekstern" cache, eller systemminne er like avhengig av nærhet for høye transporthastigheter som andre komponenter er.

Cache er dyrt, og lite fleksibelt.

 

Hvis vi ser på det konkrete tilfellet vi har i dag, så er ytelsen for en ekstern grafikkoprosessor sterkt begrenset pga. dataoverføringsraten. PCIe 2.0 tillater inntil 5 Gbps i én kanal, eller 160 Gbps i 32 kanaler. 160 Gbps (snaut 16 GBps i beste tilfelle i praksis) høres ganske mye ut, men forsinkelsen for overføring ("latency") er ikke så veldig imponerende: med 8 kanaler snakker vi om 20-25 cycles latency, eller 80-100 ns. Det var veldig kult da jeg hadde en 386, men ikke så kult til min Pentium 90.

Mener du at dette er et problem for grafikk, eller for gpgpu?

 

Det er mulig at referansen din til "minneytelse" angår det at moderne grafikkoprosessorer bruker GDDR3 som sitt lokale minne, og at det i f.eks. GeForce 8800 er høy dataoverføringsrate mellom GPU og dens eget minne, med teoretisk maksimum 86,4 GB/s. I så tilfelle forsto jeg ikke relevansen, det er mulig at forkjølelsen har spilt meg et puss her.

Så la meg hjelpe deg. Å få den latency og båndbredde som en high end GPU nyttiggjør seg lokalt til en CPU vil være vanskelig å forene med modulært minne en god stund fremover.

 

Jeg mener at Cell-arkitekturen har tatt grafikkhåndteringen inn i den samme integrerte kretsen.

 

Cell har klart sine arkitekturmessige utfordringer, men det er et klart eksempel på at man har tatt en generell prosessorarkitektur (PowerPC) og integrert med grafikkhåndtering på en og samme brikke. Problemet er "løst".

Har ikke PS3 egen GPU?

 

Minnekonfigurasjon? Kan du være litt mer konkret?

Cell har 256MB punktum.

 

At x86 endelig er død-forestillingen har jeg, så vidt jeg husker, aldri hatt, selv om jeg var med på jubelen da PowerPC-arkitekturen ble lansert, da MIPS R4000 slo til, da UltraSPARC kom, og igjen da Power 4 kom. Jeg skjønner ikke relevansen for spørsmålet, men regner med at du utdyper dersom det var seriøst ment.

(Edit: fjernet ekstra ]-tegn i sitat)

7993847[/snapback]

Utdypningen er at Cell har sine svakheter som følge av det designet som er lagt opp, m.a.o. det er ikke noe bevis på din framtidsvisjon.

Endret 21. februar 2007 av Del

[dios]

Kanskje du da kan dele hvilket nick du bruker der?

På comp.arch bruker man ikke nick, men fullt navn.

 

Men hvilken relevans har det?

 

Jeg er fortsatt interessert i hvilken bakgrunn du har, slik at jeg kan kommunisere bedre med deg.

 

Jeg bryr meg ikke om hvilke kallenavn du bruker andre steder, eller hva ditt fulle navn er.

 

Jeg har ikke hevdet at det i dag er trivielt å implementere funksjonene som er i f.eks. en GF 8800 på samme brikke som en x86-64-kjerne, men jeg har (mer eller mindre) hevdet at det er en naturlig utvikling for fremtiden.

Ved å fremheve noen trender mens du ignorerer andre?

Kan du være litt mer konkret?

 

Cache er dyrt, og lite fleksibelt.

Det var jo et ganske kort svar som har liten relevans i forhold til det jeg skrev, så vidt jeg kan se, men kanskje du har et annet poeng?

 

Terje Mathisen skrev at "all programmering er en øvelse i caching". Du er tilsynelatende uenig. Hvorfor?

 

 

Angående latency i PCIe:

Mener du at dette er et problem for grafikk, eller for gpgpu?

Jeg mener dette er et problem for datatransport over PCIe, og i den grad grafikkoprosessor skal brukes til beregniner i samkvem med hovedprosessoren, så er det et problem.

 

 

Det er mulig at referansen din til "minneytelse" angår det at moderne grafikkoprosessorer bruker GDDR3 som sitt lokale minne, og at det i f.eks. GeForce 8800 er høy dataoverføringsrate mellom GPU og dens eget minne, med teoretisk maksimum 86,4 GB/s. I så tilfelle forsto jeg ikke relevansen, det er mulig at forkjølelsen har spilt meg et puss her.

Så la meg hjelpe deg.

Kan du være så snill og legge av deg den nedlatende tonen?

 

Å få den latency og båndbredde som en high end GPU nyttiggjør seg lokalt til en CPU vil være vanskelig å forene med modulært minne en god stund fremover.

Akkurat. Jeg kan ikke se at jeg har hevdet noe som går på tvers av dette.

 

Jeg mener at Cell-arkitekturen har tatt grafikkhåndteringen inn i den samme integrerte kretsen.

 

Cell har klart sine arkitekturmessige utfordringer, men det er et klart eksempel på at man har tatt en generell prosessorarkitektur (PowerPC) og integrert med grafikkhåndtering på en og samme brikke. Problemet er "løst".

Har ikke PS3 egen GPU?

Jo, men en veldig stor del av jobben gjøres nå i Cell-prosessoren.

 

Beklager om jeg formulerte meg slik at du trodde at jeg mente at Cell-prosessoren har overtatt alle oppgaver.

 

Minnekonfigurasjon? Kan du være litt mer konkret?

Cell har 256MB punktum.

Din påstand er feil.

 

Utdypningen er at Cell har sine svakheter som følge av det designet som er lagt opp, m.a.o. det er ikke noe bevis på din framtidsvisjon.

Neivel. Hva med de øvrige punktene?