mboost-dp1
unknown
klasse,,,, så kan man få 2 stk dual-kerne cpu´s til at spille som et four-way system på en ganske standard XP-pro boks.
Så skal der bare skrives noget mere SW som udnytter multi-threading.
Ovenstående, krydret med lidt SLI, skulle osse kunne tilfredsstille de kræsne (rige) gamere.
MS all the way.
// Hollow
Så skal der bare skrives noget mere SW som udnytter multi-threading.
Ovenstående, krydret med lidt SLI, skulle osse kunne tilfredsstille de kræsne (rige) gamere.
MS all the way.
// Hollow
#5 - der er stort set ingen applikationer der er skrevet multitraadet. du skal vaere velkommen til at naevne nogle. at ht koerer et program i een traad og et andet program i een anden traad, goer dem ikke multitraadet.
noget andet de burde blive enige om, er cpu'er/kerner i servere. hvor ibm regner per kerne, bruger sun feks per cpu.
/stone
noget andet de burde blive enige om, er cpu'er/kerner i servere. hvor ibm regner per kerne, bruger sun feks per cpu.
/stone
#6 De fleste større programmer og næsten samtlige spil bruger flere tråde. Spillene overskrider desværre ikke mere end ydeevnen af en CPU selvom der er flere tilrådighed. Source bruger omkring 40% af den ene CPU og omkring 60% af den anden. Nogenlunde det samme gør Doom3.
Var det egentligt Quake 2 eller 3 der understøttede SMP?
Var det egentligt Quake 2 eller 3 der understøttede SMP?
#10: Er det så ikke bare Windows der fordeler regnekraften på de to CPU'er? Det kan den jo sagtens gøre med et enkelttrådet program.
#12 lyder rigtigt.
Men jeg syntes nu nærmere det må være en fejl i stedet for en feature. Hvis der er tale om at den samme enkelte process(spillet) står og skifter mellem 2 CPUer kan det da ikke andet end give performance nedgang.
Normalt plejer man da at gå efter højrere "stickyness" så en process ikke hopper rundt mellem flere CPUere. Det betyder ikke så meget hvis ens multi-cpu maskine kun har en memory controller. Så er det vel "kun" diverse stacks der PUSHes og POPpes oftere. Men hvis ens maskine har flere memory controllere, vil det være katastrofalt for ens performance. Men det er der nok ikke nogle hjemme PCere der har.
Men jeg syntes nu nærmere det må være en fejl i stedet for en feature. Hvis der er tale om at den samme enkelte process(spillet) står og skifter mellem 2 CPUer kan det da ikke andet end give performance nedgang.
Normalt plejer man da at gå efter højrere "stickyness" så en process ikke hopper rundt mellem flere CPUere. Det betyder ikke så meget hvis ens multi-cpu maskine kun har en memory controller. Så er det vel "kun" diverse stacks der PUSHes og POPpes oftere. Men hvis ens maskine har flere memory controllere, vil det være katastrofalt for ens performance. Men det er der nok ikke nogle hjemme PCere der har.
#3: Jo, det kan du da godt have ret i, men nu er det nu engang sådan de har valgt at gøre og det gælder iøvrigt også mange andre da antal cpu'er er en ret god indikator for hvad maskinen anvendes til.
Hvis de ikke havde valgt denne beslutning, så ville de på sigt få en opdeling hvor deres klient versioner ikke ville være kompatibel med det hardware som kommer til at sidde i workstations/klienter fremover.
Derfor må det siges at være den rette løsning.
Hvis de ikke havde valgt denne beslutning, så ville de på sigt få en opdeling hvor deres klient versioner ikke ville være kompatibel med det hardware som kommer til at sidde i workstations/klienter fremover.
Derfor må det siges at være den rette løsning.
#12 Jeg tvivler på at man får andet end svie og smerte ud af at dele en tråd op mellem to CPU'er on-the-fly. Windows gør det ikke. Jeg tvivler på at der er nogen OS'er der gør det.
#13 De er multitrådet ellers ville windows ikke kunne fordele arbejdet på to CPU'er. Og af hvad jeg har erfaret er det ganske normalt at dele spillet op i mindst to tråde. En til grafik og en til lyd.
Hvis de kan skalere arbejdet til ikke at bruge mere end hvad en CPU kan klare så burde det være en smal sag at skalere det til det antal af CPU'er der er i systemet.
#13 De er multitrådet ellers ville windows ikke kunne fordele arbejdet på to CPU'er. Og af hvad jeg har erfaret er det ganske normalt at dele spillet op i mindst to tråde. En til grafik og en til lyd.
Hvis de kan skalere arbejdet til ikke at bruge mere end hvad en CPU kan klare så burde det være en smal sag at skalere det til det antal af CPU'er der er i systemet.
#5,Du har ret i at de fleste programmer kører multi-threaded, men det er ikke ens betydende med at de er optimeret til flere CPU'er (virtuelle eller fysiske)
Normalt når man bruger multi-threading så lægger man en hel arbejdsopgave ud til en seperat tråd mens man foretager sig noget andet. I windows så er der normalt en tråd i programmet til at dispatche event (button clicks,dropdown selections osv) til "programmet", og for ikke at forhindre redraws mv. så sætter man tråde igang for at håndtere længervarende opgaver igang, f.eks. kontakte servere.
I en tekstbehandlings program kunne stavekontrollen f.eks. køre som en seperat tråd i baggrunden for at brugeren forsat kan arbejde.
Hvis et program derimod er optimeret til flere CPU'er så går de videre end det. De deler arbejdsopgaven op så den kan paraleliseres. I tekstbehandlings eksemplet kunne det være at stave kontrollen kørte i 2 tråde som hver to halvdelen af dokumentet. Eksemplet er trivielt, men kan snildt overføres til f.eks. 3D tegne programmer.
En anden fordel som mange glemmer ved flere CPU'er er at systemerne som regel er mere glatte. I almindelige computere så kan et program der tager det meste af CPU'en blokere for andre programmer, men i et dual core system vil "desktoppen" stadig svare i den anden "cpu"
Normalt når man bruger multi-threading så lægger man en hel arbejdsopgave ud til en seperat tråd mens man foretager sig noget andet. I windows så er der normalt en tråd i programmet til at dispatche event (button clicks,dropdown selections osv) til "programmet", og for ikke at forhindre redraws mv. så sætter man tråde igang for at håndtere længervarende opgaver igang, f.eks. kontakte servere.
I en tekstbehandlings program kunne stavekontrollen f.eks. køre som en seperat tråd i baggrunden for at brugeren forsat kan arbejde.
Hvis et program derimod er optimeret til flere CPU'er så går de videre end det. De deler arbejdsopgaven op så den kan paraleliseres. I tekstbehandlings eksemplet kunne det være at stave kontrollen kørte i 2 tråde som hver to halvdelen af dokumentet. Eksemplet er trivielt, men kan snildt overføres til f.eks. 3D tegne programmer.
En anden fordel som mange glemmer ved flere CPU'er er at systemerne som regel er mere glatte. I almindelige computere så kan et program der tager det meste af CPU'en blokere for andre programmer, men i et dual core system vil "desktoppen" stadig svare i den anden "cpu"
#20 - at en windows applikation ikke blokere for events, betyder ikke at programmet er skrevet til at vaere, eller udnytte multitreading.
- et spil der bruger forskellige api'er er stadig ikke skrevet multitraadet.
- fordi java udnytter traade, goer ikke at java applikationen er kodet multitraadet, med mindre den benytter javas thread api.
/stone
- et spil der bruger forskellige api'er er stadig ikke skrevet multitraadet.
- fordi java udnytter traade, goer ikke at java applikationen er kodet multitraadet, med mindre den benytter javas thread api.
/stone
#21,
Korrekt det er ingen garanti at den er multitrådet, men det er ofte tilfældet hvis det skal ske være en bare basale ting når man arbejder med programmet.
Spil: Jeg snakkede ikke om API'er så....
Java: Så snart du har et GUI i din java application så har du 2 tråde, nemlig "main" tråden som din main metode kører i og Event dispatch Tråden som bliver brugt af JVM'en til at sende events til programmet.
Man kan så vælge om man vil benytte yderligere tråde til at foretage tunge arbejdsopgaver.
Korrekt det er ingen garanti at den er multitrådet, men det er ofte tilfældet hvis det skal ske være en bare basale ting når man arbejder med programmet.
Spil: Jeg snakkede ikke om API'er så....
Java: Så snart du har et GUI i din java application så har du 2 tråde, nemlig "main" tråden som din main metode kører i og Event dispatch Tråden som bliver brugt af JVM'en til at sende events til programmet.
Man kan så vælge om man vil benytte yderligere tråde til at foretage tunge arbejdsopgaver.
#22 - at der benyttes traade i et preemptive multitasking os, er ikke just en overraskelse. men det er stadig _ikke_ det samme som at applikationen er skrevet multraadet, og udnytter dette.
det er meget faa spil, hvor det giver mening at skrive den multitraadet. specielt en 3d api er svaer at balancere, da render kaldet ofte vejer meget tungt, og noedvendigvis maa vaere een traad. et eksempel paa en anden traad, kunne saa vaere gamelogic og ai.
det er korrekt at office benytter multithreading til at printe i baggrunden feks. saa selvom det er i lille grad, kan du godt kalde den multitraadet.
med mindre programmoerene har sat sig ned, og udnytter traade, er den givne applikation _ikke_ skrevet multitraadet, selvom os'et naturligvis goer brug af det.
/stone
det er meget faa spil, hvor det giver mening at skrive den multitraadet. specielt en 3d api er svaer at balancere, da render kaldet ofte vejer meget tungt, og noedvendigvis maa vaere een traad. et eksempel paa en anden traad, kunne saa vaere gamelogic og ai.
det er korrekt at office benytter multithreading til at printe i baggrunden feks. saa selvom det er i lille grad, kan du godt kalde den multitraadet.
med mindre programmoerene har sat sig ned, og udnytter traade, er den givne applikation _ikke_ skrevet multitraadet, selvom os'et naturligvis goer brug af det.
/stone
@21 Øh, nu begynder jeg at blive interesseret i din definition af "flertrådethed". Hvis det ikke gælds, hvis man udfører længerevarende, asynkrone opgaver i en kortvarig arbejdstråd, hvad så?
Skal der være data-domain decomposition (1 opgave fordelt nogenlunde ligeligt mellem flere CPUer) førend det rigtigt gælder? I det tilfælde så er det nok kun enkelte video encodere og 3dcgi applikationer (ikke rasterizere), som er rigtigt flertrådede.
For sjov skyld, så kan man slå Thread Count til i Task manager's process view. Ok, notepad får et 1-tal, men Office produkterne har 5-6 tråde hver. Det meste af tiden er trådene inaktive, men somme tider vil flere tråde være aktive samtidigt. Intel har holdt nogle demoer, hvor de faktisk brugte PowerPoint til at vise hvor meget HT kan hjælpe. :P Selv spil kan være flertrådede, men typisk så klarer de sekundære tråde kun ting som data-loading og lignende.
Skal der være data-domain decomposition (1 opgave fordelt nogenlunde ligeligt mellem flere CPUer) førend det rigtigt gælder? I det tilfælde så er det nok kun enkelte video encodere og 3dcgi applikationer (ikke rasterizere), som er rigtigt flertrådede.
For sjov skyld, så kan man slå Thread Count til i Task manager's process view. Ok, notepad får et 1-tal, men Office produkterne har 5-6 tråde hver. Det meste af tiden er trådene inaktive, men somme tider vil flere tråde være aktive samtidigt. Intel har holdt nogle demoer, hvor de faktisk brugte PowerPoint til at vise hvor meget HT kan hjælpe. :P Selv spil kan være flertrådede, men typisk så klarer de sekundære tråde kun ting som data-loading og lignende.
@25: Jo, det har noget med definition at gøre. Næsten alt jeg har programmeret benytter threads i større eller mindre omfang, men jeg tvivler lidt på at du betragter f.eks. mindre netværks opgaver udført i en sekundær tråd som rigtig flertrådethed.
Personligt, så synes jeg at det er decideret vrøvl at sige "der er stort set ingen applikationer der er skrevet multitraadet", iogmed at flertallet af alle applikationer benytter sekundære arbejdstråde.
Iøvrigt, så laver Office produkterne meget andet end at "printe i baggrunden". Stavekontrol, on-demand-loading, o.lign. er meget mere betydende.
Vedrørende spil, så er der flere muligheder end blot funktionel dekomposition (som dine eksempler), f.eks. benytter Colin McRae rally data-domain dekomp for at lave bedre regnvejrseffekter og Havok (fysik engine) vil i fremtiden også kunne parallellisere dens beregninger. Desuden er det nok også mere almindeligt at placere on-demand-loading og netværksaktiviteter i sekundære tråde.
Personligt, så synes jeg at det er decideret vrøvl at sige "der er stort set ingen applikationer der er skrevet multitraadet", iogmed at flertallet af alle applikationer benytter sekundære arbejdstråde.
Iøvrigt, så laver Office produkterne meget andet end at "printe i baggrunden". Stavekontrol, on-demand-loading, o.lign. er meget mere betydende.
Vedrørende spil, så er der flere muligheder end blot funktionel dekomposition (som dine eksempler), f.eks. benytter Colin McRae rally data-domain dekomp for at lave bedre regnvejrseffekter og Havok (fysik engine) vil i fremtiden også kunne parallellisere dens beregninger. Desuden er det nok også mere almindeligt at placere on-demand-loading og netværksaktiviteter i sekundære tråde.
#26 - det virker som forskellige indgangsvinkler til emnet. det jeg bekymre mig om, er at udnytte smp, flere cores eller flere cpu'er i et system. at word bruger traade saa man kan skrive videre mens man gemmer, betyder ikke at word koere mere effektivt paa et smp system, da det ikke er skrevet til at udnytte det effektivt.
nu er word interessant vedr. multithreading da det er traels ikke at kunne arbejde mens man printer, men i smp sammenhaenge er det ligegyldigt, da de ikke har saa meget at vinde paa performance.
hvis du i dag afvikler et vilkaarligt spil paa et smp system opnaar du kun faa procent forbedringer, fordi de ikke er skrevet til at udnytte smp.
hvis vi skulle skrive vores 3d engine multitraadet, ville det vaere en anden struktur der skulle til for at udnytte mulighederne. det er der ganske enkelt stort set ingen applikationer der udnytter i dag, hvad enten de bruger traade eller ej.
saa da emnet er multikerne cpu'er, beskaeftigeere jeg med at skrive om software der er skrevet til at udnytte smp. ikke om der benyttes traade.
/stone
nu er word interessant vedr. multithreading da det er traels ikke at kunne arbejde mens man printer, men i smp sammenhaenge er det ligegyldigt, da de ikke har saa meget at vinde paa performance.
hvis du i dag afvikler et vilkaarligt spil paa et smp system opnaar du kun faa procent forbedringer, fordi de ikke er skrevet til at udnytte smp.
hvis vi skulle skrive vores 3d engine multitraadet, ville det vaere en anden struktur der skulle til for at udnytte mulighederne. det er der ganske enkelt stort set ingen applikationer der udnytter i dag, hvad enten de bruger traade eller ej.
saa da emnet er multikerne cpu'er, beskaeftigeere jeg med at skrive om software der er skrevet til at udnytte smp. ikke om der benyttes traade.
/stone
Jamen jamen. Fyr en kæmpe PowerPoint præsentation ind på en computer med 1/2 CPUer og bladr lidt rundt i den. Så skal du nok se en forskel.
Om du synes at det er ligegyldigt eller ej, det har for søren da ingen betydning for om applikationen er flertrådet eller ej. Faktum er at et overtal af applikationer er flertrådede, og dermed kan drage nytte af multi-processor systemer.
Ok, et par andre ting. Det var _dig_ som begyndte med flertrådethet, så ny skal du ikke prøve at lægge røgslør ud ("beskæftiger mig ikke med om der benyttes tråde bla bla"). Tråde er det programmeringsparadigme som oftest benyttes til at udnytte smp, og det er dermed en integral del af dette emne. Til sidst, Word kører altså hurtigere på et ht/smp system. Det er muligvis ikke en applikation, som er specielt egnet til at udnytte smp i høj grad, og det er muligt at Word ikke udnytter smp til det teoretiske maximum, men det ændrer stadig ikke det faktum at Word til tider kan benytte flere CPUer, og kan gøre dette med højere effektivitet til følge.
Så please, stop nu det her "der er stort set ingen applikationer der er skrevet multitraadet".
Om du synes at det er ligegyldigt eller ej, det har for søren da ingen betydning for om applikationen er flertrådet eller ej. Faktum er at et overtal af applikationer er flertrådede, og dermed kan drage nytte af multi-processor systemer.
Ok, et par andre ting. Det var _dig_ som begyndte med flertrådethet, så ny skal du ikke prøve at lægge røgslør ud ("beskæftiger mig ikke med om der benyttes tråde bla bla"). Tråde er det programmeringsparadigme som oftest benyttes til at udnytte smp, og det er dermed en integral del af dette emne. Til sidst, Word kører altså hurtigere på et ht/smp system. Det er muligvis ikke en applikation, som er specielt egnet til at udnytte smp i høj grad, og det er muligt at Word ikke udnytter smp til det teoretiske maximum, men det ændrer stadig ikke det faktum at Word til tider kan benytte flere CPUer, og kan gøre dette med højere effektivitet til følge.
Så please, stop nu det her "der er stort set ingen applikationer der er skrevet multitraadet".
#28 - der er vist ingen grund til at forsaette diskutionen, naar du paa trods af mine forsoeg paa at forklare dig sammenhaengen, insistere paa at laese det forkert, og samtidig ikke magter at snakke ordenligt til folk.
"der er stort set ingen applikationer der er skrevet multitraadet" kan misforstaaes, men ikke hvis du holde dig til traadens emne og mine uddybende posts.
hvis en applikation ikke er skrevet multitraadet for at udnytte smp, faar du kun en fraktion af den gevinst en applikation skrevet til at smp kan opnaa.
altsaa holder min paastand ganske glimrende; der meget faa applikationer der er skrevet decideret multitraadet for at udnytte smp.
du kan maaske vaere ligeglad, men hvis man arbejder i branchen, eller naar dualcore cpu'er vinder frem, er det et reelt problem.
/stone
"der er stort set ingen applikationer der er skrevet multitraadet" kan misforstaaes, men ikke hvis du holde dig til traadens emne og mine uddybende posts.
hvis en applikation ikke er skrevet multitraadet for at udnytte smp, faar du kun en fraktion af den gevinst en applikation skrevet til at smp kan opnaa.
altsaa holder min paastand ganske glimrende; der meget faa applikationer der er skrevet decideret multitraadet for at udnytte smp.
du kan maaske vaere ligeglad, men hvis man arbejder i branchen, eller naar dualcore cpu'er vinder frem, er det et reelt problem.
/stone
noget jeg bare undrer mig over, er hvorfor et spørgsmål om antal CPUer overhovedet skal have noget med licens at gøre...
jeg gad nok vide hvilken lov det er jeg bryder, hvis jeg modificerer en winXP pro til at køre med 4 CPUer...
hvis jeg lovligt må installere samme kopi af windows på min egen bærbare og min egen stationære PC (og det må jeg) er det vel intet problem også at installere den på maskine med flere CPUer
jeg gad nok vide hvilken lov det er jeg bryder, hvis jeg modificerer en winXP pro til at køre med 4 CPUer...
hvis jeg lovligt må installere samme kopi af windows på min egen bærbare og min egen stationære PC (og det må jeg) er det vel intet problem også at installere den på maskine med flere CPUer
#27, Det var da netop det jeg skrev i indlæg #19. Nemlig at bare fordi at et program er multitråedet så er det ikke nødvendigvis optimeret til SMP.
Det har som andre har været inde på om man (groft sagt) sender en stor arbejdsopgave ud til en tråd.Hvorved den tråd jo bindes på den ene core/ht/cpu. Eller om man deler en arbejdsopgave op i flere stumper som så kan behandles af hver sin tråd, på hver sin core/ht/cpu.
I dit indlæg #29 argumenterer du for at ting først er multitrådet når det er skrevet til at udnytte SMP, men det er ikke korrekt.
Rent definitionsmæsssigt er begge dele multitrådet (antal tråde >1), spørgsmålet er "blot" hvor godt de skalerer når der tilføjes flere CPU/kerner.
Desuden skriver du i indlæg #6 "der er stort set ingen applikationer der er skrevet multitraadet.", mens du i indlæg #29 skriver "der meget faa applikationer der er skrevet decideret multitraadet for at udnytte smp"
Der er stor forskel på disse statements, faktisk lige netop skaleringen som jeg nævnte.
Som en anden skrev så kan du prøve at tilføje Thread Count kollonen i din windows taskmanager, og du kan men selvsyn se at flertallet af programmer har mere end 1 tråd.Hos mig er det kun 4 ud af 63 processor som kun har 1 tråd.
Det har som andre har været inde på om man (groft sagt) sender en stor arbejdsopgave ud til en tråd.Hvorved den tråd jo bindes på den ene core/ht/cpu. Eller om man deler en arbejdsopgave op i flere stumper som så kan behandles af hver sin tråd, på hver sin core/ht/cpu.
I dit indlæg #29 argumenterer du for at ting først er multitrådet når det er skrevet til at udnytte SMP, men det er ikke korrekt.
Rent definitionsmæsssigt er begge dele multitrådet (antal tråde >1), spørgsmålet er "blot" hvor godt de skalerer når der tilføjes flere CPU/kerner.
Desuden skriver du i indlæg #6 "der er stort set ingen applikationer der er skrevet multitraadet.", mens du i indlæg #29 skriver "der meget faa applikationer der er skrevet decideret multitraadet for at udnytte smp"
Der er stor forskel på disse statements, faktisk lige netop skaleringen som jeg nævnte.
Som en anden skrev så kan du prøve at tilføje Thread Count kollonen i din windows taskmanager, og du kan men selvsyn se at flertallet af programmer har mere end 1 tråd.Hos mig er det kun 4 ud af 63 processor som kun har 1 tråd.
@29
Du må gøre som det passer dig. Surt at du ikke kan li' at jeg læser det som du skriver, og ikke det som du mener, men jeg er i store træk ligeglad. Hvis jeg ikke havde skrevet, at jeg gerne ville høre "din definition", så ville du nok ikke være kommet tættere på at udtrykke din mening på en forståelig måde. Det værste, som jeg kunne ha' gjort ville være at lade dine fejlagtige skriverier stå uantastet hen.
Og jeg vil stadig ikke give dig ret i, at man kan se bort fra de fordele som kan mærkes når man bruger almindelige desktop (Office, Web browser) produkter på en computer med mere end 1 CPU.
Jeg synes stadig at nogle af dine påstande er utilstrækkeligt begrundede. Simpel funktionel dekomposition [banal opgave opdeling som også bruges i enkelt CPU systemer] kan give betydelige gevinster i mange tilfælde. Denne artikel angiver at funktionel dekomposition giver omkring halvdelen af den gevinst som data-domain dekomposition kan give for applikationer som faktisk er egnede for data-domain dekomposition. Hvis man igen trækker PowerPoint eksemplet ind, så tvivler jeg noget på at du kan opnå større gevinster ved yderligere arbejde på at parallellisere arbejdsopgaverne.
Hvis vi holder os til trådens emne, så kan mange brugere da også være glade for at kunne køre flere tunge programmer samtidigt. Der er da ingen grund til at kun fokusere på applikationer, som er glade for flere CPUer.
Af main-stream applikationer, som er egnede til parallellisering, så ser man da ofte at de er smt-enablede. Adobe Premiere, Visual Studio.NET, diverse raytracere og audio og video codecs er eksempler.
Du må gøre som det passer dig. Surt at du ikke kan li' at jeg læser det som du skriver, og ikke det som du mener, men jeg er i store træk ligeglad. Hvis jeg ikke havde skrevet, at jeg gerne ville høre "din definition", så ville du nok ikke være kommet tættere på at udtrykke din mening på en forståelig måde. Det værste, som jeg kunne ha' gjort ville være at lade dine fejlagtige skriverier stå uantastet hen.
Og jeg vil stadig ikke give dig ret i, at man kan se bort fra de fordele som kan mærkes når man bruger almindelige desktop (Office, Web browser) produkter på en computer med mere end 1 CPU.
Jeg synes stadig at nogle af dine påstande er utilstrækkeligt begrundede. Simpel funktionel dekomposition [banal opgave opdeling som også bruges i enkelt CPU systemer] kan give betydelige gevinster i mange tilfælde. Denne artikel angiver at funktionel dekomposition giver omkring halvdelen af den gevinst som data-domain dekomposition kan give for applikationer som faktisk er egnede for data-domain dekomposition. Hvis man igen trækker PowerPoint eksemplet ind, så tvivler jeg noget på at du kan opnå større gevinster ved yderligere arbejde på at parallellisere arbejdsopgaverne.
Hvis vi holder os til trådens emne, så kan mange brugere da også være glade for at kunne køre flere tunge programmer samtidigt. Der er da ingen grund til at kun fokusere på applikationer, som er glade for flere CPUer.
Af main-stream applikationer, som er egnede til parallellisering, så ser man da ofte at de er smt-enablede. Adobe Premiere, Visual Studio.NET, diverse raytracere og audio og video codecs er eksempler.
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