mboost-dp1
Intel
Jeg tror vidst Pat Gelsinger har sovet i timen...
det er hverken nemmere eller sværere, at programmere til CUDA/FireStream end det er til IA x86/x64.
at kunne udnytte ressourcerne i alle 3 tilfælde optimalt, kræver nøjsom kendskab til CPU/GPU'ernes muligheder, samt compilerens måde at tolke forskellige stykker kode på - ergo er ingen af dem nemme.
pt. er der nogle gutter som arbejder på en .NET/C++ wrapper til CUDA som skulle gøre programmerings arbejdet en tand lettere i Nvidia's tilfælde - og jeg vil gætte på at FireStream også snart kan programmeres via .NET eller andet semi-abstrakt sprog.
Dét som Pat heller ikke helt har indset, er at NVidia 8800 lammetæver SAMTLIGE CPU'er på markedet i FLOPS.
CUDA:
- 2x Realtime Encoding af 1080p HD film
- Live simulering af galakse sammenstød (1 GFLOP)
- Rådden hurtig transcoding af diverse film-formater
pointen er, at CPU'er er gode til mange ting, men "langsomme" og nyttige... mens GPU'er er gode til få ting men afsindig hurtige
GPU'er er kommet for at blive, mindst lige så meget som CPU'er
det er hverken nemmere eller sværere, at programmere til CUDA/FireStream end det er til IA x86/x64.
at kunne udnytte ressourcerne i alle 3 tilfælde optimalt, kræver nøjsom kendskab til CPU/GPU'ernes muligheder, samt compilerens måde at tolke forskellige stykker kode på - ergo er ingen af dem nemme.
pt. er der nogle gutter som arbejder på en .NET/C++ wrapper til CUDA som skulle gøre programmerings arbejdet en tand lettere i Nvidia's tilfælde - og jeg vil gætte på at FireStream også snart kan programmeres via .NET eller andet semi-abstrakt sprog.
Dét som Pat heller ikke helt har indset, er at NVidia 8800 lammetæver SAMTLIGE CPU'er på markedet i FLOPS.
CUDA:
- 2x Realtime Encoding af 1080p HD film
- Live simulering af galakse sammenstød (1 GFLOP)
- Rådden hurtig transcoding af diverse film-formater
pointen er, at CPU'er er gode til mange ting, men "langsomme" og nyttige... mens GPU'er er gode til få ting men afsindig hurtige
GPU'er er kommet for at blive, mindst lige så meget som CPU'er
1 skrev:Jeg tror vidst Pat Gelsinger har sovet i timen...
det er hverken nemmere eller sværere, at programmere til CUDA/FireStream end det er til IA x86/x64.
at kunne udnytte ressourcerne i alle 3 tilfælde optimalt, kræver nøjsom kendskab til CPU/GPU'ernes muligheder, samt compilerens måde at tolke forskellige stykker kode på - ergo er ingen af dem nemme.
Enig, for at udnytte x86/x64 optimalt i dag benytter man Intel C++ Compiler med at hav komplekse flag eller Intel Performance Primitives som langt fra er optimalt til i alle tilfælde.
Btw er Firestream et stykke hardware fra AMD som programmeres via AMD Stream SDK.
1 skrev:
pt. er der nogle gutter som arbejder på en .NET/C++ wrapper til CUDA som skulle gøre programmerings arbejdet en tand lettere i Nvidia's tilfælde - og jeg vil gætte på at FireStream også snart kan programmeres via .NET eller andet semi-abstrakt sprog.
Uden at have set det tror jeg ikke helt på at det vil gøre det meget nemmere slet ikke hvis der blot er tale om wrappere. Det er svært at abstrahere de elementer der ikke bare er basal C kode, det svære ved at anvende CUDA imho er at mappe sine problemer til at anvende shared memory mm. Men glæder mig til at se resultatet.
1 skrev:
...
GPU'er er kommet for at blive, mindst lige så meget som CPU'er
Eller også merger de og bliver en hybrid. Steam computing som dækker over den programmeringsmodel man anvender i AMD Stream og Nvidia's CUDA er kommet for at blive. Med Intel's Ct er der også meget der indikerer at Pat Gelsinger mener dette... Intel Ct er bare ikke klart endnu.
Man kan håbe Apple's OpenCL el lign vil blive standardiseret så man kan anvende et universelt sprog til hardware fra både Amd, Ibm, Intel og Nvidia uanset om de kalder det CPU, GPU, PPU, Cell etc.
#2
via google, søgte jeg CUDA og .NET og fant lidt på CUDA's forum..
#3
Jep selvom en CUDA wrapper kun giver adgang, så giver det en række fordele at kunne kalde sin CUDA kode direkte fra sit .NET som i sig selv er nemt at skrive (C# + VS2008)
at man skal vide noget om parallel processering og CUDA spcifik syntax er så en anden sag ;-)
mht. FireStream, så ved jeg intet om det.. CUDA overskygger al interesse for andre GPU'er... efter at have eget et ATI graffikkort efter en lang række Nvidia's, mistede jeg al tro på det firma - magen til halvfærdigt lort... drivere som stinker og hardware som er 1 generation bagud altid... puha
NVidia !!!
via google, søgte jeg CUDA og .NET og fant lidt på CUDA's forum..
#3
Jep selvom en CUDA wrapper kun giver adgang, så giver det en række fordele at kunne kalde sin CUDA kode direkte fra sit .NET som i sig selv er nemt at skrive (C# + VS2008)
at man skal vide noget om parallel processering og CUDA spcifik syntax er så en anden sag ;-)
mht. FireStream, så ved jeg intet om det.. CUDA overskygger al interesse for andre GPU'er... efter at have eget et ATI graffikkort efter en lang række Nvidia's, mistede jeg al tro på det firma - magen til halvfærdigt lort... drivere som stinker og hardware som er 1 generation bagud altid... puha
NVidia !!!
Hvorfor skulle Intel også se en fremtid i konkurrenternes produkter?
Det giver da ikke mening hvis Intel melder du at der er en stor fremtid for GPU'er - hvis de ikke selv har tænkt sig at producere dem..
Det er vel ren logik at man går ind for sine egne teknologier, for at få det største salg.
Det giver da ikke mening hvis Intel melder du at der er en stor fremtid for GPU'er - hvis de ikke selv har tænkt sig at producere dem..
Det er vel ren logik at man går ind for sine egne teknologier, for at få det største salg.
Helt utroligt som de 3 kan kæmpe.
AMD vs. Nvidia er også ganske juicy, specielt det seneste om 3dmark vantage.
Rigtig sjovt at se dem slås offentligt :)
AMD vs. Nvidia er også ganske juicy, specielt det seneste om 3dmark vantage.
Rigtig sjovt at se dem slås offentligt :)
pt. er der nogle gutter som arbejder på en .NET/C++ wrapper til CUDA som skulle gøre programmerings arbejdet en tand lettere i Nvidia's tilfælde - og jeg vil gætte på at FireStream også snart kan programmeres via .NET eller andet semi-abstrakt sprog.
Folk som har brug for at lave ting i CUDA vil altså ikke gøre det i .NET. Det er for langsomt da det jo også kører på en VM. Folk som har brug for CUDA gør det fordi de skal have hurtige resultater. De har tid til at sætte sig ind i CUDA, men får de ikke noget ud af det skifter de jo ikke.
Det gode ved at holde sig til en "rigtig" CPU er jo at man har et OS til at passe på sig. Dermed også et allerede meget effektivt memory management system så man ikke skal tænke over det.
CUDA har ingen memory management og laver endda meget svære memory ting (shared memory) at holde styr på der nemt kan give programfejl. Derudover er der mangler ved CUDA der kan få enhver programmør til at skæmme sig (ingen rekursive funktioner?!). Små ting der gør tiden brugt på CUDA spildt hvis samme ting kunne lade sig gøre på en CPU.
Dog har GPU'en det at den allerede er mangekernet hvor vi idag jo kun har max 8 kernet CPU på tegnebordet (nej en cell har ikke 9 kerner, den har 1 CPU og 8 SPE'er).
På den måde parallel computing fungere kan vi først lave effektive frameworks når vi kommer op omkring 16 kerner, og mange kloge hoveder spår først at vi får lækre system når vi har mere end 100 kerner på en CPU. Og nej grimme parallele ting som erlang er ikke smarte omænd seje.
1 skrev:Dét som Pat heller ikke helt har indset, er at NVidia 8800 lammetæver SAMTLIGE CPU'er på markedet i FLOPS.
Lidt kedeligt at Nvidia "kun" bruger 65 nm.
Men så bliver det først rigtigt sjovt for konkurrenterne når Nvidia går ned til 45 nm.
Det burde reducer strømforbruget og varme udviklingen lidt.
og skruge lidt op for ydelsen :)
Jeg ved ikke med grafik og general purpose, men inden for de tunge områder er der ret mange der udvikler dedikerede koder til eksempelvis at udfører singnalbehandling og andre tunge computerings opgaver hurtigere.
Tro mig, når man snakker simuleringstider der tælles i måneder istedet for timer, så er "det for tidskrævende for programmører at lære de nye programmeringssprog" et direkte dumt udsagn.
Derudover er der inden for den videnskabelige verden ikke nogen stor frygt for at lærer nye værktøjer, bare for sjovs skyld. Kan man forbedre sin code er det bare et plus.
Tro mig, når man snakker simuleringstider der tælles i måneder istedet for timer, så er "det for tidskrævende for programmører at lære de nye programmeringssprog" et direkte dumt udsagn.
Derudover er der inden for den videnskabelige verden ikke nogen stor frygt for at lærer nye værktøjer, bare for sjovs skyld. Kan man forbedre sin code er det bare et plus.
<topic>
Intel prøver vel bare at drive ATI/AMDs aktiekurs ned med de her bekvemt regelmæssige gentagelser af deres mantra om at GPU'en er dødsdømt (hvad den meget vel kan være på den lange bane .. hvem ved).
</topic>
Jeg medforfattede iøvrigt en raytracer, der kører på GPU'en som specialeprojekt på Århus uni. Og det var i 2005 før CUDA kom ud på en gammel Geforce 6800 ultra. GPU'ens kræfter kan snildt udnyttes. Vi skrev i C++/Cg og rendte da ind i nogen enkelte driverproblemer undervejs, men nåede et godt resultat. Når man vænner sig til arkitekturen med stream processering er der virkelig smæk for skillingen, når man flytter sine beregninger over på GPU'en - alt afhængig af det algoritmiske oplæg, naturligvis. Dengang var der en faktor 8 mellem 6800'erens observerede flops og de tidssvarende CPU'ers teoretiske flops - i GPU'ens favør naturligvis.
Intel prøver vel bare at drive ATI/AMDs aktiekurs ned med de her bekvemt regelmæssige gentagelser af deres mantra om at GPU'en er dødsdømt (hvad den meget vel kan være på den lange bane .. hvem ved).
</topic>
Jeg medforfattede iøvrigt en raytracer, der kører på GPU'en som specialeprojekt på Århus uni. Og det var i 2005 før CUDA kom ud på en gammel Geforce 6800 ultra. GPU'ens kræfter kan snildt udnyttes. Vi skrev i C++/Cg og rendte da ind i nogen enkelte driverproblemer undervejs, men nåede et godt resultat. Når man vænner sig til arkitekturen med stream processering er der virkelig smæk for skillingen, når man flytter sine beregninger over på GPU'en - alt afhængig af det algoritmiske oplæg, naturligvis. Dengang var der en faktor 8 mellem 6800'erens observerede flops og de tidssvarende CPU'ers teoretiske flops - i GPU'ens favør naturligvis.
#9: Det afhænger vel af opgaven, hvis det kun er en lille del af programmet man har brug for at optimere på kan det da fint give mening at skrive resten i .NET - det fungerer også ganske overbevisende med Managed DirectX uden et sønderligt performance tab. En 2-3% performancetab i forhold til at skrive det i C er ofte acceptabelt hvis udviklingstiden tilgengæld kan forkortes væsentligt og med CUDA er det jo ikke den slags bagateller man behøver at hænge sig i - det væsentlige værende at man via CUDA til særlige formål kan mange-double performance.
#13
nemlig !
CUDA i .NET køre jo ikke i VM, hvordan hulan skulle den det ?
.NET kalder jo GPU'en igennem wrapperen, som ikke nødvendigvis er managed.
Desuden er .NET ikke meget langsommere end C++, idet de fleste kodestumper, kompileres til maskin kode (JIT) (lidt ligesom Java)
nemlig !
CUDA i .NET køre jo ikke i VM, hvordan hulan skulle den det ?
.NET kalder jo GPU'en igennem wrapperen, som ikke nødvendigvis er managed.
Desuden er .NET ikke meget langsommere end C++, idet de fleste kodestumper, kompileres til maskin kode (JIT) (lidt ligesom Java)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund