mboost-dp1
AMD
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Lyder lækkert at AMD skruer op for varmen mod Intel, jeg er hverken pro den ene eller den anden, men tror i sidste ende at det vil gavne forbrugerne.
I forhold til at have 12 kerner til husbehov lyder det måske lige vildt nok, MEN måske med noget virtualisering eller en hardware/software løsning der afskaffer GPU'en så kan det da godt blive aktuelt.
I forhold til at have 12 kerner til husbehov lyder det måske lige vildt nok, MEN måske med noget virtualisering eller en hardware/software løsning der afskaffer GPU'en så kan det da godt blive aktuelt.
#2
Var det ikke 8 kerner ?
Tror på ingen måde at man opnår en højere oplevet hastighed ved at tilføje flere kerner hele tiden. Det er vidst vist at kerner udover 8 ikke hjælper særlig meget, da de ikke kan udnyttes. Synes det virker som en dårlig måde at løse problemet på. De skulle hellere arbejde på en bedre arkitektur.
Var det ikke 8 kerner ?
Tror på ingen måde at man opnår en højere oplevet hastighed ved at tilføje flere kerner hele tiden. Det er vidst vist at kerner udover 8 ikke hjælper særlig meget, da de ikke kan udnyttes. Synes det virker som en dårlig måde at løse problemet på. De skulle hellere arbejde på en bedre arkitektur.
Nu ved AMD nok noget mere om emnet end jeg gør, men jeg vil da tilslutte mig den umiddelbare opfattelse af, at det er en meget lille brøkdel af programmer, der kører i mere end 1-2 processer. Og den menneskelige hjerne og skærmen sætter visse begrænsninger for hvad, der kræver processoren.
Ingen tvivl om, at om nogle år hvis f.eks. Cloud kommer på markedet (så vidt jeg har forstået om den smule jeg har læst om Cloud), vil langt flere kerner blive aktuelt.
Men er AMD ikke lidt foran udviklingen her?
Næh - bedre strøm/ydelsesforhold i et normalt OS er hvad jeg kigger efter samt selvfølgelig den rene ydelse. Til desktoppen kigger jeg sådan set ikke ret meget på strømmen - mere på varmen.
Ingen tvivl om, at om nogle år hvis f.eks. Cloud kommer på markedet (så vidt jeg har forstået om den smule jeg har læst om Cloud), vil langt flere kerner blive aktuelt.
Men er AMD ikke lidt foran udviklingen her?
Næh - bedre strøm/ydelsesforhold i et normalt OS er hvad jeg kigger efter samt selvfølgelig den rene ydelse. Til desktoppen kigger jeg sådan set ikke ret meget på strømmen - mere på varmen.
Problemet ligger ikke i hardwaren, men i softwaren. Det er som om, at programmører er "bange" for at hoppe ud i noget nyt. Hvem husker ikke John Carmack og hans PS3 bash, fordi den var for sær at kode til...
Tiderne skifter og mon ikke flere software udviklere skulle til at indse det? Det er sgu ikke hardwaren der er begrænsningen her.
Tiderne skifter og mon ikke flere software udviklere skulle til at indse det? Det er sgu ikke hardwaren der er begrænsningen her.
Det er også omsonst med mindre det er muligt at bygge cpuen op så den automatisk distribuere programmer så de kører jævnt på samtlige processer med mindre der programmeres direkte at det skal kører på en bestemt måde.
Der er jo så godt som ingenting der kører på mere end en processer i dag (jo det FINDES programmer. Men jo langt fra nok til at det er interessant for almindelige gamere og nørder)
Der er jo så godt som ingenting der kører på mere end en processer i dag (jo det FINDES programmer. Men jo langt fra nok til at det er interessant for almindelige gamere og nørder)
hvad f*** er der i vejen med jer??
man skal da ikke brokke sig over en 12kerne cpu... jeg kan da ikke få saft nok ud af 2 kerner og vil da self have flere næste gang jeg køber pc...
softwaren skal nok følge med... om ikke andet kan man køre 6 programmer med 2 kerner...
desuden snakker vi 2011... så ca 3 år efter kan dødelige få råd... så hvis man ikke kan bruge 12 kerner om 2-5 år SÅ er det et problem fra software folket...
men til den tid skal de fleste OS kunne følge med...
man skal da ikke brokke sig over en 12kerne cpu... jeg kan da ikke få saft nok ud af 2 kerner og vil da self have flere næste gang jeg køber pc...
softwaren skal nok følge med... om ikke andet kan man køre 6 programmer med 2 kerner...
desuden snakker vi 2011... så ca 3 år efter kan dødelige få råd... så hvis man ikke kan bruge 12 kerner om 2-5 år SÅ er det et problem fra software folket...
men til den tid skal de fleste OS kunne følge med...
#2,4,7
Der er 20 års erfaring for at man kan udnytte mere end 6/8 kerner (at der kun var en kerne per socket og at systemerne kostede en bondegård ændrer ikke på at det er bevist at man kan udbytte det).
Det afhænger naturligvis af hvilken type programmer og hvordan de er programmet.
Men at man ikke kan udnytte mere end 6/8 kerner er en and på niveau med at jorden er flad.
Der er 20 års erfaring for at man kan udnytte mere end 6/8 kerner (at der kun var en kerne per socket og at systemerne kostede en bondegård ændrer ikke på at det er bevist at man kan udbytte det).
Det afhænger naturligvis af hvilken type programmer og hvordan de er programmet.
Men at man ikke kan udnytte mere end 6/8 kerner er en and på niveau med at jorden er flad.
noxity (4) skrev:#2
Var det ikke 8 kerner ?
Tror på ingen måde at man opnår en højere oplevet hastighed ved at tilføje flere kerner hele tiden. Det er vidst vist at kerner udover 8 ikke hjælper særlig meget, da de ikke kan udnyttes. Synes det virker som en dårlig måde at løse problemet på. De skulle hellere arbejde på en bedre arkitektur.
Det passer over hovedet ikke. Flere kerner er nærmest det samme som at have flere processorer. Det der gør at ting måske bliver langsommere af flere kerner, er at hverken operativ systemer eller (meget) software er designet til at udnytte flere kerner. Dette gør at enten udnytter de slet ikke de flere kerner, eller de gør det forkert.
Jeg ville ønske at folk der ikke ved en skid om et emne bare lod være med at diskutere det.
#9: Så er det heller ikke rettet mod consumere. Jeg siger intet om at en server ikke kan bruge flere kerner (gør de allerede). Jeg siger blot, at for en almindelig bruger (der iflg. min logik udgik langt størstedelen af consumermarkedet) betyder det meget lidt eller intet om du har 4 eller 8 kerner.
Selvfølgelig kan mange åbne programmer æde flere kerner, men det kræver, at de programmer, der kører i baggrunden rent faktisk har noget at arbejde på. Dårligt eksempel, men det er lidt "spild" af Excel får sin egen kerne til at Idle på mens man spiller WoW. Selvfølgelig er der nogle, der laver 3D osv., der kan rendere noget i baggrunden, men det er nok ikke ligefrem 90% af markedet.
Hvis AMD vil vinde på consumer markedet, tror jeg næppe at flere kerner er løsningen de næste 3-4 år. Medmindre de på en eller anden måde kan få programmørerne til at lave mangetrådede programmer.
Det være sagt, så er det ikke just CPU'en, der gør at en alm. brugers PC kører langsomt. Lad os få SSD'er ned i pris.
Selvfølgelig kan mange åbne programmer æde flere kerner, men det kræver, at de programmer, der kører i baggrunden rent faktisk har noget at arbejde på. Dårligt eksempel, men det er lidt "spild" af Excel får sin egen kerne til at Idle på mens man spiller WoW. Selvfølgelig er der nogle, der laver 3D osv., der kan rendere noget i baggrunden, men det er nok ikke ligefrem 90% af markedet.
Hvis AMD vil vinde på consumer markedet, tror jeg næppe at flere kerner er løsningen de næste 3-4 år. Medmindre de på en eller anden måde kan få programmørerne til at lave mangetrådede programmer.
Det være sagt, så er det ikke just CPU'en, der gør at en alm. brugers PC kører langsomt. Lad os få SSD'er ned i pris.
#21 I 1980... Der har været programmer (Mest server programmer og måske også noget indenfor video og 3d redigering??) der udnytter langt over 2-4 kerner...
De programmer der var udviklet til itanium var alle multithreaded, men altså til det almene forbrug tror jeg nok du skal vente en 10-15 år på at se Firefox få brug for at udnytte bare en brøkdel af det :P
Og det var vidst noget med at det i spil er skide besværligt og egentlig er der ikke rigtig det helt store behov for det lige PT.
Dog tror jeg at vi, når den næste generation af konsoller bliver lanceret, vil se rigtig meget godt udnyttet multithreading i spil ;)
De programmer der var udviklet til itanium var alle multithreaded, men altså til det almene forbrug tror jeg nok du skal vente en 10-15 år på at se Firefox få brug for at udnytte bare en brøkdel af det :P
Og det var vidst noget med at det i spil er skide besværligt og egentlig er der ikke rigtig det helt store behov for det lige PT.
Dog tror jeg at vi, når den næste generation af konsoller bliver lanceret, vil se rigtig meget godt udnyttet multithreading i spil ;)
Flere kerner!
Jeg gider ikke flere kerner!
Det er måske fint nok til en terminal server hvor brugere kan spredes ud over flere kerner i hver deres miljø.
Men en desktop pc har ikke brug for flere kerner end max 4 efter min mening! Jeg vil hellere at de får sat noget mere fart på processoren pr. kerne og at de får fjerne eventuelle flaske halse. Ud over det ville jeg ønske 32 bit blev droppet og vi alle kunne benytte 64 bit. Det er spild af tid for software og hardware producenter at blive ved med at understøtte 32 bit.
Tak for kaffe :)
Jeg gider ikke flere kerner!
Det er måske fint nok til en terminal server hvor brugere kan spredes ud over flere kerner i hver deres miljø.
Men en desktop pc har ikke brug for flere kerner end max 4 efter min mening! Jeg vil hellere at de får sat noget mere fart på processoren pr. kerne og at de får fjerne eventuelle flaske halse. Ud over det ville jeg ønske 32 bit blev droppet og vi alle kunne benytte 64 bit. Det er spild af tid for software og hardware producenter at blive ved med at understøtte 32 bit.
Tak for kaffe :)
Ser ud til at jeg vil foretrække Intel et godt stykke tid endnu så.
Foretrækker som det er lige nu højere clock af den åbenlyse grund nævnt her i debatten.
Men det er godt at nogen tør tage det skridt, for så skal software developerne jo nok tage sig sammen når de kan se at nu begynder det virkelig at blive nødvendigt / et plus i deres produkt.
Foretrækker som det er lige nu højere clock af den åbenlyse grund nævnt her i debatten.
Men det er godt at nogen tør tage det skridt, for så skal software developerne jo nok tage sig sammen når de kan se at nu begynder det virkelig at blive nødvendigt / et plus i deres produkt.
1. Du kan ikke bruge alle de kerner til et dyt uden at 64bit bliver mere normalt.
2. Du kan ikke bruge kerner til et nyt med mindre software producenterne skriver deres kode til flere kerner.
3. Jo flere kerner du benytter jo større bliver flaskehalsen.
Det absolut bedste der kan ske for PC ydelse lige nu hedder SSD.
Jo hurtigere vi får SSD ud til folket jo bedre. De fleste kan ikke bruge flere kerner til ret meget. Hvor imod en SSD disk ville gøre et system meget hurtigere i 99 % af alle tilfælde.
2. Du kan ikke bruge kerner til et nyt med mindre software producenterne skriver deres kode til flere kerner.
3. Jo flere kerner du benytter jo større bliver flaskehalsen.
Det absolut bedste der kan ske for PC ydelse lige nu hedder SSD.
Jo hurtigere vi får SSD ud til folket jo bedre. De fleste kan ikke bruge flere kerner til ret meget. Hvor imod en SSD disk ville gøre et system meget hurtigere i 99 % af alle tilfælde.
bani (28) skrev:1. Du kan ikke bruge alle de kerner til et dyt uden at 64bit bliver mere normalt.
Udnyttelsen af mange kerne processorer og 64 bit har intet med hinanden at gøre.
bani (28) skrev:2. Du kan ikke bruge kerner til et nyt med mindre software producenterne skriver deres kode til flere kerner.
En enkelt process kan kun udnytte en kerne medmindre koden er multithreaded.
Men det hænder at nogen kører flere processer.
Som udvikler, hvor jeg ofte beskæftiger mig med udvikling af serverløsninger, er mange kerner på desktoppen rigtig lækkert.
Det muliggør simuleringer der minder meget om driftsituationen (hvor der typisk vil være mange flere kerner tilrådighed).
Desto flere kerner, desto størrer sandsynlighed og dermed desto hurtigere vil man finde sjældent opstående samtidighedsproblemer.
Derudover må folk bare til at tage sig lidt sammen - det er helt klart sværere at kode til mange kerner, men det kan læres.
De fleste udviklere kan godt li en udfordring, så tag og grib den, istedetfor al det jamren over at verden er blevet kompliceret.
Man kan godt forvente at det kræver en ændret tankegang at kode til nutidens CPU'er, men de er kommet for at blive og det er med at holde sig på vognen - for fremtiden tilhører de udviklere der formår at udnytte dem.
Det muliggør simuleringer der minder meget om driftsituationen (hvor der typisk vil være mange flere kerner tilrådighed).
Desto flere kerner, desto størrer sandsynlighed og dermed desto hurtigere vil man finde sjældent opstående samtidighedsproblemer.
Derudover må folk bare til at tage sig lidt sammen - det er helt klart sværere at kode til mange kerner, men det kan læres.
De fleste udviklere kan godt li en udfordring, så tag og grib den, istedetfor al det jamren over at verden er blevet kompliceret.
Man kan godt forvente at det kræver en ændret tankegang at kode til nutidens CPU'er, men de er kommet for at blive og det er med at holde sig på vognen - for fremtiden tilhører de udviklere der formår at udnytte dem.
arne_v (29) skrev:Udnyttelsen af mange kerne processorer og 64 bit har intet med hinanden at gøre.bani (28) skrev:2. Du kan ikke bruge kerner til et nyt med mindre software producenterne skriver deres kode til flere kerner.
En enkelt process kan kun udnytte en kerne medmindre koden er multithreaded.
Men det hænder at nogen kører flere processer.
Der er så sandlig også meget at bruge 8 kerner til med kun 3½ GB RAM i en maskine! Uha da da! Det lyder lige så kedeligt som søndags tv! 64 Bit skal til!
bani (31) skrev:Der er så sandlig også meget at bruge 8 kerner til med kun 3½ GB RAM i en maskine! Uha da da! Det lyder lige så kedeligt som søndags tv! 64 Bit skal til!
Der er ikke nogen fast sammenhæng mellem CPU og RAM forbrug.
Iøvrigt kan 32 bit Windows og 32 bit Linux godt bruge 64 GB RAM (desktop udgaverne af Windows har bare fået en kunstig restriktion lagt ind).
Er jeg den enste, som falder over, at Intel's kodenavne er en smule sejere end AMD's?
Altså Nehalem; Det lyder jo nærmest som en eller anden syg solgud, eller sådan noget. Mens Magny Cours jo bare er en sølle racerbane på en mark i Frankrig. :P
Altså Nehalem; Det lyder jo nærmest som en eller anden syg solgud, eller sådan noget. Mens Magny Cours jo bare er en sølle racerbane på en mark i Frankrig. :P
#12 At du gider blive ved, igen har du ikke forstand på hvad du snakker om, hvem er det der falmer smarte?
http://www.extremetech.com/article2/0,2845,2107342...
omg de 2 extra kerner giver simplen 1-5fps OMG det er super udnyttelse.
Og WiC siger mig ikke noget, men jeg er sikker på en anden klog Newz bruger kan finde en benchmark, så vi lige kan banke dig helt på plads, husk nu at gå ud i solen, du falmer rigtig meget lige p.t
Når de nu ikke kan øge clock hastighed ret meget mere lige p.t så er vi nød til at skal have rå ydelse i spil, ved de flere kerner og det for vi ikke. Det er ihvertfald dyre fps.
http://www.extremetech.com/article2/0,2845,2107342...
omg de 2 extra kerner giver simplen 1-5fps OMG det er super udnyttelse.
Og WiC siger mig ikke noget, men jeg er sikker på en anden klog Newz bruger kan finde en benchmark, så vi lige kan banke dig helt på plads, husk nu at gå ud i solen, du falmer rigtig meget lige p.t
Når de nu ikke kan øge clock hastighed ret meget mere lige p.t så er vi nød til at skal have rå ydelse i spil, ved de flere kerner og det for vi ikke. Det er ihvertfald dyre fps.
#35
Benchmarket du linker til viser ret tydeligt at deres setup er begrænset af gpu (og muligvis båndbredde), derfor er der ingen reel forskel på ydelsen imellem de to processorer (de burde også kunne have brugt en endnu svagere cpu uden det ville påvirke noget). At klage over at det er dyrt opnåede fps i det tilfælde svarer til at klage over excel ikke starter hurtigere op af at man opgraderer ens graffikkort.
Praktisk taget alle de tunge beregninger i spil foregår på gpu'en, hvor der beregnes ekstremt parallelt med op til flere hundrede kerner. Sagt på en anden måde er der mange opgaver, hvor ydelsen skalerer tilnærmelsesvis lineært med antallet af kerner opgaven beregnes på. Der er dog også opgaver som praktisk taget ikke kan løses parallelt (især under ai og kryptologi), men de opgaver er ikke så almindelige.
Benchmarket du linker til viser ret tydeligt at deres setup er begrænset af gpu (og muligvis båndbredde), derfor er der ingen reel forskel på ydelsen imellem de to processorer (de burde også kunne have brugt en endnu svagere cpu uden det ville påvirke noget). At klage over at det er dyrt opnåede fps i det tilfælde svarer til at klage over excel ikke starter hurtigere op af at man opgraderer ens graffikkort.
Praktisk taget alle de tunge beregninger i spil foregår på gpu'en, hvor der beregnes ekstremt parallelt med op til flere hundrede kerner. Sagt på en anden måde er der mange opgaver, hvor ydelsen skalerer tilnærmelsesvis lineært med antallet af kerner opgaven beregnes på. Der er dog også opgaver som praktisk taget ikke kan løses parallelt (især under ai og kryptologi), men de opgaver er ikke så almindelige.
Undre mig lidt over hvorfor der er så mange der siger at programmer først om mange år vil kunne udnytte flere kerner.. Hvis jeg kigger i min taskmanager lige nu kan jeg se at explorer.exe bruger 32 tråde. Det vil altså potentielt kunne brede sig over 32 kerner på maskinen. Grunden til denne proess bruger så mange tråde er for man f.eks. kan browse filer i én mappe, mens man kopiere filer i en anden.. Uden denne mulighed ville de blocke for hinanden.
Ud over det starter en standard dot net app. mellem 10 og 15 tråde uden man gør noget specielt, og VS2010 understøtter paralleliserede for og foreach loops, som på en nem måde spreder ens load over alle tilgængelige kerner i maskinen..
Den nye paralleliserede foreach løkke ser ud som følger:
Parallel.ForEach(cacheActor, (tActor) =>
{
});
hvilket er meget tæt på hvad vi kender fra i dag, så mon ikke rigtig mange udviklere vil begynde at bruge dette meget snart? :)
Ud over det starter en standard dot net app. mellem 10 og 15 tråde uden man gør noget specielt, og VS2010 understøtter paralleliserede for og foreach loops, som på en nem måde spreder ens load over alle tilgængelige kerner i maskinen..
Den nye paralleliserede foreach løkke ser ud som følger:
Parallel.ForEach(cacheActor, (tActor) =>
{
});
hvilket er meget tæt på hvad vi kender fra i dag, så mon ikke rigtig mange udviklere vil begynde at bruge dette meget snart? :)
Så stop dog det der pis med flere kerner vi kan jo ikke bruge dem kom med dem når vi faktisk har et system der kan bruge den slags.
Ind til da brug energien på forskning inden for lys leder kabler.
Se så snakker vi fart har hørt (ved ikke om det er sandt) at når først der er nogle ordtenlige lys leder kabler i maskinen vil vi kunne køre med en hastighed op til 800 til 8000 gange så hurtigt som vi kan nu.
Ind til da brug energien på forskning inden for lys leder kabler.
Se så snakker vi fart har hørt (ved ikke om det er sandt) at når først der er nogle ordtenlige lys leder kabler i maskinen vil vi kunne køre med en hastighed op til 800 til 8000 gange så hurtigt som vi kan nu.
#37 Korrekt.. Men explorer har ikke brug for 32 kerner :/ det kan godt være den kunne køre på 32 på 1 gang, men så ville der blive brugt 0.01% af den kraft der er :P
Men jeg synes det er lidt overdrevet at de går fra 2/4 kerner og nu vil hve 16 kerners inden for få år... De quad core CPUer vi har haft i en del år nu bliver stadig ikke udnyttet særlig effektivt i de mest gængse desktop programmer :/
#38 Ja, og det er MANGE år i fremtiden du taler om der... Jeg tror personligt at en biologisk computer med nogle lys leder som BUS eller sådan noget bliver det næste store spring vi ser.
Men jeg synes det er lidt overdrevet at de går fra 2/4 kerner og nu vil hve 16 kerners inden for få år... De quad core CPUer vi har haft i en del år nu bliver stadig ikke udnyttet særlig effektivt i de mest gængse desktop programmer :/
#38 Ja, og det er MANGE år i fremtiden du taler om der... Jeg tror personligt at en biologisk computer med nogle lys leder som BUS eller sådan noget bliver det næste store spring vi ser.
Jeg kunne godt forestille mig at man har processorer med flere hundrede kerner om nogle år. Problemet er lige nu at der ikke er nogle styresystemer der kan udnytte dem særligt effektivt. 4 kerner bruger ufatteligt meget tid på at stå og vente på hinanden. Det er sgu modigt/optimistisk af AMD, for jeg tror ikke at MS bliver de første til at knække den omdiskuterede nød..
#40: Det er noget bullshit. Operativsystemerne kan sagtens udnytte de her mange kerner. Den eneste grund til at Windows Server 2008 er begrænset til at udnytte 64 kerner er grundet en implementationsdetalje i scheduleren - med Win2k8 R2 rykker denne grænse sig til 256 kerner. (og kernen i Vista SP1 er iøvrigt identisk med kernen i Win2k8 og R2 kommer formentlig til at svare til kernen i Win7)
Det er specifikke softwareprodukter der kan have problemer, fordi udviklerne ikke har omstillet sig til en multicore verden - meget ofte gælder det spil fordi de er baseret på håbløs forældede tanker om et centralt gameloop, det er dog så småt ved at ændre sig, bl.a. er Crysis udviklet til at kunne udnytte de mange kerner i en moderne PC.
Det er specifikke softwareprodukter der kan have problemer, fordi udviklerne ikke har omstillet sig til en multicore verden - meget ofte gælder det spil fordi de er baseret på håbløs forældede tanker om et centralt gameloop, det er dog så småt ved at ændre sig, bl.a. er Crysis udviklet til at kunne udnytte de mange kerner i en moderne PC.
RMJdk (35) skrev:#12 At du gider blive ved, igen har du ikke forstand på hvad du snakker om, hvem er det der falmer smarte?
http://www.extremetech.com/article2/0,2845,2107342...
omg de 2 extra kerner giver simplen 1-5fps OMG det er super udnyttelse.
Og WiC siger mig ikke noget, men jeg er sikker på en anden klog Newz bruger kan finde en benchmark, så vi lige kan banke dig helt på plads, husk nu at gå ud i solen, du falmer rigtig meget lige p.t
Når de nu ikke kan øge clock hastighed ret meget mere lige p.t så er vi nød til at skal have rå ydelse i spil, ved de flere kerner og det for vi ikke. Det er ihvertfald dyre fps.
Lad være med at bruge amatør sites:
http://www.hardocp.com/article.html?art=MTMwNiwzLC...
http://www.hardocp.com/article.html?art=MTIxNyw0LC...
http://www.guru3d.com/article/cpu-scaling-in-games...
#43: Det er lidt så som så, set fra OS'et optråder en HT-kerne som om den har 2 kerner, men den har altså kun én execution unit. Forskellen ligger i preemption delen - en HT processor er istand til at udføre context switches mellem 2 tråde langt hurtigere end en traditionel processor.
Tilgengæld kan det også have visse ulemper. Typisk er HT godt til desktop-brug da det kan øge responsiveness, men skidt til serverbrug da man risikerer at schedulere dobbel arbejde på én execution unit istedetfor at fordele det over 2 execution units, som typisk er det man ønsker (dog primært et problem hvis man selv styrer processor affinities, de fleste moderne schedulerer er HT-aware).
Tilgengæld kan det også have visse ulemper. Typisk er HT godt til desktop-brug da det kan øge responsiveness, men skidt til serverbrug da man risikerer at schedulere dobbel arbejde på én execution unit istedetfor at fordele det over 2 execution units, som typisk er det man ønsker (dog primært et problem hvis man selv styrer processor affinities, de fleste moderne schedulerer er HT-aware).
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.