Windows og Linux egner sig ikke til 8 kerner
-
af
Pernicious
, redigeret af Avenger-
mboost-dp1
AMD
Undskyld, jeg er vidst blevet blind, for jeg kan ikke finde påstanden om at det er Windows og Linux der er problemet i kilden?
Ud over det, så har Microsoft for et halvt år siden annonceret at Win7 nu let skallerer op til 256 kerner, så hvor XP og Vista ville have problemer så er der taget godt fat i problemet.
Ud over det, så har Microsoft for et halvt år siden annonceret at Win7 nu let skallerer op til 256 kerner, så hvor XP og Vista ville have problemer så er der taget godt fat i problemet.
Linux håndterer kerner ganske udemærket. Gtk er designet til at være threaded og nemt threadsafe, så det er vel i sidste ende applikationsprogrammørerne der fejler. Anywho- det er langt fra alt det er nemt at distribuere over flere kerner så det kan umuligt være nogen overraskelse.
For your enjoyment:
http://img183.imageshack.us/img183/6582/linuxcpuse...
For your enjoyment:
http://img183.imageshack.us/img183/6582/linuxcpuse...
Windows scalerer nu også fint til mange CPU'ere:
http://blogs.technet.com/blogfiles/markrussinovich...
(http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx)
Men som før nævnt, er det mere de programmer/services der kører der scalerer dårligt.
http://blogs.technet.com/blogfiles/markrussinovich...
(http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx)
Men som før nævnt, er det mere de programmer/services der kører der scalerer dårligt.
#7
men... men... det er jo fysisk umuligt...
Lige gyldigt hvor klog du er eller hvor meget du pager din memory så har en 32bit chip altså kun 32 address pins til din fysiske ram, så du kan ikke under nogen omstændigheder addresere mere end 4294967296 bytes (read 4GB) RAM. Jeg ville tage artiklen med et gran salt
You can see physical memory support licensing differentiation across the server SKUs for all versions of Windows. For example, the 32-bit version of Windows Server 2008 Standard supports only 4GB, while the 32-bit Windows Server 2008 Datacenter supports 64GB.
men... men... det er jo fysisk umuligt...
Lige gyldigt hvor klog du er eller hvor meget du pager din memory så har en 32bit chip altså kun 32 address pins til din fysiske ram, så du kan ikke under nogen omstændigheder addresere mere end 4294967296 bytes (read 4GB) RAM. Jeg ville tage artiklen med et gran salt
#11
Der er der såmænd ingen grund til.
32 bit betyder 32 bit virtuelle adresser.
Uden PAE bruger 32 bit windows også 32 bit fysiske adresser, men med PAE bruger de 36 bit fysiske adresser.
Og man kan adressere 64 GB RAM med 36 bit adresser.
(der er så lagt kunstige restriktioner ind på de billige versioner, så de ikke kan bruge 64 GB selv med PAE)
Der er der såmænd ingen grund til.
32 bit betyder 32 bit virtuelle adresser.
Uden PAE bruger 32 bit windows også 32 bit fysiske adresser, men med PAE bruger de 36 bit fysiske adresser.
Og man kan adressere 64 GB RAM med 36 bit adresser.
(der er så lagt kunstige restriktioner ind på de billige versioner, så de ikke kan bruge 64 GB selv med PAE)
#11
Så skulle du læse artiklen der er linket til, den forklarer det fint, men ja det er på meget højt niveau, skrevet af folk der ved hvordan de interne ting i windows kernen fungerer.
Men det er nu ikke mem. jeg ville skrive om, når artikelen er om CPU'ere :)
Derudover er Mark Russinovich ikke hvem som helst, så ham vil jeg nu stole mere på end hvad de fleste skriver :)
( http://en.wikipedia.org/wiki/Mark_Russinovich )
Så skulle du læse artiklen der er linket til, den forklarer det fint, men ja det er på meget højt niveau, skrevet af folk der ved hvordan de interne ting i windows kernen fungerer.
Men det er nu ikke mem. jeg ville skrive om, når artikelen er om CPU'ere :)
Derudover er Mark Russinovich ikke hvem som helst, så ham vil jeg nu stole mere på end hvad de fleste skriver :)
( http://en.wikipedia.org/wiki/Mark_Russinovich )
En af de største problemer jeg ser med multicore systemer i fremtiden er hukommelses flaskehalsen (snæver/begrænset hukommelsesbåndbredde)
- - - -
Mit lille program, som jeg lavede for ikke så længe siden, performede stort set ikke bedre på 4 kerner i forhold til 1 - og jeg kan ikke finde nogen forklaring på det andet end at min hukommelsesbåndbredde bliver max´et ud.
- - - -
Mit lille program, som jeg lavede for ikke så længe siden, performede stort set ikke bedre på 4 kerner i forhold til 1 - og jeg kan ikke finde nogen forklaring på det andet end at min hukommelsesbåndbredde bliver max´et ud.
Overskriften burde nok have været "moderne OS egner sig ikke til flere end 4 kerner".
Men selv dér, passer det ikke helt med virkeligheden. Virkeligheden er ikke, at OSer ikke passer til X kerner, eller at programmer ikke kan finde ud af at udnytte X kerner. Sandheden er nok hellere, at det er helt omvendt. Moderne CPUer passer ikke til moderne programmer.
Man har fundet ud af, at man skal have noget mere juice ud af de gamle CPUer, da man ramte muren omkring 3 GHz. Det kunne ikke længere lade sig gøre, at presse mere ud af den vej at køre videre af RISC vejen, og bare skrue op for klokfrekvensen. I takt med at pipelines blev dybere og dybere blev branch-misses dyrere og dyrere i tabte beregninger. Koden og kompilere blev til en vis grad forbedret til at håndtere dette problem, men kun med en vis succes.
Man gik så en anden vej og sagde "Jamen hvis en computer alligevel kører X processer samtidigt, så kan man jo lave X kerner, og så kan man få X gange så meget performance ud af chippen". Det er så rigtigt til en vis grad. Men oftest har man kun 1 process kørende på full load samtidigt, og denne vil man gerne have til at kunne dele sig i et antal tråde, således at den ene process kan udnytte alle X kerner.
Her kommer så problemet. Hvem gider (eller kan?) sidde og dele en engine af en art i X stykker med X forskellige klumper hukommelse, og definere en kommunikationsprotokol mellem trådene, og få det hele til at køre? Og hvordan gør man det effektivt, så X-1 kerner ikke står og venter på den sidste, da trådene ikke er perfekt balancerede? Og endnu vigtigere: Hvordan skal man dog teste sådan et system, når ukendte processer/tråde kan mase sig ind foran i køen og overtage et antal kerner?
Kerner egner sig bare bedst til at køre selvstændige programmer, og dem kører der sjældent 8 styks af på en alm hjemme-pc.
Jeg tror personligt, at man skulle tage et skridt tilbage og sige "ok vi bruger kun 4 kerner, da man oftes kun kører 4 programmer maks." og så tage et kik på, hvordan moderne kode kører.
I tunge engines benyttes ofte 99% af beregningstiden på 10% af koden. Der er nogle løkker, som itereres et enormt antal gange for at lave forskellige matematiske operationer. Det kan være vektor- eller matrice-beregninger. Kigger man nærmere på disse opgaver, så er de i sig selv ret parallele af natur. Vektorberegninger kan ofte foretages som atomiske operationer, bare ens processor er bred nok (vektorprocessor).
Gik man skridtet tilbage og byggede en processor med 3 traditionelle kerner og en vektorprocessor-kerne, der er i stand til at lave operationer på store sæt data, vil man kunne aflaste de tre andre kerner betydeligt. I stedet for at bruge 99% af tiden på at ligge og fise rundt i for-loops og miste så mange % af tiden i branching og branch-misses, vil man kunne foretage store stykker beregningsarbejde på rekordtid.
Desuden vil det ikke kræve nogen form for synkronisering eller kodning. Programmøren behøver ikke vide andet end at "Det er smart at begrænse vektorberegninger / matriceberegningerne til operationer á X gange Y sæt data, da dette er bredden af CPUen".
Men selv dér, passer det ikke helt med virkeligheden. Virkeligheden er ikke, at OSer ikke passer til X kerner, eller at programmer ikke kan finde ud af at udnytte X kerner. Sandheden er nok hellere, at det er helt omvendt. Moderne CPUer passer ikke til moderne programmer.
Man har fundet ud af, at man skal have noget mere juice ud af de gamle CPUer, da man ramte muren omkring 3 GHz. Det kunne ikke længere lade sig gøre, at presse mere ud af den vej at køre videre af RISC vejen, og bare skrue op for klokfrekvensen. I takt med at pipelines blev dybere og dybere blev branch-misses dyrere og dyrere i tabte beregninger. Koden og kompilere blev til en vis grad forbedret til at håndtere dette problem, men kun med en vis succes.
Man gik så en anden vej og sagde "Jamen hvis en computer alligevel kører X processer samtidigt, så kan man jo lave X kerner, og så kan man få X gange så meget performance ud af chippen". Det er så rigtigt til en vis grad. Men oftest har man kun 1 process kørende på full load samtidigt, og denne vil man gerne have til at kunne dele sig i et antal tråde, således at den ene process kan udnytte alle X kerner.
Her kommer så problemet. Hvem gider (eller kan?) sidde og dele en engine af en art i X stykker med X forskellige klumper hukommelse, og definere en kommunikationsprotokol mellem trådene, og få det hele til at køre? Og hvordan gør man det effektivt, så X-1 kerner ikke står og venter på den sidste, da trådene ikke er perfekt balancerede? Og endnu vigtigere: Hvordan skal man dog teste sådan et system, når ukendte processer/tråde kan mase sig ind foran i køen og overtage et antal kerner?
Kerner egner sig bare bedst til at køre selvstændige programmer, og dem kører der sjældent 8 styks af på en alm hjemme-pc.
Jeg tror personligt, at man skulle tage et skridt tilbage og sige "ok vi bruger kun 4 kerner, da man oftes kun kører 4 programmer maks." og så tage et kik på, hvordan moderne kode kører.
I tunge engines benyttes ofte 99% af beregningstiden på 10% af koden. Der er nogle løkker, som itereres et enormt antal gange for at lave forskellige matematiske operationer. Det kan være vektor- eller matrice-beregninger. Kigger man nærmere på disse opgaver, så er de i sig selv ret parallele af natur. Vektorberegninger kan ofte foretages som atomiske operationer, bare ens processor er bred nok (vektorprocessor).
Gik man skridtet tilbage og byggede en processor med 3 traditionelle kerner og en vektorprocessor-kerne, der er i stand til at lave operationer på store sæt data, vil man kunne aflaste de tre andre kerner betydeligt. I stedet for at bruge 99% af tiden på at ligge og fise rundt i for-loops og miste så mange % af tiden i branching og branch-misses, vil man kunne foretage store stykker beregningsarbejde på rekordtid.
Desuden vil det ikke kræve nogen form for synkronisering eller kodning. Programmøren behøver ikke vide andet end at "Det er smart at begrænse vektorberegninger / matriceberegningerne til operationer á X gange Y sæt data, da dette er bredden af CPUen".
Skal ikke kunne tale for windows, men jeg ved da at linux understøtter rigtig mange kerner. Derfor er det ikke operativsystemet der er flaskehalsen, men de programmer der afvikles ovenpå.
Arh.. pokker tage min skrive-ivrighed, kan se jeg ikke er den første der har skrevet det her :)
Arh.. pokker tage min skrive-ivrighed, kan se jeg ikke er den første der har skrevet det her :)
Izaaq (18) skrev:Her kommer så problemet. Hvem gider (eller kan?) sidde og dele en engine af en art i X stykker med X forskellige klumper hukommelse, og definere en kommunikationsprotokol mellem trådene, og få det hele til at køre? Og hvordan gør man det effektivt, så X-1 kerner ikke står og venter på den sidste, da trådene ikke er perfekt balancerede? Og endnu vigtigere: Hvordan skal man dog teste sådan et system, når ukendte processer/tråde kan mase sig ind foran i køen og overtage et antal kerner?
Det må app programmørerne og compiler programmørerene jo se at finde ud af.
Nogen siger at vi skal lære Erlang !
Aarrrrh ............
Jeg tror jeg er blevet dummere af at laese denne nyhed samt traad.
uanset hvad saa er linux bedere end windows.
Jeg tror jeg er blevet dummere af at laese denne nyhed samt traad.
uanset hvad saa er linux bedere end windows.
Jeg tvivler på at hardwaren udvikler så således at den passer til måden der bliver kodet på. Hvis der udvikles hardware der gør det muligt at lave X antal beregninger så skal der nok være udviklere der benytter dette og derved kommer med et produkt der er hurtigere og bedre end alle andre.
De kommende styresystemer bliver bedre til at håndtere flere kerner og tråede og de kommende udviklingsværktøjer vil ligge op til fleretråede programmer. Årsagen til det er at teknologien og hardwaren er der i dag.
De kommende styresystemer bliver bedre til at håndtere flere kerner og tråede og de kommende udviklingsværktøjer vil ligge op til fleretråede programmer. Årsagen til det er at teknologien og hardwaren er der i dag.
Huskede du at spawne flere tråde? ;)spectual (17) skrev:
Mit lille program, som jeg lavede for ikke så længe siden, performede stort set ikke bedre på 4 kerner i forhold til 1 - og jeg kan ikke finde nogen forklaring på det andet end at min hukommelsesbåndbredde bliver max´et ud.
Må man høre lidt nærmere?
Der er ikke nogen løsning på problemet. Hvis en algoritme ikke kan deles op i flere parallele opgaver, så er det bare ærgeligt.
Det eneste der kan gøres, er at gøre det nemmere for udviklerne problemfrit at parallelisere opgaver hvor det faktisk er muligt.
Et eksempel på det kan ses i "parallel extensions" til .net som fås til .net 3.5 og som inkluderes i 4.0, se http://blogs.msdn.com/pfxteam/
Det eneste der kan gøres, er at gøre det nemmere for udviklerne problemfrit at parallelisere opgaver hvor det faktisk er muligt.
Et eksempel på det kan ses i "parallel extensions" til .net som fås til .net 3.5 og som inkluderes i 4.0, se http://blogs.msdn.com/pfxteam/
#26
Server programmer har længe kunnet udnytte 8, 16, 32, 64 kerner.
Med programmer som egner sig til massiv parallelisering (og det er der mange server programmer som gør), så kan du opnå næsten lineær forbedring af performance.
Men også kun næsten. Der er lidt overhead.
Server programmer har længe kunnet udnytte 8, 16, 32, 64 kerner.
Med programmer som egner sig til massiv parallelisering (og det er der mange server programmer som gør), så kan du opnå næsten lineær forbedring af performance.
Men også kun næsten. Der er lidt overhead.
Det kommer jo meget an på hvordan man skriver sine programmer. Nogle algoritmer kan man nemt parallelisere i så mange tråde som nu er passende for den pågældende maskine. Man kunne også parallelisere sit program i f.eks. 16 tråde, og så vil det udnytte alle kerner uanset om der er 4 eller 16 af dem. Nogle programmer bruger måske algoritmer, der ikke er nemme at parallelisere, og man opdeler måske i stedet programmet i forskellige opgaver (f.eks. kunne man forestille sig et spil hvor der bruges forskellige tråde til hhv. AI, fysiksimulering, og grafik rendering). Men så vil antallet af tråde nemt komme til at ligge ret fast, og man har ikke en jævn fordeling af arbejdet over trådene. Men så længe at den tungeste tråd kan køre med acceptabel hastighed på en enkelt CPU core, så er det ikke noget problem.RMJdk (3) skrev:Det er man skal programmere specielt til x antal kerne, er problemet imo. vi skal have en måde sådan at cpu'en selv kan dele tingene ud over de x antal kerne der måtte være, lidt ala sådan som et grafikkort gør det.
Jeg tror det vigtigste skridt for at forbedre situationen ville nok være, at OS skal være bedre til at håndtere programmer der starter mange tråde. I dag kan du nemt starte for mange, og systemet vil føles sløvt. Hvis nu OS kunne indrettes sådan, at et program uden videre kan starte 256 CPU-bundne tråde uden at det har negativ indvirkning på performance, så ville der nok blive skrevet flere multitrådede programmer. (Men bedre værktøjer vil selvfølgelig også hjælpe).
Det er faktisk rigtigt nok at de seneste 32 bits Intel CPUer kan bruge op til 64GB RAM. De 32 referere til størrelsen af et CPU register, ikke antallet af adresse pins. Der sker mange ting med adresserne på vej fra registre ud til busen. Jeg skal undlade at gå ind i samtlige detaljer og blot nævne den vigtigste i den her sammenhæng, nemlig page tabellen.Zhasha (11) skrev:Lige gyldigt hvor klog du er eller hvor meget du pager din memory så har en 32bit chip altså kun 32 address pins til din fysiske ram, så du kan ikke under nogen omstændigheder addresere mere end 4294967296 bytes (read 4GB) RAM. Jeg ville tage artiklen med et gran salt
På tidligere 32 bits CPU'er (386-Pentium) blev en 32 bits adresse delt op i to dele, de nederste 12 bits forblev uændret, de øverste 20 bits blev brugt som index ind i en tabel. Hver indgang i tabellen gav dig 20 nye bits og nogle forskellige flags. Den endelige adresse blev så udregnet ved at tage de 20 bits fra tabellen, og de 12 nederste bits fra den oprindelige tabel.
Hver indgang i tabellen var faktisk på 32 bits - 20 bits til adressen og så nogle flags. Nogle af bittene havde ikke noget formål, de var der kun fordi 32 bits var en praktisk størrelse. På et tidspunkt fandt Intel så på at udnytte 4 af dem til at gøre adresserne større, dette trick blev kaldt for PAE (page address extension). Når man bruger PAE bliver de 20 bits brugt til at slå op i tabellen og få 24 bits ud. Sammen med de 12 nederste bits fra den oprindelige adresse ender man altså med 36 bits.
Det betyder, at systemet kan have op til 64GB RAM. Men hvert program kan højst bruge 4GB RAM (minus en del reserveret til kernen).
Hvad skal vi med så mange kerner ?
Til normal forbrug er en 1-2-4 kerner mere end nok.
Spil kræver en hurtig processer, Selv om GPU tager de mere krævende opgaver.
Så heller få strøm forbruget og prisen ned på Processer.
Hvad skal en person der bruger sin computer til Mail, internet og Word samt nogle billeder. SÅ hurtig processer til?
Man har ikke kunne mærke forskel på at hastigheden på en CPU er blevet hurtigere. Da styresystemet bare tager flere resurse..
Til normal forbrug er en 1-2-4 kerner mere end nok.
Spil kræver en hurtig processer, Selv om GPU tager de mere krævende opgaver.
Så heller få strøm forbruget og prisen ned på Processer.
Hvad skal en person der bruger sin computer til Mail, internet og Word samt nogle billeder. SÅ hurtig processer til?
Man har ikke kunne mærke forskel på at hastigheden på en CPU er blevet hurtigere. Da styresystemet bare tager flere resurse..
#3 Nej, det er programmørerne der skal følge med udviklingen og lære at lave multitrådet kode.
AMD genåbnede jo for muligheden med at kunne sætte en coprocessor direkte til deres AMD64 processorer. Xilinx var de første der lavede en FPGA-chip med Hypertransport links.
18 skrev:Gik man skridtet tilbage og byggede en processor med 3 traditionelle kerner og en vektorprocessor-kerne, der er i stand til at lave operationer på store sæt data, vil man kunne aflaste de tre andre kerner betydeligt. I stedet for at bruge 99% af tiden på at ligge og fise rundt i for-loops og miste så mange % af tiden i branching og branch-misses, vil man kunne foretage store stykker beregningsarbejde på rekordtid.
AMD genåbnede jo for muligheden med at kunne sætte en coprocessor direkte til deres AMD64 processorer. Xilinx var de første der lavede en FPGA-chip med Hypertransport links.
kasperd (28) skrev:Men hvert program kan højst bruge 4GB RAM (minus en del reserveret til kernen).
Normal kode kan kun bruge 2 GB virtuelt address space til sig selv og dermed også maksimalt 2 GB RAM (eller 3 GB med /3GB switch), men hvis programmøren er villig til selv løbende at remappe de virtuelle addresser til fysisk memory, så kan det lade sig gøre for et enkelt program at bruge mere RAM.
Microsoft har da et labs projekt til .NET som gør det muligt at arbejde med flere kerner i C#.arne_v (21) skrev:Det må app programmørerne og compiler programmørerene jo se at finde ud af.
Nogen siger at vi skal lære Erlang !
http://en.wikipedia.org/wiki/Parallel_FX_Library
Det udnytte LINQ til at opnå en mere funktionel syntax.
Jeg er da ked af at høre at Linux ikke kan med mere end 4 kerner. Så er alle de 8 kerners MySQL servere jeg har pludseligt blevet ubrugelige selv om de gør arbejdet rigtigt godt...øv!
Jeg har endda en enkelt 16 kerners maskine, den klarer Linux også rigtigt fint, noget andet er MySQL der døjer med at skalere fornuftigt nok ud på den. Jeg har for en lille måneds tid siden også testet Linux på en SUN T5120, der har 8 kerner med 8 hardware tråde - betydende i praksis at den har 64 kerner. Det havde Linux absolut ingen problemer med, jeg lavede flere ting hvor jeg fik noget nær 100% load på den - dog med enkelttrådede processer...
Så at sige at Linux ikke kan klare ting over 4 kerner er helt forkert. Det handler om at mange applikationer, herunder f.eks. MySQL der falder i performance, i forhold til antallet af kerner, når man begynder at komme over 4. 8 klarer den rimeligt, 16 får man ikke meget mere ud af. Men det kan jo være det kommer i fremtiden :)
Jeg har endda en enkelt 16 kerners maskine, den klarer Linux også rigtigt fint, noget andet er MySQL der døjer med at skalere fornuftigt nok ud på den. Jeg har for en lille måneds tid siden også testet Linux på en SUN T5120, der har 8 kerner med 8 hardware tråde - betydende i praksis at den har 64 kerner. Det havde Linux absolut ingen problemer med, jeg lavede flere ting hvor jeg fik noget nær 100% load på den - dog med enkelttrådede processer...
Så at sige at Linux ikke kan klare ting over 4 kerner er helt forkert. Det handler om at mange applikationer, herunder f.eks. MySQL der falder i performance, i forhold til antallet af kerner, når man begynder at komme over 4. 8 klarer den rimeligt, 16 får man ikke meget mere ud af. Men det kan jo være det kommer i fremtiden :)
#24 skrev:Huskede du at spawne flere tråde? ;)
Må man høre lidt nærmere?
Det er en del af et program, som sørger for loading af en data fil.
Jeg lavede parallelisering på den måde, at jeg under loading starter 4 tråde op, som står og venter på en ManualResetEvent, mens jeg parser de indledende data i filen. Efter de indledende data er resten af filen gruppe opdelt og uafhængigt af resten, så det egner sig godt til parallelisering.
Grupperne fra filen smides i en processeringskø, som trådene begynder at æde fra. Den eneste synkronisering, der er behov for, er når de skal hente næste gruppe fra køen, så det er meget minimalt.
Hele loadingen tager ca. 1800 ms på min maskine med 1 kerne og ca. 1200 ms med 4 kerner.
Loadingen tager en fil på omkring 20 mb. og arrangerer det i dictionaries, som efter loadingen fylder ca. 400 mb i hukommelsen - på under 1.2 sekunder - måske ikke så usandsynligt at max båndbredde er nået.
Jeg har prøvet mange forskellige måder at lave I/O fra datafilen på uden at det resulterer i betydelige performance forskelle (MemoryStream og BinaryReader er temmelig hurtige, selvom de parser en Int32 éen byte af gangen).
Det er hvad der sker når man blindt tager ting fra slashdot ;-)
http://developers.slashdot.org/developers/09/03/22...
Også herinde klager folk over at kilden intet nævner om de påståede problemer med Windows eller Linux.
http://developers.slashdot.org/developers/09/03/22...
Også herinde klager folk over at kilden intet nævner om de påståede problemer med Windows eller Linux.
I anden kommentar, af Scott.andreasg (1) skrev:Hvor præcis nævner artiklen Windows og Linux?
"It isn't that hard - it is just hard for Linux and Windows."
Det er i hvert fald det eneste sted jeg lige så.
Personligt er jeg ikke bekymret - Hvis båndbredden bliver et problem, så kommer der jo nok en ny standard ganske snart, som afhjælper det også. Kun folk, der ønsker at have top-performance maskiner bliver ramt af det her problem.
Mit lille program, som jeg lavede for ikke så længe siden, performede stort set ikke bedre på 4 kerner i forhold til 1 - og jeg kan ikke finde nogen forklaring på det andet end at min hukommelsesbåndbredde bliver max´et ud. skrev:
Og du er 100% på at du selv udnytter alle dine kerner?
Der er meget snak om multitrådede programmer og jeg tror der hersker en hvis forvirring. At et program er multitrådet betyder ikke at OSet vil afvikle det på flere kerner. OSet vil typisk afvikle alle tråde påd en samme kerne.
Hvis man skal have et program til at køre multikerne, skal man selv lave ALT benarbejdet som det er nu. Jeg så for nyligt en demo af Microsofts Parallel Extensions til C# (af Anders Hejlsberg) og det ser ret lovende ud. Frameworket gør det muligt i C# at give OSet mulighed for at afvikle bestemte funktioner på evt. andre kerner end applikationen kører på. - Og det er enddda på rimeligt højt niveau.
Men det er så her at OSets begrænsninger bliver et problem.
#38 skrev:Og du er 100% på at du selv udnytter alle dine kerner?
Nej ikke 100%. Kan se alle 4 kerner få belastning.
#38 skrev:Der er meget snak om multitrådede programmer og jeg tror der hersker en hvis forvirring. At et program er multitrådet betyder ikke at OSet vil afvikle det på flere kerner. OSet vil typisk afvikle alle tråde påd en samme kerne.
Hvis du snakker windows er jeg ikke sikker på du har ret - netop pga at alle 4 kerner bliver belastet
#38 skrev:Hvis man skal have et program til at køre multikerne, skal man selv lave ALT benarbejdet som det er nu
Hvad består benarbejdet i?
#40 At du kan se i taskmanager at alle fire kerner bliver belastet er ikke ensbetydende med at de bliver belastet samtidig. Windows kernen (32bit) sørger så vidt muligt at belaste alle kerner lige, og jonglerer rundt med næsten alle programmer som den har lyst til. Dette sker flere gange i sekundet. Selv enkelttrådet programmer forbliver ikke på samme kerne hele tiden.
Windows kernen i XP64 er dog ikke så ivrig hvis NUMA er aktiveret.
Windows kernen i XP64 er dog ikke så ivrig hvis NUMA er aktiveret.
#42 Okay det lyder som om det er værd at sikre sig, at trådene kører på hver deres kerne.
Fandt dette her link som snakker om en SetThreadAffinityMask. Tilsyneladende kun noget, som kan nåes via et p/invoke kald (nasty løsning efter min mening).
Der skulle tilfældigvis ikke være nogen som ved om der er et alternativ?
Fandt dette her link som snakker om en SetThreadAffinityMask. Tilsyneladende kun noget, som kan nåes via et p/invoke kald (nasty løsning efter min mening).
Der skulle tilfældigvis ikke være nogen som ved om der er et alternativ?
spectual (43) skrev:#42 Okay det lyder som om det er værd at sikre sig, at trådene kører på hver deres kerne.
Nej, det ordner Windows selv.
Hvis jeg har én tråd, som tager al den CPU den kan få, trækker den 50% af mine to kerner.
Laver jeg to tråde, trækker de begge 50% på hver kerne.
Jeg har intet magi/benarbejde/whatever, bare to tråde som laver noget CPU-tungt. Så kommer det helt af sig selv.
Nogle gange er multi-threading nemt. ;-)
esbenr (38) skrev:Der er meget snak om multitrådede programmer og jeg tror der hersker en hvis forvirring. At et program er multitrådet betyder ikke at OSet vil afvikle det på flere kerner. OSet vil typisk afvikle alle tråde påd en samme kerne.
Hvis du bruger et styre system og version fra 1980'erne så ja.
Men nyere Windows, Linux, Unix etc. deler fint trådene ud på flere kerner som default.
Artiklen viser ikke lige hvorfor, men det jeg tror problemet består i er at det nogen gange er uhyggeligt kompliceret at implementere et effektiv multi-threaded model til et program.
Mange tror at tråde(threads) kører simultant, men de glemmer at tænke på at en enkel kerne kun kan bearbejde en instruktion ad gangen. Det der får det til at virke som om de kører simultant er "the process scheduler" eller hvad den nu hedder. Den finder den bedste/hurtigste rækkefølge at eksekvere instruktioner fra de forskellige programmer der kører.
Tit kan det virke som om at jo flere tråde dit program bruger, jo bedre, men det gælder ikke rigtigt hvis man kun tænker "processing power" - det virker meget tit sådan, fordi et program med mange tråde kan læse/skrive mange filer og/eller håndtere mange socket forbindelser ad gangen, men hvis man snakker ren processing power, så er det kun effektivt at have lige så mange tråde som du har af kerner.
Microsoft er blandt andet i gang med at løse problemet der hedder at programmøren er ofte lidt for langt nede i lortet med trådene. I stedet for at du skal starte tråde selv, og bestemme hvor mange, fortæller du i virkeligheden bare at du har nogen Tasks der skal gennemføres, og systemet finder ud af hvor mange tråde der skal bruges og så videre. Nå ja for søren - jeg snakker om .NET, btw. For dem der vil vide mere, google: PLINQ eller Parallel Linq.
Mange tror at tråde(threads) kører simultant, men de glemmer at tænke på at en enkel kerne kun kan bearbejde en instruktion ad gangen. Det der får det til at virke som om de kører simultant er "the process scheduler" eller hvad den nu hedder. Den finder den bedste/hurtigste rækkefølge at eksekvere instruktioner fra de forskellige programmer der kører.
Tit kan det virke som om at jo flere tråde dit program bruger, jo bedre, men det gælder ikke rigtigt hvis man kun tænker "processing power" - det virker meget tit sådan, fordi et program med mange tråde kan læse/skrive mange filer og/eller håndtere mange socket forbindelser ad gangen, men hvis man snakker ren processing power, så er det kun effektivt at have lige så mange tråde som du har af kerner.
Microsoft er blandt andet i gang med at løse problemet der hedder at programmøren er ofte lidt for langt nede i lortet med trådene. I stedet for at du skal starte tråde selv, og bestemme hvor mange, fortæller du i virkeligheden bare at du har nogen Tasks der skal gennemføres, og systemet finder ud af hvor mange tråde der skal bruges og så videre. Nå ja for søren - jeg snakker om .NET, btw. For dem der vil vide mere, google: PLINQ eller Parallel Linq.
#47 skrev:Artiklen viser ikke lige hvorfor, men det jeg tror problemet består i er at det nogen gange er uhyggeligt kompliceret at implementere et effektiv multi-threaded model til et program
Vel ikke uhyggeligt (dog mere) kompliceret men de fleste opgaver egner sig ikke til køre multitrådet - f.eks. hvis det ville resultere i for meget synkronisering
#47 skrev:Mange tror at tråde(threads) kører simultant, men de glemmer at tænke på at en enkel kerne kun kan bearbejde en instruktion ad gangen. Det der får det til at virke som om de kører simultant er "the process scheduler" eller hvad den nu hedder. Den finder den bedste/hurtigste rækkefølge at eksekvere instruktioner fra de forskellige programmer der kører.
Jamen for dit program, kører dine tråde faktisk simulatant hvis du holder dig lig eller under antal kerner.
Kode, der venter på meget på I/O er som udgangspunkt gode at køre i seperate tråde - uanset om man har 1 eller flere kerner.
Jeg tror ikke på et framework kan løse problemet på magisk vis. Hvis du skal lave et program, som udnytter flere kerner effektivt, skal du som programmør ned og rode med tråde.
Frameworket kan hjælpe med at parallelisere flere ting med mindre anstrengelser.
julu (14) skrev:ps. er OsX gud og døjer ikke med det her problem?
OsX er en ombygget BSD, dvs. en *nix og i samme familie som Linux. :-) Du døjer på den platform nøjagtig lige så meget med problemet, som alle andre paltforme.
Jep, multitrådet er vejen frem - det er sikkert og vist. Der er ofte dårligt skrevne programmer *host* windows *host* hvor maskinen kan føles som om den "låser" / hænger ved visse operationer, og et glimrende eksempel på hvorfor man bør multitråde sine applikationer.
Jo, det er til dels OS-betinget. Så længe den helt basale trådkontrol er tam, så bliver alt overliggende det selvfølgelig også. Der findes adskillige 3. parts programmer til at 'hjælpe' især Windows frem på dette område. Linux er på overfladen ikke så hårdt ramt - not true - hér kan man 'bare' få lov til at hjælpe med at skrive et fix, og skal ikke vente 10 år på ét, så det bliver indskrevet i OS'et næste gang der releases... :-) Og så er der det faktum at *nix folket havde de her problemer for 10 år siden, og derfor er noget foran i udviklingen, samt ikke er hæmmet af at være baseret på en enkelt-trådet DOS-arkitektur ;-)
<3 Open source :-)
Angående "Linux egner sig ikke til 8 kerner":
Linux 2.6.29 udkom den 23. marts med support for 4096 CPU'er. :P
http://kernelnewbies.org/LinuxChanges
Linux 2.6.29 udkom den 23. marts med support for 4096 CPU'er. :P
http://kernelnewbies.org/LinuxChanges
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