mboost-dp1
SXC - clix
Jeg har aldrigt helt forstået hvorfor folk mener det er så svært at lave multicore udvikling?
Altså...det er da ikke nemt, men det er der da så mange ting der ikke er?
Har i andre kodere meget svært ved det?
Altså...det er da ikke nemt, men det er der da så mange ting der ikke er?
Har i andre kodere meget svært ved det?
Skiftet er blevet betydeligt mindre eftersom at LINQ tilbyder funktionel programming og funktionelle tankegange direkte i C#, på en naturlig måde, som hurtig højner ens produktivitet, og sikre bedre kode, som er nemmere at vedligeholde.
Det er specielt higher-order functions som f.eks. map og reduce som gør arbejdet nemt i alm. programmeringsituationer.
Dertil kommer så at programmøren begynder at tænke i mere funktionelle baner, og prøver at opnå immutability hvor det er muligt (også selvom sprogene ikke understøtter det)
Det er specielt higher-order functions som f.eks. map og reduce som gør arbejdet nemt i alm. programmeringsituationer.
Dertil kommer så at programmøren begynder at tænke i mere funktionelle baner, og prøver at opnå immutability hvor det er muligt (også selvom sprogene ikke understøtter det)
Paradigme skift er altid svære. Skiftet fra procedural programmering til OOP var svært.moveax1ret (2) skrev:Har i andre kodere meget svært ved det?
Ligeledes er tankegangen om at du ikke må have et mutable state, fordi det derfor ikke (umiddelbart) kan paralleliseres, ikke helt nem for den alm. programmør, som er vant til at have både public og private fields, som alle er mutable.
#2 Chipproducenterne vil gerne leve videre på Moore's bølge. Det kan de kun, hvis udviklerne skriver programmer, der rent faktisk udnytter multiprocessing.
Om det er nemt eller ej er sekundært til det problem, at få programmer i dag skrives, så de udnytter mere en halvdelen af computerens kraft.
Om det er nemt eller ej er sekundært til det problem, at få programmer i dag skrives, så de udnytter mere en halvdelen af computerens kraft.
#5
Jeg mente nu om i har svært ved f.eks. at lave en multithreaded web server der deler noget data mellem processer/threads og så lave noget synkronisering?
I whatever sprog i bruger nu.
Jeg mente nu om i har svært ved f.eks. at lave en multithreaded web server der deler noget data mellem processer/threads og så lave noget synkronisering?
I whatever sprog i bruger nu.
#6
Du kan godt parallelisere et ikke-funktionelt program. Det er bare meget mere besværligt, og du risikere at skulle debugge side effects.
Du kan godt parallelisere et ikke-funktionelt program. Det er bare meget mere besværligt, og du risikere at skulle debugge side effects.
jamen nu snakker jeg jo ikke om funktionelle sprog- mit spørgsmål er: har i svært ved at kode til multi processors lige nu i c#, java, c++ whatever?
ja, det ved jeg da udmærket godt- jeg sidder faktisk netop lige nu og koder en multithreaded/process applikation i c++.
jeg spørger- nu for tredje gang: HAR DU SVÆRT VED DET SOM DET ER NU????
jeg spørger- nu for tredje gang: HAR DU SVÆRT VED DET SOM DET ER NU????
Derudover har funktionelle sprog jo forskellige features, som ikke nødvendigvis er et krav for at arbejde funktionelt, men giver fordele i typiske matematisk operationer, eller tunge algoritmer.
Det er f.eks. sådan at head::tail call i F# kan gøres simpelt på få linjers kode (3-4), som er let læsbart, hvor i C# kræver det mange (15-25), og er meget mindre læsbart.
Og så er der funktionalitet som pattern-matching og method pipiing, samt monads (Haskell)
Det er f.eks. sådan at head::tail call i F# kan gøres simpelt på få linjers kode (3-4), som er let læsbart, hvor i C# kræver det mange (15-25), og er meget mindre læsbart.
Og så er der funktionalitet som pattern-matching og method pipiing, samt monads (Haskell)
Det kan matematiks bevises at fejlraten er større når du arbejder med mutable state, pga. side-effects.moveax1ret (12) skrev:jeg spørger- nu for tredje gang: HAR DU SVÆRT VED DET SOM DET ER NU????
Derfor må svaret jo være "ja". Da flere fejl nødvendigvis gør udviklingsprocessen sværere.
Det er derudover meget nemmere at implementere en paralleliseret process i funktionelle sprog, end i alm. imperative sprog.
At det godt kan lade sig gøre, betyder jo ikke at det er optimalt! Hvis alle tænkte sådan, arbejde vi stadigvæk i ASM eller COBOL.
nu har jeg ikke prøvet funktionelle sprog- men hvis jeg nu bruger const for at undgå sideeffects, og ikke bruger globale variabler opnår jeg ikke så ca. det samme?
(c++0x)
(c++0x)
#15
Hvis du programmere alle dine funktioner som higher-order functions, og ikke bruger mutable datatypes (pointers), og ligeledes kun bruger konstante værdier, og ingen class fields, opnår du cirka det samme.
Men hvis du forsøger at bilde mig ind du koder C++ uden pointers, så har jeg svært ved at tro på dig ;-)
Tænk på det som at *alting* *altid* skal "pass by value", og *alle* methoder har en værdi-type som return-type (altså ingen void!)
Hvis du programmere alle dine funktioner som higher-order functions, og ikke bruger mutable datatypes (pointers), og ligeledes kun bruger konstante værdier, og ingen class fields, opnår du cirka det samme.
Men hvis du forsøger at bilde mig ind du koder C++ uden pointers, så har jeg svært ved at tro på dig ;-)
Tænk på det som at *alting* *altid* skal "pass by value", og *alle* methoder har en værdi-type som return-type (altså ingen void!)
det er ikke meget galt :) har du hørt om referencer?
Og hvis det så er at jeg skal interface til noget c bruger jeg shared_ptr eller auto_ptr
men, referencer tillader jo også at man kan ændre dataen, så det er lidt ordkløveri, men så kommer const jo ind i billedet :)
Og hvis det så er at jeg skal interface til noget c bruger jeg shared_ptr eller auto_ptr
men, referencer tillader jo også at man kan ændre dataen, så det er lidt ordkløveri, men så kommer const jo ind i billedet :)
@#7
Nu er der ret stor forskel på banal grovkornet parallelitet, som fx en webserver og så faktisk speedup hvor fx en ligningsløser skal paralleliseres over mange kerner samtidigt med at man tager hensyn til cache lokalitet:)
Nu er der ret stor forskel på banal grovkornet parallelitet, som fx en webserver og så faktisk speedup hvor fx en ligningsløser skal paralleliseres over mange kerner samtidigt med at man tager hensyn til cache lokalitet:)
Jeg har studeret datalogi.
jeg har haft funktionel programmerings kurserne.
Dette er ikke en nyhed, alle der har haft disse kurser ved at det er en god måde for paralisering..
Kort forklaret hvad funktionel programmering er, tænk rekursiv, det er en meget god metode at anvende til f.eks. parser og andre ting der kræver rekursiv tænkning.
Hvis det ikke lige præsis er for disse problemer der hvor funktionel programmering er god, så er det noget være lort.
Glem alt om løkker (loop) while repeat. Det skal gøres rekrusivt.
god fornøjelse med at debugge en rekrusive funktion, hahaha eller for den sagts skyld at læse kode og forstå hvad der sker.
jeg har haft funktionel programmerings kurserne.
Dette er ikke en nyhed, alle der har haft disse kurser ved at det er en god måde for paralisering..
Kort forklaret hvad funktionel programmering er, tænk rekursiv, det er en meget god metode at anvende til f.eks. parser og andre ting der kræver rekursiv tænkning.
Hvis det ikke lige præsis er for disse problemer der hvor funktionel programmering er god, så er det noget være lort.
Glem alt om løkker (loop) while repeat. Det skal gøres rekrusivt.
god fornøjelse med at debugge en rekrusive funktion, hahaha eller for den sagts skyld at læse kode og forstå hvad der sker.
#24 Hvis du tænker lidt nærmere over det, så giver det ikke særligt meget mening at debugge i traditionel forstand hvis man arbejder i et rent funktionelt sprog.
Hvad er det man laver når man debugger i et imperativt sprog? Man stepper igennem sin kode trin for trin, og ser hvornår programmet kommer i en ugyldig tilstand. Men da tilstand er fraværende i et rent funktionelt sprog, er alt hvad du har brug for at analysere, et trace af kaldet til den funktion som ikke opfører sig som forventet.
Hvad er det man laver når man debugger i et imperativt sprog? Man stepper igennem sin kode trin for trin, og ser hvornår programmet kommer i en ugyldig tilstand. Men da tilstand er fraværende i et rent funktionelt sprog, er alt hvad du har brug for at analysere, et trace af kaldet til den funktion som ikke opfører sig som forventet.
ildhesten skrev:Hvad er det man laver når man debugger i et imperativt sprog? Man stepper igennem sin kode trin for trin, og ser hvornår programmet kommer i en ugyldig tilstand. Men da tilstand er fraværende i et rent funktionelt sprog, er alt hvad du har brug for at analysere, et trace af kaldet til den funktion som ikke opfører sig som forventet.
arrr jeg må indrømme når du nu skriver det så har du ret.
en småkage til dig.
Men jeg vil stadig påstå at finde fejl i et funktionel sprog ikke er sjov, ikke fordi det er sjoverede i et imprerativ sprog, men recrusive funktioner stinker når det kommer til at finde fejl i dem.
#moveax1ret
Hvis du ikke synes OOP udvikling til multicore er svært... then you ain't doing it right...
Jeg har arbejdet meget med det - og hvis du vil udnytte mere end bare et par kerner bare nogenlunde effektivt så skal man altså have gang i de små grå, og en meget stor procentdel af de apps der bliver lavet virker mere ved tilfælde end noget andet.
Det letteste du kan lave er en server hvor du har mindst lige så mange bruger-requests som du har kerner og hvor du bruger et datastore (f.eks. en database) hvor nogen med fedtede briller har løst problemerne for dig. Det svære i server apps ligger andre steder, f.eks. når man vil kunne håndtere 10.000 concurrent users uden at bruge 90% af sine ressourcer på tråd-schedulering...
Hvis du ikke synes OOP udvikling til multicore er svært... then you ain't doing it right...
Jeg har arbejdet meget med det - og hvis du vil udnytte mere end bare et par kerner bare nogenlunde effektivt så skal man altså have gang i de små grå, og en meget stor procentdel af de apps der bliver lavet virker mere ved tilfælde end noget andet.
Det letteste du kan lave er en server hvor du har mindst lige så mange bruger-requests som du har kerner og hvor du bruger et datastore (f.eks. en database) hvor nogen med fedtede briller har løst problemerne for dig. Det svære i server apps ligger andre steder, f.eks. når man vil kunne håndtere 10.000 concurrent users uden at bruge 90% af sine ressourcer på tråd-schedulering...
#28
nu foregår det heller ikke med OOP, men med pthreads/winapi og c, og jeg skulle mene jeg klarer mig ok.
og angående db backend har jeg prøvet at bruge inmem db i sqlite til det, men jeg kan klare det bedre selv.
nu foregår det heller ikke med OOP, men med pthreads/winapi og c, og jeg skulle mene jeg klarer mig ok.
og angående db backend har jeg prøvet at bruge inmem db i sqlite til det, men jeg kan klare det bedre selv.
Windcape (13) skrev:Det er f.eks. sådan at head::tail call i F# kan gøres simpelt på få linjers kode (3-4), som er let læsbart, hvor i C# kræver det mange (15-25), og er meget mindre læsbart.
Jeg forstår ikke hvad du mener med head::tail call... Det lyder som noget værre nonsense. "::"-operatoren bruges til at putte 'head' på listen 'tail'. Her er noget OCaml (ikke OCalm ffs!).
[code}
# 1::[2; 3];;
- : int list = [1; 2; 3]
[/code]
Generelt lyder det som om du ikke har styr på noget/særligt meget af det du siger.
EDIT: btw du skrevet 13/30 posts. >.<
#2
Jeg synes ikke det er svært. Der er bare meget man skal holde styr på, nogle gange, og man skal tænke sig godt om.
Jeg har nogle gange haft problemer med koordinering når programmet får ekstern input to forskellige steder og de ikke skal behandle det på samme tid, men man kan ikke stoppe dem midt i behandlingen (da det skal være atomisk). Men det er nok mere fordi jeg prøver at parallelisere noget der egentlig ikke kan paralleliseres :)
onetreehill: Jeg tror det windcape mener er at pattern matche en liste og dens hoved med x::xs, men det er muligt at jeg tager fejl.
Definér "svært"?moveax1ret (2) skrev:Jeg har aldrigt helt forstået hvorfor folk mener det er så svært at lave multicore udvikling?
Altså...det er da ikke nemt, men det er der da så mange ting der ikke er?
Har i andre kodere meget svært ved det?
Svært ved at få koden til at køre fejlfrit?
Svært ved at debugge når koden IKKE kører fejlfrit?
Svært ved at skalere lineært (eller superlineært - det KAN gøres for visse problemer)?
Personligt vil jeg svare ja til punkt #2 og #3, når vi ser videre end trivielle problemer.
State kan ikke universelt undgås, og parallelisering er ikke kun interessant for ren talknusningskode... men der er bestemt en rigtigt god pointe i at undgå shared state som pesten, og dén lektie fra de funktionelle sprog kan direkte adopteres i såvel OOP som procedural kodning :)
#32>>> Ja, alle de ting- og med simulering af kæmpe workload, og profilering af koden.
Det er da ikke nemt- men når man har forstået hvad tingene går ud på- er det blot endnu en af de besværlige ting.
Men så sandeligt ikke noget jeg umiddelbart vil lære en nyt programmerings paradigme for at slippe for at tænke på.
Faktisk gyser jeg lidt ved tanken om at abstrahere væk fra hvad der egenligt foregår.
Det er da ikke nemt- men når man har forstået hvad tingene går ud på- er det blot endnu en af de besværlige ting.
Men så sandeligt ikke noget jeg umiddelbart vil lære en nyt programmerings paradigme for at slippe for at tænke på.
Faktisk gyser jeg lidt ved tanken om at abstrahere væk fra hvad der egenligt foregår.
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