mboost-dp1
unknown
Bah, hader kerner..
Så sidder man lige og spiser en eller anden frugt, og så er der krafedme kerner INDENI FRUGTEN!?! Hvor faen kom dé fra, spørger jeg bare..
Så sidder man lige og spiser en eller anden frugt, og så er der krafedme kerner INDENI FRUGTEN!?! Hvor faen kom dé fra, spørger jeg bare..
#1
"Hvor faen kom dé fra, spørger jeg bare.."
Hvad står der på skrallen, Intel eller AMD?
Hvor mange kerner var der?
"Hvor faen kom dé fra, spørger jeg bare.."
Hvad står der på skrallen, Intel eller AMD?
Hvor mange kerner var der?
Jeg værdsætter AMD's og Intels innovation, men jeg mener, at vi lige nu har væsentlige problemer med at afvikle al den ydelse, som flerkernede processorere skaver. Men... Burde AMD ikke prioritere udnyttelsen af ydelsen højere end skabelsen af nye variationer af deres flerkernede processorer? Umiddelbart synes jeg, at det er ret ulogisk, når vores software er enkelt-strenget og har svært ved at udnytte de ekstra kerner og ekstra kraft.
#4 Kan godt følge dig, men uden hardware kan vi vel ikke udvikle bedre concurrency-modeller og software der implementerer disse? Fakta er jo at vi har meget ringe erfaring og akedemia omkring et så tæt-koblet distribueret system. IBM's Cell CPU forventes f.eks. ikke udnyttet til fulde før om 4-5 år.
Desuden har jeg pt. 42 processer der nyder godt af at kunne sceduleres på mere end én kerne.
Desuden har jeg pt. 42 processer der nyder godt af at kunne sceduleres på mere end én kerne.
#4 Sådan som jeg har opfattet det, bunder det i at de ikke rigtig har mulighed for at skalere dem helt vildt højt op, så for stadig at holde liv i produktionen så smider de nogle flere kerner i. P4 kunne jo f.eks. ikke skaleres til 10GHz som var planen, ja faktisk ikke engang 4GHz, så bliver de jo nødt til at presse citronen på en anden måde.
Det er en opteron som kommer med 4 kerner. En server processor. som regel kører disse mange programmer på samme tid, og/eller mange kopier af samme program fordi der er mange netværks forbindelser til servere. Derfor fungerer 4 kerner fint.
Desuden er det langt de færreste som i dag kun kører et program af gangen. Men jo, det ville da være bedre med en kerne som er helt vildt frisk.
Faktum er vel at det med flere kerne for tiden er den letteste metode til at øge performance. Specielt for AMD der bruger hypertransport.
Desuden er det langt de færreste som i dag kun kører et program af gangen. Men jo, det ville da være bedre med en kerne som er helt vildt frisk.
Faktum er vel at det med flere kerne for tiden er den letteste metode til at øge performance. Specielt for AMD der bruger hypertransport.
#7 Hvad har hypertransport med CPU'en og dens processer at gøre? Hypertransport bruges hverken når kerner skal snakke med hinanden eller memmory skal tilgås, dertil benyttes en crossbar-switch.
#4
Din counterstrike-computer har sikkert ikke meget med målgruppen for QuadCore Opteron at gøre. Derimod kan det faktisk godt tænkes at en del af målgruppen kunne udgøres af spil-servere :)
Hit med flere cores! og igang med noget mere virtualisering! og det kan kun gå for langsomt. :)
// haj
Din counterstrike-computer har sikkert ikke meget med målgruppen for QuadCore Opteron at gøre. Derimod kan det faktisk godt tænkes at en del af målgruppen kunne udgøres af spil-servere :)
Hit med flere cores! og igang med noget mere virtualisering! og det kan kun gå for langsomt. :)
// haj
#4,
Der er masser af applikationer som kan udnytte mange kerner.
Server applikationer: databse servere, applikation servere,
web servere, fil servere.
Selv banale desktop apps såsom browser, email program og
tekstbehandling bruger flere tråde nu om dage.
(omend fordelen nok ikke er så stor som ved server applikationer
og slet ikke med mere end 2 kerner)
Den største mangel for fler kerne processorer er nok på
spil med god support for det, men de skal nok komme når både
Intek og AMD satser på det.
Der er masser af applikationer som kan udnytte mange kerner.
Server applikationer: databse servere, applikation servere,
web servere, fil servere.
Selv banale desktop apps såsom browser, email program og
tekstbehandling bruger flere tråde nu om dage.
(omend fordelen nok ikke er så stor som ved server applikationer
og slet ikke med mere end 2 kerner)
Den største mangel for fler kerne processorer er nok på
spil med god support for det, men de skal nok komme når både
Intek og AMD satser på det.
#12 Det kommer vel an på niveauet vi taler om. Software i user-space kan naturligvis skrives med distribution som et led i at optimere til SMP-miljøer. Her vil der ikke ske mange ændringer, udover at SMP software nu inkluderer en meget bredere vifte af programmel og en vis del af dette programmel er relativt uafprøvet i SMP sammenhæng. Her tænker jeg især på multimedia og spil.
Men længere nede, i ring-0/kernel-mode hvor scheduleren opererer bliver det jo mindst lige så interesant (og besværligt). Til forskel fra ældre SMP systemer med en langsom FSB imellem sig, kan kernerne nu kommunikere internt over en hurtig crossbar-switch og enddog tilgå og forhandle omkring en shared dynamisk L2 cache. Dette giver nogle nye muligheder for at optimere enddog før branch-predicteren får smidt instruktioner i sin pipeline.
Men længere nede, i ring-0/kernel-mode hvor scheduleren opererer bliver det jo mindst lige så interesant (og besværligt). Til forskel fra ældre SMP systemer med en langsom FSB imellem sig, kan kernerne nu kommunikere internt over en hurtig crossbar-switch og enddog tilgå og forhandle omkring en shared dynamisk L2 cache. Dette giver nogle nye muligheder for at optimere enddog før branch-predicteren får smidt instruktioner i sin pipeline.
#13
Udenfor x86 verdenen har man stadig haft MP systemer i mange år
uden "FSB begrænsning".
Og jeg kan ikke se hvorfor flere kerner per socket heller ikke med
hurtigere interconnection og shared L2 cache skulle gøre at man
ville skrive kernel mode software anderledes.
Hvad vil du skrive anderledes ?
Udenfor x86 verdenen har man stadig haft MP systemer i mange år
uden "FSB begrænsning".
Og jeg kan ikke se hvorfor flere kerner per socket heller ikke med
hurtigere interconnection og shared L2 cache skulle gøre at man
ville skrive kernel mode software anderledes.
Hvad vil du skrive anderledes ?
#15 Scheduleren! Mener du seriøst at scheduleren ikke behøver være bevidst med hvor løst/tæt koblet de er forbundet? Med en tråd på et MP board med dual-kerner giver det alt andet lige mening, at lade en forket tråd med shared memory schedulere på samme CPU frem for på en anden. Nu ved jeg ikke specifikt hvilke non-x86 MP systemer du tænker på.
#18
Problemet med scheduleren er omvendt. For et MP system med
separat cache skal man implementere soft CPU affinity for
at få god performance. For et system med shared cache
behøver man ikke goere noget.
Men jeg tror ikke engang at de vil fjerne soft affinity. Fordi
Intel producerer multi core CPU'er med separat cache og
multi core CPU'er fra både Intel og AMD skal vel også bruges
i multi socket sammenhæng.
Problemet med scheduleren er omvendt. For et MP system med
separat cache skal man implementere soft CPU affinity for
at få god performance. For et system med shared cache
behøver man ikke goere noget.
Men jeg tror ikke engang at de vil fjerne soft affinity. Fordi
Intel producerer multi core CPU'er med separat cache og
multi core CPU'er fra både Intel og AMD skal vel også bruges
i multi socket sammenhæng.
Intel's Core benytter sig, modsat den frygtelige Prescott, af shared cache. Pentium D var jo ikke andet end 2 logiske CPU'er i samme fysiske hus, de skulle stadig over FSB'en for at udveksle data.
Med Core kernerne er det dog anderledes, de kan sågar forhandle indbyrdes omkring fordelingen af de 2/4MB cache.
Med Core kernerne er det dog anderledes, de kan sågar forhandle indbyrdes omkring fordelingen af de 2/4MB cache.
Jeg kan huske for en 4-5 år siden, at SUN var rasende
over en SPEC benchmark af en IBM pSeries box.
De har L3 cache. Den pågældende box var en 8 CPU box
med 128 MB L3 cache.
Da der blev kørt en single stream test, så performede den
box fantastisk.
Fordi den ene aktive CPU hapsede alle 128 MB L3 cache og de
fleste af benchmark testene kunne ligge i den, så de kunne
køres dem uden RAM access overhovedet.
over en SPEC benchmark af en IBM pSeries box.
De har L3 cache. Den pågældende box var en 8 CPU box
med 128 MB L3 cache.
Da der blev kørt en single stream test, så performede den
box fantastisk.
Fordi den ene aktive CPU hapsede alle 128 MB L3 cache og de
fleste af benchmark testene kunne ligge i den, så de kunne
køres dem uden RAM access overhovedet.
#20 "Den frygtelige prescott"
Det er faktisk en ganske udemærket CPU. Min maskine indeholder en 3.0GHz Prescott med HT. Den ligger i "tomgang" på ca. 40 grader C og belastet på ca. 50 grader C, trods den er oc til 3.3GHz. Den er tænt 24-7-365... går aldrig ned og yder ok. -Mit nVIDIA gfx bliver meget varmere!
Det er faktisk en ganske udemærket CPU. Min maskine indeholder en 3.0GHz Prescott med HT. Den ligger i "tomgang" på ca. 40 grader C og belastet på ca. 50 grader C, trods den er oc til 3.3GHz. Den er tænt 24-7-365... går aldrig ned og yder ok. -Mit nVIDIA gfx bliver meget varmere!
der er en ganske væsentlig årsag til at lave multi-core cpu'er - og den bunder i økonomi.
Virksomheder betaler rent faktisk ofte deres licenser, og database software koster ganske pæne beløb, og som en tidligere har skrevet, så finder de store maskiner ofte anvendelse som database eller applikationsservere.
Et lille regnestykke, baseret på at MS SQL Server Enterprise edition koster ~160.000 afhængigt af rabatter.
4 x 1 cpu = 640.000,-
1 x 4 core cpu = 160.000,-
Med Oracle Enterprise edition, med RAC og Partitioning options
4 x 1 cpu = 280.000 USD
1 x 4 core cpu = 140.000 USD
Så alt i alt kan man håbe på at få afsat sin cpu bedre end konkurrenterne, fordi man er billigere i forhold til licenserne. Og for virksomheder, er det ikke cpu'en der er den store omkostning ;)
Virksomheder betaler rent faktisk ofte deres licenser, og database software koster ganske pæne beløb, og som en tidligere har skrevet, så finder de store maskiner ofte anvendelse som database eller applikationsservere.
Et lille regnestykke, baseret på at MS SQL Server Enterprise edition koster ~160.000 afhængigt af rabatter.
4 x 1 cpu = 640.000,-
1 x 4 core cpu = 160.000,-
Med Oracle Enterprise edition, med RAC og Partitioning options
4 x 1 cpu = 280.000 USD
1 x 4 core cpu = 140.000 USD
Så alt i alt kan man håbe på at få afsat sin cpu bedre end konkurrenterne, fordi man er billigere i forhold til licenserne. Og for virksomheder, er det ikke cpu'en der er den store omkostning ;)
#23 Den kommer du lige til at forklare. Oracle ændrede i 2005 deres forrykte licenspolitik, til at tælle individuelle kerner som en alm. CPU dog med en faktor på 0.75. Dvs. din beregning er forkert:
1 x 4 core CPU x .75= 1 x USD $70.000 x .75 = USD $210.000
...før denne justering, skulle du betale fuld CPU pris for hver kerne!
1 x 4 core CPU x .75= 1 x USD $70.000 x .75 = USD $210.000
...før denne justering, skulle du betale fuld CPU pris for hver kerne!
#26
Haha, ja, men de er desværre rimeligt vilde med deres ændringer
1 single core cpu = 1 cpu licens
1 core i en intel/amd cpu = 0.5 cpu licenser
1 core i en IBM cpu = 1 cpu licens
1 core i en sun cpu = 0.75 cpu licenser med undtagelse af
1 core i en sun niagara cpu = 0.25 cpu licenser
så ja, min beskrivelse ovenfor skulle have beskrevet at det var specifikt for AMD cpu'er.
Haha, ja, men de er desværre rimeligt vilde med deres ændringer
1 single core cpu = 1 cpu licens
1 core i en intel/amd cpu = 0.5 cpu licenser
1 core i en IBM cpu = 1 cpu licens
1 core i en sun cpu = 0.75 cpu licenser med undtagelse af
1 core i en sun niagara cpu = 0.25 cpu licenser
så ja, min beskrivelse ovenfor skulle have beskrevet at det var specifikt for AMD cpu'er.
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