mboost-dp1
Microsoft Corporation
#5
Hverken p/Invoke eller mixed mode C++ goer at hardwaren tilgåes via .NET - det exposer bare en .NET wrapper for den native kode.
Det native kode er nødvendig.
Man kunne også sagtens forestille sig at MS kommer med en officiel .NET wrapper.
Men givet at number crunching typisk laves i native kode, så er det næppe en high priority.
Hverken p/Invoke eller mixed mode C++ goer at hardwaren tilgåes via .NET - det exposer bare en .NET wrapper for den native kode.
Det native kode er nødvendig.
Man kunne også sagtens forestille sig at MS kommer med en officiel .NET wrapper.
Men givet at number crunching typisk laves i native kode, så er det næppe en high priority.
#6
Sarkasme er spildt på dig :p
Ej, spøg til side. F# kan nu også bruges til number crushing. Det er ihvertfald noget nemmere at parallelisere F#/C#, end C++ til regulare CPU'er.
Men AMP har jo et helt andet formål.
Jeg synes dog det er sørgeligt at man stadigvæk er af den opfattelse af C++ er det eneste sprog der kan bruges til formålet. Hvorfor ikke f.eks. OCaml?
Sarkasme er spildt på dig :p
Ej, spøg til side. F# kan nu også bruges til number crushing. Det er ihvertfald noget nemmere at parallelisere F#/C#, end C++ til regulare CPU'er.
Men AMP har jo et helt andet formål.
Jeg synes dog det er sørgeligt at man stadigvæk er af den opfattelse af C++ er det eneste sprog der kan bruges til formålet. Hvorfor ikke f.eks. OCaml?
#7
Er F# godt til at parallelisere? SVJV så minder F# meget om ocaml, og ocaml har aldrig rigtig været god til shared memory multiprocessing (selvom der findes gode libraries til distributed MP, men det er noget andet).
Edit: dvs. ocaml har ikke understøttet multicores indtil nogen lavede en compiler som jeg ikke er klar over hvor god er.
Er F# godt til at parallelisere? SVJV så minder F# meget om ocaml, og ocaml har aldrig rigtig været god til shared memory multiprocessing (selvom der findes gode libraries til distributed MP, men det er noget andet).
Edit: dvs. ocaml har ikke understøttet multicores indtil nogen lavede en compiler som jeg ikke er klar over hvor god er.
#8
Det skal jeg ikke kunne sige. Jeg går sjældent så dybt ned. Men jeg tror ikke at det er dårligere end f.eks. Erlang.
Spørgsmålet er nok om hvilke type operationer der skal arbejdes med. Hvis der kræves mere detaljeret memory kontrol, er C++ sikkert stadigvæk bedst.
Selvom vi snart burde finde en afløser for C++, med en mindre sindsyg syntaks.
Det skal jeg ikke kunne sige. Jeg går sjældent så dybt ned. Men jeg tror ikke at det er dårligere end f.eks. Erlang.
Spørgsmålet er nok om hvilke type operationer der skal arbejdes med. Hvis der kræves mere detaljeret memory kontrol, er C++ sikkert stadigvæk bedst.
Selvom vi snart burde finde en afløser for C++, med en mindre sindsyg syntaks.
#9
C++ har den fordel, når man snakker parallell computing, at det ikke er garbage collected. Parallell GC er hammersvært/ineffektivt.
C++ har den fordel, når man snakker parallell computing, at det ikke er garbage collected. Parallell GC er hammersvært/ineffektivt.
Windcape (11) skrev:#10
Mjah, GC er jo sådan mere eller mindre optimal når vi ikke er i en .NET/Java context.
Jeg tænkte også mere på ren OCaml eller ML. De kan også kompileres til native code svjv, men selve sprogene er en del mere sane, end C++.
???(!)
Windcape (7) skrev:F# kan nu også bruges til number crushing. Det er ihvertfald noget nemmere at parallelisere F#/C#, end C++ til regulare CPU'er.
onetreehell (8) skrev:Er F# godt til at parallelisere? SVJV så minder F# meget om ocaml, og ocaml har aldrig rigtig været god til shared memory multiprocessing
Windcape (9) skrev:Det skal jeg ikke kunne sige. Jeg går sjældent så dybt ned. Men jeg tror ikke at det er dårligere end f.eks. Erlang.
Nu skal vi være meget påpasselige med hvad vi diskuterer.
"godt" er sådan en lidt bred term.
Snakker vi "nemt at skrive parallelle programmer som er korrekte" eller "maksimerer performance på parallele systemer"?
Erlang er rigtigt god til det første og rigtigt dårligt til det andet.
onetreehell (10) skrev:
C++ har den fordel, når man snakker parallell computing, at det ikke er garbage collected. Parallell GC er hammersvært/ineffektivt.
Parallel GC performer fint.
Problemerne ligger i real time egenskaberne (pauser).
Men det er ikke et problem for number crunching.
#sprog til number crunching
Grundene til at Fortran/C/C++ er så dominerende er vel:
* det er de sprog som diverse biblioteker (LINPACK, BLAS etc.) kommer med bindings til
* det er sprog som ikke checker for array index out of bounds (det kan godt være dyrt for heftige matrix beregninger)
* det er sprog som gør det nemt at interface hardware (embedde eller linke med assembler)
* det er sprog hvor compiler optimizere traditionelt er gode
* den selvforstærkende effekt af at det bruger alle andre
Grundene til at Fortran/C/C++ er så dominerende er vel:
* det er de sprog som diverse biblioteker (LINPACK, BLAS etc.) kommer med bindings til
* det er sprog som ikke checker for array index out of bounds (det kan godt være dyrt for heftige matrix beregninger)
* det er sprog som gør det nemt at interface hardware (embedde eller linke med assembler)
* det er sprog hvor compiler optimizere traditionelt er gode
* den selvforstærkende effekt af at det bruger alle andre
Jer der snakker om en udgave af det til .NET kunde måske tage et gik på http://www.yourfilelink.com/get.php?fid=697999 hvor vi laver noget tilsvarende til .NET selv om at det dog bruger CUDA
#22
Jo men efter som vi først skal op og forsvare det på Torsdag har universitetet ikke gjort den tilgængelig i nu og så er yourfilelink bare så meget letter end så meget andet ;-)
håber desuden på at vi en gang efter eksamen får taget os sammen til at få sat noget GPL på vores kode og lagt det på sourceforge :-)
Jo men efter som vi først skal op og forsvare det på Torsdag har universitetet ikke gjort den tilgængelig i nu og så er yourfilelink bare så meget letter end så meget andet ;-)
håber desuden på at vi en gang efter eksamen får taget os sammen til at få sat noget GPL på vores kode og lagt det på sourceforge :-)
onetreehell (17) skrev:Det kunne jeg godt tænke mig nogle kilder på.
Et af de klassiske papirer er:
http://www.cs.colorado.edu/department/publications...
Det sammenligner C/C++ uden og med GC (men jeg vil tillade mig at antage at der er brugt mere tid på at optimere Java/.NET GC end C/C++ GC).
#25
Nu har jeg kun skimtet den igennem, men umiddelbart ser det ud til at være til singlecore programmer.
Nu har jeg kun skimtet den igennem, men umiddelbart ser det ud til at være til singlecore programmer.
I erlang har hver tråd sin egen lille heap og så er der en stor global heap for store (delte) objekter. Det betyder at det meste af al garbage collection kan foregå parallelt.
Erlang bruger så message passing, hvilket er lidt noget andet.
jeg *mener* ikke at et free() i en tråd har indflydelse på en anden tråd i samme process så længe den anden ikke også prøver. Det gælder i hvert fald for processer.
Erlang bruger så message passing, hvilket er lidt noget andet.
jeg *mener* ikke at et free() i en tråd har indflydelse på en anden tråd i samme process så længe den anden ikke også prøver. Det gælder i hvert fald for processer.
#29
http://linux.derkeiler.com/Newsgroups/comp.os.linu...
antyder at de "gør et eller andet" for at håndtere threads.
http://linux.derkeiler.com/Newsgroups/comp.os.linu...
antyder at de "gør et eller andet" for at håndtere threads.
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