mboost-dp1
unknown
100 kerner - så begynder det at ligne noget. Det er rart at se de går i nye retninger efter MHz ræset er mere eller mindre overstået. Mere ydelse til brugeren =)
Gad vide om man kan køre conf. call med 1000 deltagere på Skype med en 100 kernet cpu ;)
/Zip
Gad vide om man kan køre conf. call med 1000 deltagere på Skype med en 100 kernet cpu ;)
/Zip
Det er alt sammen meget godt, men softwareleverandørerne skal også være med på vognen, ellers er det totalt spildt arbejde.
I øjeblikket er der ikke meget vundet ved at have en dual-core CPU hvis man arbejder med et windows-system (som ca. 85% af folk rundt om gør).
Jeg ved godt at Linux understøtter multi-core og at windows til en vis grad også gør det, men det har stadig ikke den store effekt hvis applikationerne ikke gør det.
I øjeblikket er der ikke meget vundet ved at have en dual-core CPU hvis man arbejder med et windows-system (som ca. 85% af folk rundt om gør).
Jeg ved godt at Linux understøtter multi-core og at windows til en vis grad også gør det, men det har stadig ikke den store effekt hvis applikationerne ikke gør det.
Vi vil jo nok se at windows vil begynde at falde af på den hvis de ikke begynder at benytte OpenSource stategien i deres software.
De vil kunne følge med hvis de åbner den del af deres system der er afgørende for om det kan håndterer flere CPU'er.
Hvis de vil sælge deres styresystem må de tilvejebringe muligheden for at flest mulige kan bruge det.
Hvis ikke det bliver åbnet tror jeg flere vil migrerer til Linux eller andre åbne systemer, hvor man vil kunne tilbyde software der kan kører på de nye former for hardware der kommer.
De vil kunne følge med hvis de åbner den del af deres system der er afgørende for om det kan håndterer flere CPU'er.
Hvis de vil sælge deres styresystem må de tilvejebringe muligheden for at flest mulige kan bruge det.
Hvis ikke det bliver åbnet tror jeg flere vil migrerer til Linux eller andre åbne systemer, hvor man vil kunne tilbyde software der kan kører på de nye former for hardware der kommer.
#3
Uden at komme ind på Linux vs. Ms, så tager du ganske fejl. Det er ikke nødvendigt for MS at åbne deres system for at kunne følge med, blot fordi der kommer flere cores i cpu'erne. Mon ikke MS godt kan følge med?
Det er ikke MS's ansvar at få applikationsudviklerne til at udvikle software, der udnytter multi-cure cpu'er.
Desuden, så har jeg lidt svært ved at diskutere sagligt med en der har sådan et link i sin signatur :>
Uden at komme ind på Linux vs. Ms, så tager du ganske fejl. Det er ikke nødvendigt for MS at åbne deres system for at kunne følge med, blot fordi der kommer flere cores i cpu'erne. Mon ikke MS godt kan følge med?
Det er ikke MS's ansvar at få applikationsudviklerne til at udvikle software, der udnytter multi-cure cpu'er.
Desuden, så har jeg lidt svært ved at diskutere sagligt med en der har sådan et link i sin signatur :>
Hvor mange kerne tillader Windows Vista?
Det er da ikke fedt, at have 100 kerner, hvis ens OS kun tillade at man bruger de to.
Det er da ikke fedt, at have 100 kerner, hvis ens OS kun tillade at man bruger de to.
-> #2 Fordelen er bl.a at man kan køre flere "single core" applikationer samtidigt uden at man mister responsivitet.
->#6 Det kommer an på hvilken version af Vista du har. Så vidt jeg ved så understøtter windows antal kerner baseret på antal sockets, dvs at de "mindre" udgaver af windows understøtter 1 socket med n antal kerner mens de "store" udgaver understøtter x antal sockets med n antal kerner.
Men der bliver da noget at holde styr på i windows task manager hvis der er hundrede kerner :P
->#6 Det kommer an på hvilken version af Vista du har. Så vidt jeg ved så understøtter windows antal kerner baseret på antal sockets, dvs at de "mindre" udgaver af windows understøtter 1 socket med n antal kerner mens de "store" udgaver understøtter x antal sockets med n antal kerner.
Men der bliver da noget at holde styr på i windows task manager hvis der er hundrede kerner :P
Tror ikke, at 100kerne processoren vil kunne bruges til andet end forskerprojekter lige med det samme. Der er simpelt hen for få opgaver i normale programmer, til at de kan deles op i 100 stykker. I hvert fald ikke ret nemt.
Nettop derfor var mhz ræset fedt i forhold til multicore, fordi det ikke kræver ændring i den nemme step by step kode form.
Nettop derfor var mhz ræset fedt i forhold til multicore, fordi det ikke kræver ændring i den nemme step by step kode form.
#11
Måske kan spil-markedet udnytte det.
Jeg kunne f.eks. forestille mig et RTS hvor hver eneste enhed har sin egen tråd. Jo flere kerner,des flere enheder kan håndteres på samme processortid.. Hvis udviklerne tænker sig lidt om, kunne jeg godt forestille mig at det kunne gøre underværker for spillenes AI-emulering.
Måske kan spil-markedet udnytte det.
Jeg kunne f.eks. forestille mig et RTS hvor hver eneste enhed har sin egen tråd. Jo flere kerner,des flere enheder kan håndteres på samme processortid.. Hvis udviklerne tænker sig lidt om, kunne jeg godt forestille mig at det kunne gøre underværker for spillenes AI-emulering.
OK, der går "lang" tid inden vi får 100 kerner, men der skal da en hele anden tankegang til, for at udnytte 100 kerner. Selv når jeg har mange applikationer i gang på en gang, kommer jeg ikke i nærheden af 50 tråde. Så fremtidens OS skal kunne udnytte flere kerner til samme tråd. Findes der i dag et OS, der kan det?
#13
Jeg tvivler voldsomt på at der findes en scheduler der kan det.
Bliver der lavet en sådan scheduler, så skulle det være nogenlunde nemt for folk at opgradere, da det oftest ikke kræver størere ændringer udenfor kernen, at få det til at virke.
Det er dog, naturligvis, et desingspørgamål. Er der f.eks. tale om et singlethread OS, så er det langtfra sikkert at det kan gøres uden størere ændringer i resten af OS'et.
Så fremtidens OS skal kunne udnytte flere kerner til samme tråd. Findes der i dag et OS, der kan det?
Jeg tvivler voldsomt på at der findes en scheduler der kan det.
Bliver der lavet en sådan scheduler, så skulle det være nogenlunde nemt for folk at opgradere, da det oftest ikke kræver størere ændringer udenfor kernen, at få det til at virke.
Det er dog, naturligvis, et desingspørgamål. Er der f.eks. tale om et singlethread OS, så er det langtfra sikkert at det kan gøres uden størere ændringer i resten af OS'et.
#12
Spil-markedet???
Du tager gas på os, ikke? De har problemer nok med to kerner, så forestil dig at de skal lære at bruge 100!!!
Spil-markedet???
Du tager gas på os, ikke? De har problemer nok med to kerner, så forestil dig at de skal lære at bruge 100!!!
#15
CELL processoren har 9 kerner udelukkende til spil markedet, så måske 100 kerner er muligt(!)
Men jeg giver dig helt ret - det lader til der går længe før de lære at bruge bare CELL chippen med dens kerner, så hvis den havde 100 ville det nok bare tage længere tid :(
CELL processoren har 9 kerner udelukkende til spil markedet, så måske 100 kerner er muligt(!)
Men jeg giver dig helt ret - det lader til der går længe før de lære at bruge bare CELL chippen med dens kerner, så hvis den havde 100 ville det nok bare tage længere tid :(
#16 - skridtet fra at bruge 9 kerner til at bruge 100 er ikke så stort; Når de først har fundet metoden til at udnytte flere kerner på samme tid så er det ikke "det store problem" at udvide det til at være 100 kerner eller endda 1000 kerner.
Problemet er at udviklere ikke har været vant til at skulle skrive programmer/spil til flere kerner og de derfor skal finde den rigtige måde at gøre det på.
Problemet er at udviklere ikke har været vant til at skulle skrive programmer/spil til flere kerner og de derfor skal finde den rigtige måde at gøre det på.
#19
Intel satser på at forbedre deres "Ydelse per watt". Som en anden nyhed i dag nævner, så kommer Intel også ud med en CPU der har 40% mindre energiforbrug og 40% højere ydelse.
Så vidt jeg ved, så har Intel i sinde at fortsætte denne strategi i sine fremtidige processorer, indtil spørgsmålet om ydelse per watt bliver irrelevant.
Og så er resten nemt at regne ud.
Færre watt == mindre varme.
Intel satser på at forbedre deres "Ydelse per watt". Som en anden nyhed i dag nævner, så kommer Intel også ud med en CPU der har 40% mindre energiforbrug og 40% højere ydelse.
Så vidt jeg ved, så har Intel i sinde at fortsætte denne strategi i sine fremtidige processorer, indtil spørgsmålet om ydelse per watt bliver irrelevant.
Og så er resten nemt at regne ud.
Færre watt == mindre varme.
Problemet er ret komplekst meget af det man foretager sig på en computer er linært i sin natur og man kan ikke bare køre det parallelt. tag f.eks. 1 * 3 + 4 du kan ikke bare dele det over på midten og sende hhv. 1 * 3 og 3 + 4 igennem hver sin kerne - man er alt andet lige nødt til at udføre regnestykket i to på hinanden følgende udregninger.
Det er klart at der findes opgaver der kan deles ud på mange kerner/processorer, og nogle er lette at fordele og andre svære, men en stor del af de opgaver man har behov for at løse kan ikke paralleliseres hvorend man gerne ville og den slags opgaver vil aldrig drage nytte af flere kerner uanset hvor mange fantastiske forbedringer der laves i compilerne.
Dertil kommer at en parallelisering af opgaver meget let kan føre voldsomt overhead med sig og i realiteten betyde at de bliver meget langsommere for små mængder data. Det kunne gå så vidt at man ville få situationer med O(n/2) for datamængder under 10 mio enheder.
Noget af det overhead kunne muligvis løses ved nogle meget avancerede scheduleringsrutiner, men det i sig selv kunne åbne helt nye problemer.
Det er klart at der kan være performance at hente i et vist omfang i mange forskellige sammenhænge, men det er ikke noget man bare lige gør på 5 minuter, og det er ingenlunde en linær funktion af antal kerner.
Jeg har på det sidste designet et omfattende serversystem der er bygget til at kunne skalere op til meget store antal brugere med meget store datamængder, prisen for det er at minimum konfigurationen er 10 servere, hvis ikke systemet skal drukne i sit eget overhead, men så kan det også skaleres opad næsten ubegrænset.
Det sagt så var det en relativt let opgave fordi belastningen består af en lang række opgaver der er uafhængige af hinanden - det står i stærk kontrast til f.eks. spil hvor måske 95% af belastningen består i håndtering af grafikken - og omend det uden tvivl er muligt at dele disse beregning ud i et eller andet omfang så er det på ingen måde let og det er meget usansynligt at det kan deles op i ret mange stykker før det overhead der skabes af den nødvendige kommunikation imellem de forskellige dele bliver en større belastning end selve udregningen.
Tag f.eks. en simpel antialiasering kan jo ikke bare udføres på 16 individuelle firkanter da man så vil få problemer omkring kanten af firkanterne, man kan selvfølgelig lave alle firkanterne lidt større end den del man har tænkt sig at bruge, men det sætter jo en naturlig begrænsning på antallet af firkanter, ligeledes vil det betyde at man skal til at låse forskellige dele mens de enkelte arbejde med dem og dermed geninfører man en vis mængde linearitet.
Det er ikke for sjov at man har valgt at bygge dedikerede chips (GPU'er) til at lave disse beregninger - der er langt mere at hente i perfomance per transistor ved at lave dedikerede chips end ved at lave opsplitning i deludregninger på generiske CPU'er.
Det er klart at der findes opgaver der kan deles ud på mange kerner/processorer, og nogle er lette at fordele og andre svære, men en stor del af de opgaver man har behov for at løse kan ikke paralleliseres hvorend man gerne ville og den slags opgaver vil aldrig drage nytte af flere kerner uanset hvor mange fantastiske forbedringer der laves i compilerne.
Dertil kommer at en parallelisering af opgaver meget let kan føre voldsomt overhead med sig og i realiteten betyde at de bliver meget langsommere for små mængder data. Det kunne gå så vidt at man ville få situationer med O(n/2) for datamængder under 10 mio enheder.
Noget af det overhead kunne muligvis løses ved nogle meget avancerede scheduleringsrutiner, men det i sig selv kunne åbne helt nye problemer.
Det er klart at der kan være performance at hente i et vist omfang i mange forskellige sammenhænge, men det er ikke noget man bare lige gør på 5 minuter, og det er ingenlunde en linær funktion af antal kerner.
Jeg har på det sidste designet et omfattende serversystem der er bygget til at kunne skalere op til meget store antal brugere med meget store datamængder, prisen for det er at minimum konfigurationen er 10 servere, hvis ikke systemet skal drukne i sit eget overhead, men så kan det også skaleres opad næsten ubegrænset.
Det sagt så var det en relativt let opgave fordi belastningen består af en lang række opgaver der er uafhængige af hinanden - det står i stærk kontrast til f.eks. spil hvor måske 95% af belastningen består i håndtering af grafikken - og omend det uden tvivl er muligt at dele disse beregning ud i et eller andet omfang så er det på ingen måde let og det er meget usansynligt at det kan deles op i ret mange stykker før det overhead der skabes af den nødvendige kommunikation imellem de forskellige dele bliver en større belastning end selve udregningen.
Tag f.eks. en simpel antialiasering kan jo ikke bare udføres på 16 individuelle firkanter da man så vil få problemer omkring kanten af firkanterne, man kan selvfølgelig lave alle firkanterne lidt større end den del man har tænkt sig at bruge, men det sætter jo en naturlig begrænsning på antallet af firkanter, ligeledes vil det betyde at man skal til at låse forskellige dele mens de enkelte arbejde med dem og dermed geninfører man en vis mængde linearitet.
Det er ikke for sjov at man har valgt at bygge dedikerede chips (GPU'er) til at lave disse beregninger - der er langt mere at hente i perfomance per transistor ved at lave dedikerede chips end ved at lave opsplitning i deludregninger på generiske CPU'er.
Man kan nu godt dele dit eksempel op, så den ene tråd udfører 1*3 og den anden *result* + 4. Om der så er menning i dette.. tja.. ;)
Det er ikke engang parallet, men man bruger da flere kerner på den måde :)
Det er ikke engang parallet, men man bruger da flere kerner på den måde :)
#23
du kan også dele det op i 25 tråde hvis du vil, men opgaven er lineær og du er nødt til at vente på result før du kan lave udregning nr 2 så det hjælper ingenting og du kan sagtens bruge 2 kerner på udregningen uden at have tråde, du skal bare have OS'et til at preempte opgaven midtvejs og hvis du så har 100 kerner er sansynligheden for at den lander på den samme kerne til resten af udførelse ca. 1%... Og selv hvis du bruger to tråde er der ingen garanti for at den rent faktisk bliver kørt på forskellige kerner, tråd to vil være i suspended state indtil tråd 1 er færdig og så kunne den snildt lande på den samme kerne til udregningen i tråd 2.
Men det er lidt besides the point, som er at der er opgaver der ikke kan løses i parallel og så er det lidt ligemeget hvor mange tråde man deler den op i - det går heller ikke hurtigere at sende et brev fra København til Aalborg fordi der er mange postbude, det er underordnet om det er det samme postbud der foretager alle opgaver i processen eller der er et postbud til hver opgave - det kan trods alt ikke bringes ud af posten i Aalborg før lastbilen fra Kæøbenhavn har leveret det til posthuset i Aalborg. Til gengæld går det meget hurtigere at levere 100.000 breve med mange postbude end det gør med et postbud der skal frem og tiblage for hvert enkelt brev.
du kan også dele det op i 25 tråde hvis du vil, men opgaven er lineær og du er nødt til at vente på result før du kan lave udregning nr 2 så det hjælper ingenting og du kan sagtens bruge 2 kerner på udregningen uden at have tråde, du skal bare have OS'et til at preempte opgaven midtvejs og hvis du så har 100 kerner er sansynligheden for at den lander på den samme kerne til resten af udførelse ca. 1%... Og selv hvis du bruger to tråde er der ingen garanti for at den rent faktisk bliver kørt på forskellige kerner, tråd to vil være i suspended state indtil tråd 1 er færdig og så kunne den snildt lande på den samme kerne til udregningen i tråd 2.
Men det er lidt besides the point, som er at der er opgaver der ikke kan løses i parallel og så er det lidt ligemeget hvor mange tråde man deler den op i - det går heller ikke hurtigere at sende et brev fra København til Aalborg fordi der er mange postbude, det er underordnet om det er det samme postbud der foretager alle opgaver i processen eller der er et postbud til hver opgave - det kan trods alt ikke bringes ud af posten i Aalborg før lastbilen fra Kæøbenhavn har leveret det til posthuset i Aalborg. Til gengæld går det meget hurtigere at levere 100.000 breve med mange postbude end det gør med et postbud der skal frem og tiblage for hvert enkelt brev.
#25
opdelingerne vil være præcis lige så meningsgivende som opdelingen i to tråde og vil i bedste fald tage præcis samme tid som en tråd.
man kunne f.eks. splitte regnestykket op i udregninger på dele af integers sige 1*3 kunne blive til et helt bjerg af regnestykker baseret på 4 bit størelser eller mindre det samme med + 4 regnestykket - det kan deles op i næsten lige så mange dele du måtte have lyst til men der er absolut intet at hente ved at bevæge sig højere end 1 tråd.
Der er heller ingen mangel på vanvittige udregninger f.eks. kunne man tage hver eneste mulige værdi af en integer dele den med 3 og checke om det giver 1 i hvilket fald det var den rigtige værdi der skal arbejdes vidre med... i så fald kan vi lave over 4 mia tråde til at lave udregningen med.
Det er ikke spor svært at dele hvad som helst op i præcis lige så mange tråde du har lyst til, til gengæld er det langt fra altid muligt at opnå en positiv effekt, og meget ofte vil der vise sig at være et antal tråde/processor der er optimalt; hvor en forøgelse vil medføre mere overhead end gevinst.
opdelingerne vil være præcis lige så meningsgivende som opdelingen i to tråde og vil i bedste fald tage præcis samme tid som en tråd.
man kunne f.eks. splitte regnestykket op i udregninger på dele af integers sige 1*3 kunne blive til et helt bjerg af regnestykker baseret på 4 bit størelser eller mindre det samme med + 4 regnestykket - det kan deles op i næsten lige så mange dele du måtte have lyst til men der er absolut intet at hente ved at bevæge sig højere end 1 tråd.
Der er heller ingen mangel på vanvittige udregninger f.eks. kunne man tage hver eneste mulige værdi af en integer dele den med 3 og checke om det giver 1 i hvilket fald det var den rigtige værdi der skal arbejdes vidre med... i så fald kan vi lave over 4 mia tråde til at lave udregningen med.
Det er ikke spor svært at dele hvad som helst op i præcis lige så mange tråde du har lyst til, til gengæld er det langt fra altid muligt at opnå en positiv effekt, og meget ofte vil der vise sig at være et antal tråde/processor der er optimalt; hvor en forøgelse vil medføre mere overhead end gevinst.
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