mboost-dp1
unknown
4 af dem tak.. :P
det var sku ikke så lidt... torede jeg faktisdk ikke var muligt, at man kunne få windows til at håndtere mere end 2 proccesore af gangen.. :P
det var sku ikke så lidt... torede jeg faktisdk ikke var muligt, at man kunne få windows til at håndtere mere end 2 proccesore af gangen.. :P
Synes det er rigtig fedt at de har kunne lave sådanne noget... vil spare masser af plads i maskinen.. :P
vil garanteret også hjælpe firma'erne meget bedre!!
vil garanteret også hjælpe firma'erne meget bedre!!
Jeps helt sikkert.... nu kan alle firmaer få en masse computerkraft til deres servere uden at skulle punge ud i lange baner...
Gnoby
Gnoby
Fuuuhuuuuck det kunne være svedigt med "16" aktive processorer i WinXP :-P Så tror jeg ikke man nærmer sig ventetid hvis resten af maskinen også er i top :-D
Hvad med dual-core Xeon?
"De mange transistorer skyldes sandsynligvis primært at Montecito har 24MB L1 cache onboard ..."
Sandsynligvis? 24MB SRAM koster 1,2 mia. transistorer. så er der 500 mio. til to CPU'er, arbitrator og buslogik.
"De mange transistorer skyldes sandsynligvis primært at Montecito har 24MB L1 cache onboard ..."
Sandsynligvis? 24MB SRAM koster 1,2 mia. transistorer. så er der 500 mio. til to CPU'er, arbitrator og buslogik.
#7: Win2k3 Datacenter Edition understøtter 64 CPU'er
Tjek evt. http://www.microsoft.com/windowsserver2003/evaluat...
Tjek evt. http://www.microsoft.com/windowsserver2003/evaluat...
Er hyperthreading så egentlig ikke en dårlig idé? Du ender jo med kun at kunne købe 32 cpu'er(:P). Og være bundet af HT. Vil da også se hvad de så kommer til at gøre med desktopversionen og XP
Og så er det ikke 24MB L1. Hver kerne har sin egen sæt af cache. L1 16kB, L2 1280kB og L3 12MB, det koster 668 mio. transistorer pr. CPU hvilket efterlader 365 mio. til deling mellem 2xCPU og arbitrator og bus logik.
#8: 24MB SRAM koster 1,2 mia. transistorer.
Jeg må indrømme, at jeg ved ikke præcis hvor mange transistorer, der skal til en SRAM celle, men 6 lyder ikke helt ved siden af. Men cache RAM skal jo helst være associativ, kommer det så ikke til at kræve lidt flere transistorer?
(I øvrigt er betegnelsen onboard vist ikke helt rigtig)
Jeg må indrømme, at jeg ved ikke præcis hvor mange transistorer, der skal til en SRAM celle, men 6 lyder ikke helt ved siden af. Men cache RAM skal jo helst være associativ, kommer det så ikke til at kræve lidt flere transistorer?
(I øvrigt er betegnelsen onboard vist ikke helt rigtig)
hvis man har 2 cpu'er med HT så windows ser dem som 4, er der så ikke en chance for at 2 tråde som bliver afviklet samtidigt kan vi blive udført på den ene cpu da OS ser den som 2. hvorimod hvis cpu'erne ikke har HT, vil de 2 tråde altid blive afviklet på hver sin cpu
#6 Dee_Kay
[Fuuuhuuuuck det kunne være svedigt med "16" aktive processorer i WinXP :-P Så tror jeg ikke man nærmer sig ventetid hvis resten af maskinen også er i top :-D]
Smuk tanke som jeg selv har tænkt.
Men du har en stor flaskehals i din computer, ved væsentligt færre cpu kræfter end den der.
Mit spring fra 2500+ til 3200+ gav mig stortset intet, før jeg skiftede til en hurtigere disk... ;)
[Fuuuhuuuuck det kunne være svedigt med "16" aktive processorer i WinXP :-P Så tror jeg ikke man nærmer sig ventetid hvis resten af maskinen også er i top :-D]
Smuk tanke som jeg selv har tænkt.
Men du har en stor flaskehals i din computer, ved væsentligt færre cpu kræfter end den der.
Mit spring fra 2500+ til 3200+ gav mig stortset intet, før jeg skiftede til en hurtigere disk... ;)
9: Ja ok, kunne ikke lige huske det - har muligvis 'kun' været 16 eller 32 med 2000 Datacenter? Ikke så tit jeg lige checker må jeg erkende.
Montecito har 24MB L1 cache onboard
Øhm jeg har læst en del andre steder at det er 24 megabyte level 3 og der er jo rimlig stor forskel på level 1 og level 3
Øhm jeg har læst en del andre steder at det er 24 megabyte level 3 og der er jo rimlig stor forskel på level 1 og level 3
Hvad jeg lige hurtigtkan huske, understøtter WinNT 64 cpu'er men det er selvfølgelig ved at være nogen år siden jeg så på det :)
og man kan så heller ikke bruge det information til det helt store.
og man kan så heller ikke bruge det information til det helt store.
Hmmm, nogle forslag til hvad man om muligt kunne bruge 4 CPU'er til, hvis man ikke regner servere med?
Man skal altså være pænt syg med Alt+tab hvis man skal bruge 4 CPU'er.
Dual CPU'er kan jeg godt se idéen i, da 2xCPU = dobbelt power, og kan behandle to processer af gangen, men når en HT CPU også kan, hvad er så idéen i dual HT CPU?
Man skal altså være pænt syg med Alt+tab hvis man skal bruge 4 CPU'er.
Dual CPU'er kan jeg godt se idéen i, da 2xCPU = dobbelt power, og kan behandle to processer af gangen, men når en HT CPU også kan, hvad er så idéen i dual HT CPU?
#28 enkelt, så kan den behandler 4 processer ad gangen. Du skal huske på at HT faktisk kun viser sin fordel hvis programmet er skrevet direkte til HT.
Og selv når det er, plejer det "boost" at være så minimalt at det er intet i forhold til at 2 cpu'er. Tror måske du kunne have noget á la. HT0 til baggrundprocesser, HT1 til fx Folding@Home. Og dine cpu'er som knusere når der arbejdes hårdt.
Er dog mere interesseret i Hypertransport
Og selv når det er, plejer det "boost" at være så minimalt at det er intet i forhold til at 2 cpu'er. Tror måske du kunne have noget á la. HT0 til baggrundprocesser, HT1 til fx Folding@Home. Og dine cpu'er som knusere når der arbejdes hårdt.
Er dog mere interesseret i Hypertransport
#27
Det er vist også min hukommelse der er noget galt med, men det understøtter faktisk 32 cpu'er
http://www.systelusa.com/faq.html
det er godt nok server udgaven, men den understøtter 32 :)
Det er vist også min hukommelse der er noget galt med, men det understøtter faktisk 32 cpu'er
http://www.systelusa.com/faq.html
det er godt nok server udgaven, men den understøtter 32 :)
#13 er der så ikke en chance for at 2 tråde som bliver afviklet samtidigt kan vi blive udført på den ene cpu da OS ser den som 2.
Jo, det er der en risiko for, hvis ikke OS tager højde for HT. Og det er bare et af mange potentielle problemer, man skal overveje, når man laver en kerne til et HT system. Der er forskel på SMP og HT, og i mange situationer bør kernen træffe forskellige valg i de to situationer. Kombinationen med flere HT CPUer er naturligvis mere compliceret, og stiller nogle krav til kernen for at opnå god performance. På tidlige kerner har man da også ofte kunnet opnå bedre performance ved at slå HT fra.
Når en SMP kerne skal vælge hvilken process en given CPU skal afvikle opnås bedst performance, hvis den kan vælge en process der sidst har kørt på samme CPU. Det skyldes at den har større chance for at allerede have relevante data i cachen. Med en HT maskine gør det ingen forskel, da de to virtuelle CPUer deler cache.
Når der bruges en kombination bliver situationen mere compliceret. På den ene side har du muligvis relevante data i cachen på den ene CPU, men hvis den ene virtuelle CPU allerede er i brug vil det nok alligevel være bedre at vælge en anden fysisk CPU. Og når man kigger hvilken CPU en process sidst har kørt på skal man kun kigge på hvilken fysisk CPU og ikke hvilken virtuel CPU.
Med SMP vil man normalt forsøge at holde alle CPUer beskæftiget hele tiden, hvis man da ellers har processer nok. Men på HT er det ikke altid et fornuftigt valg. Har du to processer med forskellig prioritet kan en dual CPU maskine afvikle dem på hver sin CPU, og de vil begge køre med fuld hastighed (hvis blot busen kan følge med). Men med en enkelt HT CPU er det ikke så god en idé at lade dem køre samtidig, fordi de skal deles om resourcerne. Processen med den lave prioritet vil dermed sløve den anden process meget ned. Faktisk må man forvente at de to processer får lige mange resourcer, da valgene nu træffes af hardwaren, og kernen har ikke mere noget at skulle have sagt.
En løsning på problemet er, at man noget af tiden lader processen med den højere prioritet køre alene og lader den anden virtuelle CPU være idle. Dermed udnyttes de samlede resourcer ikke lige så godt, men den vigtige process får mere CPU tid.
Hvis man har en HT maskine og kører med en kerne uden særlig god support for HT, så bør man nok ikke begynde at køre ting som seti@home, da de kan sløve systemet mere ned end de burde have gjort.
Jo, det er der en risiko for, hvis ikke OS tager højde for HT. Og det er bare et af mange potentielle problemer, man skal overveje, når man laver en kerne til et HT system. Der er forskel på SMP og HT, og i mange situationer bør kernen træffe forskellige valg i de to situationer. Kombinationen med flere HT CPUer er naturligvis mere compliceret, og stiller nogle krav til kernen for at opnå god performance. På tidlige kerner har man da også ofte kunnet opnå bedre performance ved at slå HT fra.
Når en SMP kerne skal vælge hvilken process en given CPU skal afvikle opnås bedst performance, hvis den kan vælge en process der sidst har kørt på samme CPU. Det skyldes at den har større chance for at allerede have relevante data i cachen. Med en HT maskine gør det ingen forskel, da de to virtuelle CPUer deler cache.
Når der bruges en kombination bliver situationen mere compliceret. På den ene side har du muligvis relevante data i cachen på den ene CPU, men hvis den ene virtuelle CPU allerede er i brug vil det nok alligevel være bedre at vælge en anden fysisk CPU. Og når man kigger hvilken CPU en process sidst har kørt på skal man kun kigge på hvilken fysisk CPU og ikke hvilken virtuel CPU.
Med SMP vil man normalt forsøge at holde alle CPUer beskæftiget hele tiden, hvis man da ellers har processer nok. Men på HT er det ikke altid et fornuftigt valg. Har du to processer med forskellig prioritet kan en dual CPU maskine afvikle dem på hver sin CPU, og de vil begge køre med fuld hastighed (hvis blot busen kan følge med). Men med en enkelt HT CPU er det ikke så god en idé at lade dem køre samtidig, fordi de skal deles om resourcerne. Processen med den lave prioritet vil dermed sløve den anden process meget ned. Faktisk må man forvente at de to processer får lige mange resourcer, da valgene nu træffes af hardwaren, og kernen har ikke mere noget at skulle have sagt.
En løsning på problemet er, at man noget af tiden lader processen med den højere prioritet køre alene og lader den anden virtuelle CPU være idle. Dermed udnyttes de samlede resourcer ikke lige så godt, men den vigtige process får mere CPU tid.
Hvis man har en HT maskine og kører med en kerne uden særlig god support for HT, så bør man nok ikke begynde at køre ting som seti@home, da de kan sløve systemet mere ned end de burde have gjort.
For folk der undre sig over hvordan Intel kan presse 1720 millioner transistorer ned i en 90nm CPU, har Anandtech en artikel fra dag #2 på IDF
Billede af selve kernen kan ses her.
Billede af selve kernen kan ses her.
LOL prøv at se her:
http://www.theinquirer.net/?article=18348
Det bliver sq en satan på over 150+ watt.
http://www.theinquirer.net/?article=18348
Det bliver sq en satan på over 150+ watt.
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