mboost-dp1
AMD
Det skal nok komme mht båndbreden, teknologien ændre sig konstant. Før eller siden sidder vi alle med en super-duper-computer med 50 kerner og massere af båndbrede i, som sikkert er fuldstændigt nyttesløst at have, pga div programmer ikke bruger dem alle alligevel.
Men det kommer; Fordi vi kan!!
Men det kommer; Fordi vi kan!!
De tager så grueligt fejl, specielt når vi flytter alt ned på CPU'en og dertil lægger de øgede fysikberegninger som fremtisden spil kræver:
http://techresearch.intel.com/articles/Tera-Scale/...
http://www.anandtech.com/cpuchipsets/showdoc.aspx?...
Ham Sandi skulle lægge barbiebladet fra sig og følge med i udviklingen:
http://www.tomshardware.com/news/Intel-Avalanche-P...
http://techresearch.intel.com/articles/Tera-Scale/...
http://www.anandtech.com/cpuchipsets/showdoc.aspx?...
Ham Sandi skulle lægge barbiebladet fra sig og følge med i udviklingen:
http://www.tomshardware.com/news/Intel-Avalanche-P...
Jeg syntes det er lidt mærkelig udtalelse at lave. Hvis båndreden ikke er stor nok må, man vel lave en ny sockel eller andet som forøger den, når man kommer til det punkt at men vil havde 16 eller flere kerner. Det er vel også noget af gundet til at core i7 ikke køre med samme sockel som Core2Duo. Det er også derfor der findes flere versioner af HT busen til AMDs cpuer. Der kommer jævnligt sådan åbenlyse udtalelser hvor det bare ikke giver nogen mening at informere folk om det. Det er jo klart at AMD/Intel vil da lave større båndbrede før de udgaver processerne hvis der er et stort behov for det. Jeg kunne måske forstå hvis de sagde at der går lang tid før man har brug for flere kerner, da programmer der kan udnytte det ordenligt, ikke er det mest almindelige.
Det er utroligt at vi idag stadig kan se folk udtale sig om teknologi i stil med:
"X of Y is enough for everyone."
:-)
"X of Y is enough for everyone."
:-)
Jeg syntes at der skulle bruges flere kræfter paa at forbredre kernerne istedet for, at blot tilføje flere.
Det er ikke let at lave algoritmer flertrådet (taler af erfaring fik 12 i bachelor projekt omkring at gøre geometriske algoritmer flertrådet) Ved at bruge 2 kerne kerne bliver en algoritme ikke dobbel så hurtig, kun noget der ligner 1.5-1.6 gange. Desuden er der flere algoritmer som slet ikke egner sig til, at kører på flere kerner, men her kan man ofte designe nogle nye og mere komplekse.
Selvfølgelig findes der sprog der automatisk laver kode flertrådet, men min erfaring er at det ikke holder ret godt!
Det er ikke let at lave algoritmer flertrådet (taler af erfaring fik 12 i bachelor projekt omkring at gøre geometriske algoritmer flertrådet) Ved at bruge 2 kerne kerne bliver en algoritme ikke dobbel så hurtig, kun noget der ligner 1.5-1.6 gange. Desuden er der flere algoritmer som slet ikke egner sig til, at kører på flere kerner, men her kan man ofte designe nogle nye og mere komplekse.
Selvfølgelig findes der sprog der automatisk laver kode flertrådet, men min erfaring er at det ikke holder ret godt!
Man kan undres over om de har hørt om de herens multikernede supercomputere:
http://en.wikipedia.org/wiki/Supercomputer
Terra - De ER allerede beviseligt forkert på den...
http://en.wikipedia.org/wiki/Supercomputer
Terra - De ER allerede beviseligt forkert på den...
#0
Problemet er, at der ikke er båndbredde nok i de nuværende processor-designs til at levere data hurtigt nok til de enkelte kerner.
Det er jo altid rart at der er nogen der funder ud af hvor den næste barriere er. Cell CPUen som har 9 kerner, har jo også en meget stor intern og ekstern båndbredte, sammenlignet med de 4 kerne CPUer som Intel og AMD levere. Og det ved de selvfølgelig godt.
Uanset hvilke beregninger det er de vil lave på en super computer, er det altid muligt at lave en CPU med hukommelsesbuser der levere en hurtigere ydelse end hvis kernere var i forskellige noder i deres cluster. Alene pga den kortere afstand.
GOOOD (8) skrev:Ved at bruge 2 kerne kerne bliver en algoritme ikke dobbel så hurtig, kun noget der ligner 1.5-1.6 gange
Det er også rigtig, men hvis valget står mellem at bruger flere noder eller flere kærner i samme node, så skal algoritmen kodes som flertrådet. Og du har ret i at der er der ikke mange der er gode til, fordi det er ikke let. Men der er brug for det, så med den karakter du fik, ser det ud til at der er arbejde til dig på trods af krisen :-)
#8, #11: Nu er der jo stor forskel på algoritmer - hvor nogle er meget svære at splitte op i flere tråde (i tilfælde hvor næste step i algoritmen afhænger af resultatet af det foregående), så er det stort set ligetil ved andre (fx maskeoperationer på billeder som blur, edge detection, etc). Så de 1.5-1.6x speedup ved fordobling af kerneantal vil jeg vove at påstå kun gælder for nogle typer algoritmer. Nogle vil se meget lavere forbedringer, mens andre vil komme tæt på 2x speedup, hvis båndbredden er der (det er jo så selvfølgelig også lidt af idéen i nyheden;).
Og tror nu nok at chipproducenterne skal få sparket nogle kerner ud til forbrugerne - det er jo set før at det der tit fokuseres på er de specs som kan opgives og sammenlignes direkte såsom clockfrekvens osv. Hvis hr og fru Hansen har valget mellem en maskine med 16 kerner og en med 8 og de koster ca. det samme, så vil de da højest sandsynligt vælge den med 16 - uanset om den med 8 så er hurtigere eller ej... For 16 er jo tydeligvis bedre end 8...;)
Og tror nu nok at chipproducenterne skal få sparket nogle kerner ud til forbrugerne - det er jo set før at det der tit fokuseres på er de specs som kan opgives og sammenlignes direkte såsom clockfrekvens osv. Hvis hr og fru Hansen har valget mellem en maskine med 16 kerner og en med 8 og de koster ca. det samme, så vil de da højest sandsynligt vælge den med 16 - uanset om den med 8 så er hurtigere eller ej... For 16 er jo tydeligvis bedre end 8...;)
GOOOD (8) skrev:Det er ikke let at lave algoritmer flertrådet (taler af erfaring fik 12 i bachelor projekt omkring at gøre geometriske algoritmer flertrådet)
...med den teknologi, som var tilgængelig på det tidspunkt?
Huskede du de nye programmeringsprog og algoritmer, som er designet til mange kerner?
Den nye generation af sprog laver om på nogle af de mest grundlæggende ting, som har været med os i rigtigt mange år.
Fx. for-loopen:
for (i=1; i<1000; i++) {
numbers[i]++;
}
Gør noget 1000 gange. Fx. en beregning på 1000 elementer. Der er en counter, som viser hvilket element vi er nået til. Ergo kan den ikke deles op i flere tråde.
Man kunne lave en ny syntax, som implicit udføres paralelt:
foeach(i in numbers) {
numbers[i]++;
}
Vupti, den er let at dele op. For simpel til at det kan betale sig, men der kunne ske meget mere inde i loopen, så længe den ikke er afhængig af de 999 andre elementer.
Forestil dig at hvert element tager 1 sekund at behandle. Forestil dig så en CPU med 1024 kerner. 1000 af dem beregner ét element, én organiserer det hele, og så er der stadig 23 kerner i overskud. Det hele kan måske gøres på 1-2 sekunder, hvis ellers arkitekturen omkring denne vilde CPU passer til.
Sådan er der så mange detaljer der lige skal gentænkes, og så kan ting som tidligere var umuligt at dele op i flere tråde, pludseligt nemt at dele op.
GOOOD (8) skrev:Ved at bruge 2 kerne kerne bliver en algoritme ikke dobbel så hurtig, kun noget der ligner 1.5-1.6 gange.
Jeg har nu oplevet >1.9, men din pointe er god nok. Der vil være noget spild, ved at dele det op.
Men selv hvis en 512-kerne CPU kun er 100 gange så hurtig som en 1-kerne, så vil jeg nu stadig foretrække den med 512 kerner.
GOOOD (8) skrev:Selvfølgelig findes der sprog der automatisk laver kode flertrådet, men min erfaring er at det ikke holder ret godt!
Erfaring? Vent til sprogene modner. ;-)
På papiret synes jeg det ser rigtigt spændende ud, og jeg glæder mig til sprogene modner og CPU'erne har flere kerner end æbler har. ;-)
#7: Hvor står der at x kerner er nok til alle? Jeg ser da nærmere at der står at selv om alle gerne vil have flere kerner, så hjælper det ikke. Alle vil gerne have flere biler ind ad Sydmotorvejen om morgenen. Men prøver man hænger man bare fast i køen.
#10: Det kunne måske være at de dersens flerkernede supercomputere var lavet på en lidt anderledes måde hvor flaskehalsen ikke eksisterede.
#topic: Der er da ikke noget som helst nyt i dette. Lige siden CPU hastigheden overhalede RAM hastigheden har der været røster der sagde at det ikke kunne betale sig at lave CPU hurtigere, for den ville bare nå endnu hurtigere frem til næste røde lyskurv. (bil-analogi), Hver gang er problemet blevet "løst", eller i hvert tilfælde skubbet lidt i baggrunden ved at tilføje caches. Først en level 1 cache meget tæt på CPU, derefter med en level 2 cache lidt længere væk. Det næste bliver vel at man opgiver det håbløst langsomme D-RAM og går til rigtig RAM for at få hastighederne op. Nogen der kunne tænke sig maskiner der kan følge med til 15 GHz clock?
Nå, det er lidt som SSD/HDD snakken. Det er spændende men dyrt at have det hurtigste.
#10: Det kunne måske være at de dersens flerkernede supercomputere var lavet på en lidt anderledes måde hvor flaskehalsen ikke eksisterede.
#topic: Der er da ikke noget som helst nyt i dette. Lige siden CPU hastigheden overhalede RAM hastigheden har der været røster der sagde at det ikke kunne betale sig at lave CPU hurtigere, for den ville bare nå endnu hurtigere frem til næste røde lyskurv. (bil-analogi), Hver gang er problemet blevet "løst", eller i hvert tilfælde skubbet lidt i baggrunden ved at tilføje caches. Først en level 1 cache meget tæt på CPU, derefter med en level 2 cache lidt længere væk. Det næste bliver vel at man opgiver det håbløst langsomme D-RAM og går til rigtig RAM for at få hastighederne op. Nogen der kunne tænke sig maskiner der kan følge med til 15 GHz clock?
Nå, det er lidt som SSD/HDD snakken. Det er spændende men dyrt at have det hurtigste.
#13: Det bliver så kompliceret, at sørge for at alle dele af loopet er færdig før man går videre, og eksemplet der er også meget simpelt. Hvad med f.eks. samtidighed? Man skal jo huske at låse, sætte monitors op etc.
Givetvis vil man kunne lave en virtuel maskine, der kan sørge for alt det, men man kan hurtige ende ud med en, der er så ressourcetung, at man ikke vinder noget.
Samtidig tilgang af variable kan være et meget komplekst problem.
Givetvis vil man kunne lave en virtuel maskine, der kan sørge for alt det, men man kan hurtige ende ud med en, der er så ressourcetung, at man ikke vinder noget.
Samtidig tilgang af variable kan være et meget komplekst problem.
Jeg må nok indrømme, at hvis jeg skal samle en puter til at game på og jeg har et fastsat budget, så prøve jeg at få noget dualcore med så mange ghz som muligt. I stedet for en quadcore med færre ghz.
Skal jeg samle en puter som skal bruges til multimedia, altså video decoding, 3d rendering osv.. Så går jeg efter en quadcore.
Grunden til dette er, at der ikke er ret mange spil som undersøtter mere end en kerne og er gode til det. Det er yderst sjældent at min Core2Duo køre på 100% (Mit G15 keyboard står altid og viser RAM/CPU forbrug). Så derfor gælder det om at få så meget fart på den ene, eller måske to kerner som spillet kan bruge. For hvad skal man dog med fire kerner, hvis det man primært bruger sin puter til kun tillader at bruge en eller to?
Programmer derimod, de er åbenbart optimeret bedre til flerekerne CPU'er, så der kan man med stor fordel købe en Quadcore.
Skal jeg samle en puter som skal bruges til multimedia, altså video decoding, 3d rendering osv.. Så går jeg efter en quadcore.
Grunden til dette er, at der ikke er ret mange spil som undersøtter mere end en kerne og er gode til det. Det er yderst sjældent at min Core2Duo køre på 100% (Mit G15 keyboard står altid og viser RAM/CPU forbrug). Så derfor gælder det om at få så meget fart på den ene, eller måske to kerner som spillet kan bruge. For hvad skal man dog med fire kerner, hvis det man primært bruger sin puter til kun tillader at bruge en eller to?
Programmer derimod, de er åbenbart optimeret bedre til flerekerne CPU'er, så der kan man med stor fordel købe en Quadcore.
#9 Uhyggeligt, at man kan kan skrive sådan et indlæg, med den orddeling!
"Interresant of relevant info
Og no offence, men hvordan kan en nyhed blive accepteret med den komma fordeling ? Det jo helt uhyggeligt!
Har foreslået en rettelse med korrekt komma sættelse :)
"
Det hedder 'Interessant'. 'kommafordeling' staves i eet ord. 'kommasættelse' staves også i eet ord og faktisk ikke kommasættelse, men 'kommasætning'. Der skulle nok stå "og" i stedet for "of". Og der mangler et "jeg" i sidste linje, så det også bliver en god dansk sætning.
Skulle man ikke lige klappe i, før man selv kan skrive dansk?
#topic
Det er noget underligt, at man ikke har vurderet, at fremtidens software vil tilpasses flere kerner. Dermed lærer programørrer at tænke mere hierarkisk i planlægningen af datastrømme. F.eks. kunne man få to kerner til at dele deres cache, og denne cache synkroniseres mod en større cache, som i alt 4 kerner deler og så videre...
"Interresant of relevant info
Og no offence, men hvordan kan en nyhed blive accepteret med den komma fordeling ? Det jo helt uhyggeligt!
Har foreslået en rettelse med korrekt komma sættelse :)
"
Det hedder 'Interessant'. 'kommafordeling' staves i eet ord. 'kommasættelse' staves også i eet ord og faktisk ikke kommasættelse, men 'kommasætning'. Der skulle nok stå "og" i stedet for "of". Og der mangler et "jeg" i sidste linje, så det også bliver en god dansk sætning.
Skulle man ikke lige klappe i, før man selv kan skrive dansk?
#topic
Det er noget underligt, at man ikke har vurderet, at fremtidens software vil tilpasses flere kerner. Dermed lærer programørrer at tænke mere hierarkisk i planlægningen af datastrømme. F.eks. kunne man få to kerner til at dele deres cache, og denne cache synkroniseres mod en større cache, som i alt 4 kerner deler og så videre...
#13 Ehm forklar mig lige, hvorfor:
for (i=1; i<1000; i++) { numbers[i]++;}
er forskelligt fra:
for (i=1; i<500; i++) { numbers[i]++;}
for (i=500; i<1000; i++) { numbers[i]++;}
Det nederste kan køres på to kerner helt seperat, og med 100% speedup.
Jeg tror du mener noget a la:
for (i=2; i<1000; i++) { numbers[i] += numbers[i-1];}
Resultatet af hver iteration af loopet afhænger af resultatet af det foregående. Dermed har du så mange dataafhængigheder, at ovenstående løkke ikke kan deles mellem flere kerner ;-)
for (i=1; i<1000; i++) { numbers[i]++;}
er forskelligt fra:
for (i=1; i<500; i++) { numbers[i]++;}
for (i=500; i<1000; i++) { numbers[i]++;}
Det nederste kan køres på to kerner helt seperat, og med 100% speedup.
Jeg tror du mener noget a la:
for (i=2; i<1000; i++) { numbers[i] += numbers[i-1];}
Resultatet af hver iteration af loopet afhænger af resultatet af det foregående. Dermed har du så mange dataafhængigheder, at ovenstående løkke ikke kan deles mellem flere kerner ;-)
#1 Ikke på newz, men noget af dataen blev allerede offentligtgjort for et par måneder siden.
http://spectrum.ieee.org/nov08/6912
#6 Uden at have læst andet end kilden (jeg gider ikke finde deres publicerede data når de ikke engang gider smide et DOI) så tror jeg roligt du kan regne med data er beregnet ift. standard. Altså at der er korrigeret for bushastigheden øges som en eller anden funktion af tiden, og at antal kerner er korrigeret efter samme princip. Det eneste der står tilbage i nyheden så, er at memory wall nåes ved >8 kerner ved den nuværende udvikling og at det er her det egentlige udviklingsproblem befinder sig. Ikke i at meningsløst tæske flere kerner i processorne og bare meningsløst efterfølge et "sygt" religiøst mantra som da de bare pumpede frekvensen op.
http://spectrum.ieee.org/nov08/6912
#6 Uden at have læst andet end kilden (jeg gider ikke finde deres publicerede data når de ikke engang gider smide et DOI) så tror jeg roligt du kan regne med data er beregnet ift. standard. Altså at der er korrigeret for bushastigheden øges som en eller anden funktion af tiden, og at antal kerner er korrigeret efter samme princip. Det eneste der står tilbage i nyheden så, er at memory wall nåes ved >8 kerner ved den nuværende udvikling og at det er her det egentlige udviklingsproblem befinder sig. Ikke i at meningsløst tæske flere kerner i processorne og bare meningsløst efterfølge et "sygt" religiøst mantra som da de bare pumpede frekvensen op.
gnarfsan (16) skrev:#13: Det bliver så kompliceret, at sørge for at alle dele af loopet er færdig før man går videre,
Kompliceret? Computerens styrke er vel netop komplicerede ting. ;-)
gnarfsan (16) skrev:Hvad med f.eks. samtidighed? Man skal jo huske at låse, sætte monitors op etc.
Jeg vil lige understrege, at jeg ikke påstår at ALT kan splittes op i maaange tråde. Jeg påstår kun at mange ting som man i dag af den ene eller anden årsag ikke splitter op, vil blive nemt at splitte op i fremtidens sprog.
Men netop samtidighed er en af de ting, vi skal tænke på på en anden måde.
Med mange kerner kan det nogle gange bedre betale sig at beregne det samme flere gange, end at vente på at en anden tråd beregner det én gang for alle. Der slipper vi allerede for nogle samtidighedsproblemer.
Forestil dig fx. 100 elementer der skal behandles. Én tråd beregner element 1-50, en anden tråd beregner 51-100.
Det viser sig, at for at beregne #51, skal man bruge resultatet af #50. Men #50 kan beregnes uafhængigt. Skal tråd 2 så vente på at tråd 1 er færdig, eller skal tråd 2 lige beregne #50, bruge resultatet til beregning af #51, og så smide det ud?
Ja, det er dobbelt-arbejde at beregne #50 2 gange. Men det er da bedre end at kun én tråd arbejder af gangen, og måske bedre end at lave en cache.
gnarfsan (16) skrev:Givetvis vil man kunne lave en virtuel maskine, der kan sørge for alt det, men man kan hurtige ende ud med en, der er så ressourcetung, at man ikke vinder noget.
Gør det noget hvis man fx. bruger 20 kerner udelukkende på at styre de restende 1004 kerner, hvis den er 100 gange hurtigere end 12-kerner?
gnarfsan (16) skrev:Samtidig tilgang af variable kan være et meget komplekst problem.
Ja. Men problemet er ofte helt anderledes i et mange-kernet miljø, end i et mange-trådet miljø med få kerner.
Fra kilden:
"More cores per chip will slow some programs unless there’s a big boost in memory bandwidth."
Det er ligesom at sige, at man bliver fed af sødemidler. (Da man har fundet ud af, at fede mennesker spiser mange sødemidler, så må fedme jo komme af sødemidlerne :(. Årsag -> effekt... ikke omvendt! )
Det er noget komplet sludder, at sige at flere kerner sløver et program. Det ville være rigtigt at sige "Hvis man tror, at man kan dele et hvilket som helst program i N dele, og tro, at programmet så kører N gange så hurtigt, og ikke vide en fjas om programmering, så er man en klaphat!".
Hurra for moderne "forskning" :-D (jaja jeg ved godt, at jeg er en sur gammel mand)
"More cores per chip will slow some programs unless there’s a big boost in memory bandwidth."
Det er ligesom at sige, at man bliver fed af sødemidler. (Da man har fundet ud af, at fede mennesker spiser mange sødemidler, så må fedme jo komme af sødemidlerne :(. Årsag -> effekt... ikke omvendt! )
Det er noget komplet sludder, at sige at flere kerner sløver et program. Det ville være rigtigt at sige "Hvis man tror, at man kan dele et hvilket som helst program i N dele, og tro, at programmet så kører N gange så hurtigt, og ikke vide en fjas om programmering, så er man en klaphat!".
Hurra for moderne "forskning" :-D (jaja jeg ved godt, at jeg er en sur gammel mand)
Izaaq (20) skrev:#13 Ehm forklar mig lige, hvorfor:
for (i=1; i<1000; i++) { numbers[i]++;}
er forskelligt fra:
for (i=1; i<500; i++) { numbers[i]++;}
for (i=500; i<1000; i++) { numbers[i]++;}
Hvad denne diskution angår, er der ingen forskel. Jeg kan til gengæld nævne adskillige problemer med eksempel 2, som ikke er interessante i denne diskution.
Izaaq (20) skrev:Det nederste kan køres på to kerner helt seperat, og med 100% speedup.
Ikke sådan som verden ser ud i dag. Du er nødt til at pakke det ind i noget kode, som opretter tråde osv. Og hvis du skal oprette 1.000 tråde rammer du et hav af problemer. Fx.:
1) En simpel for-loop bliver til noget avanceret noget, som du meget nemt laver fejl i. Ikke noget for den gennemsnitlige programmør.
2) Husk også at håndtere, at du ikke laver flere tråde end du har kerner til rådighed.
3) Husk at holde styr på afhængigheder manuelt. (Giftig!)
Princippet er godt nok, tricket er at lade computeret håndtere det. Du skal blot sige at alle elementerne skal behandles, så klarer afvikleren resten.
Izaaq (20) skrev:Jeg tror du mener noget a la:
for (i=2; i<1000; i++) { numbers[i] += numbers[i-1];}
Resultatet af hver iteration af loopet afhænger af resultatet af det foregående. Dermed har du så mange dataafhængigheder, at ovenstående løkke ikke kan deles mellem flere kerner ;-)
Du forklarer selv, hvorfor det ikke var det jeg mente.
Mit yndlingseksempel på flertrådet programmering:
int a =0;
int b = 0;
Thread 1
{
while (a < maxint)
a++;
}
Thread 2
{
while (b < maxint)
b++;
}
Nogen der vil byde ind med performance vurdering af dette simple program (Og lad nu være med at sige at compileren fjerner løkkerne ;) ). Derudover er &a != &b (Forskellige adresser i memory)
Med vurdering mener jeg self forskel på ekserkvering på en kerne i forhold til flere kerner.
int a =0;
int b = 0;
Thread 1
{
while (a < maxint)
a++;
}
Thread 2
{
while (b < maxint)
b++;
}
Nogen der vil byde ind med performance vurdering af dette simple program (Og lad nu være med at sige at compileren fjerner løkkerne ;) ). Derudover er &a != &b (Forskellige adresser i memory)
Med vurdering mener jeg self forskel på ekserkvering på en kerne i forhold til flere kerner.
er det ikke en lidt fejlvurderet overskrift?
Som jeg ser det, er flere kerner ALTID godt.
At jeg har 100.000.000 kerner, er altid GODT, omend det ikke altid er BEDRE end at have lidt faerre - men hurtigere kerner.. :D
Og allerede nu arbejder de kraftigt paa at forbedre den interne hastighed, saa han skal stoppe med at whine skal han :)
Som jeg ser det, er flere kerner ALTID godt.
At jeg har 100.000.000 kerner, er altid GODT, omend det ikke altid er BEDRE end at have lidt faerre - men hurtigere kerner.. :D
Og allerede nu arbejder de kraftigt paa at forbedre den interne hastighed, saa han skal stoppe med at whine skal han :)
myplacedk (22) skrev:Med mange kerner kan det nogle gange bedre betale sig at beregne det samme flere gange, end at vente på at en anden tråd beregner det én gang for alle. Der slipper vi allerede for nogle samtidighedsproblemer.
Jeg mener samtidig tilgang og opdatering af variable. Det kommer du ikke uden om med flere kerne. Synkroniseringen af mange kerne er komplekst.
myplacedk (22) skrev:Gør det noget hvis man fx. bruger 20 kerner udelukkende på at styre de restende 1004 kerner, hvis den er 100 gange hurtigere end 12-kerner?
Nej men programmet bliver ikke hurtigere end styringen.
#29
Det er jo ogsaa rimeligt meget pointen?
Flere kerner i samme CPU giver fin mening da du kan have en utroligt meget hoejere bandwidth mellem kernerne.
Omvendt giver det ikke saa meget mening at have 2 seperate CPU'er, set ifht. fler-kerne teknologi.
Det skulle da lige vaere cache og den slags, men det kan man jo sagtens forhoeje paa flerkerne systemer. :)
Det er jo ogsaa rimeligt meget pointen?
Flere kerner i samme CPU giver fin mening da du kan have en utroligt meget hoejere bandwidth mellem kernerne.
Omvendt giver det ikke saa meget mening at have 2 seperate CPU'er, set ifht. fler-kerne teknologi.
Det skulle da lige vaere cache og den slags, men det kan man jo sagtens forhoeje paa flerkerne systemer. :)
The cores are all asking for memory through the same pipe. It’s like having one, two, four, or eight people all talking to you at the same time, saying, ‘I want this information.’ Then they have to wait until the answer to their request comes back. This causes delays.James Peery, Sandia
.. eller det samme som hvis man havde 4 eller 8 klunker der alle vil komme på samme tid, men der er kun et rør at deles om. hmm
.. eller det samme som hvis man havde 4 eller 8 klunker der alle vil komme på samme tid, men der er kun et rør at deles om. hmm
Izaaq (30) skrev:#25 En såkaldt race condition. Det kommer man eksempelvis udover ved at holde skæg for sig og snot for sig (læs: hver tråd har sine egne data) og definere en kommunikationsprotokol mellem trådene. Der er sikkert mange andre muligheder.
Godt forsøgt men ikke rigtigt (Eller rettere, ikke det facit jeg ledte efter).
Problemet er at performance kommer an på hvordan compileren smider dit memory sammen.
Hvis a og b, ligger på forskellige cache lines, vil performance boost sikkert være nær 100 %, hvis a og b derimod har fået plads på samme cache line vil det givetvis være en smule langsommere end at køre det hele på samme kerne (men den vil bruge 100% CPU kraft fra begge).
Jeg kan konkludere at mindst 50% af kommentatorerne herinde kan blive ansat i det firma, uden problem.
On topic:
Har det ikke altid været sådan med videnskab generelt? Man skal modbevise en andens teori før at sin egen bliver troværdig.
You can't!
I can, I did!
Oh, ok, but you can't do this!
..
..
On topic:
Har det ikke altid været sådan med videnskab generelt? Man skal modbevise en andens teori før at sin egen bliver troværdig.
You can't!
I can, I did!
Oh, ok, but you can't do this!
..
..
#37
Java er, i form af sin virtuelle koereform, ganske oplagt til flerkerne setups.
Men generelt saa er flere kerner altsaa en fordel.. Jeg kan ikke lige umiddelbart se nogen grund til at det ikke skulle vaere en fordel, overhovedet :)
Crosstalk paa deres memory pipes betyder blot at der skal mere bandwidth imellem jo :P
Java er, i form af sin virtuelle koereform, ganske oplagt til flerkerne setups.
Men generelt saa er flere kerner altsaa en fordel.. Jeg kan ikke lige umiddelbart se nogen grund til at det ikke skulle vaere en fordel, overhovedet :)
Crosstalk paa deres memory pipes betyder blot at der skal mere bandwidth imellem jo :P
#19 nu det jo heller ikk mig der skriver nyhederne, så jeg ku da ikk gi' en skid med hvordan jeg skriver mine kommentare :) Det det handler om er en ordentlig opsat tekst i nyheden, og det tror jeg godt du er klar over ;) Men du sku jo lige spille klassens klovn ye? :D
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