[Sammelthread] offizieller Nehalem-EP Thread

es wird nur non ECC reg ram verwendet seh ich das richtig?
das wäre doch bullshit- was sollen die leute die cpu power und ram brauche machen ? also wo man 128GB+ braucht etc?
und wie sieht es mit den 6cores aus? gibts die auch mit neuer architektur?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hmmm, ist irgendwas bekannt zu SLI support oder so?

Finde den 5520/00 Chipsatz gerade ein wenig doof, kein crossfire/sli, und nur einen richtigen PCI-E 2.0 x16.
 
also Boards mit mehreren PCIe 2.0 16x gibst sehr wohl von Supermicro ... Crossfire sollte da eigentlich kein Problem sein oder hast du irgend wo was gegenteiliges gelesen.

vll kommt noch ein Board mit NF200 Chips drauf das dann auch für SLI freigegeben wird

mfg
 
@ MAFRI
es wird nur non ECC reg ram verwendet seh ich das richtig?
das wäre doch bullshit- was sollen die leute die cpu power und ram brauche machen ? also wo man 128GB+ braucht etc?
und wie sieht es mit den 6cores aus? gibts die auch mit neuer architektur?

Ähmmm, alles klar bei dir? ;) Ist doch alles besser als dieser FB-DIMM Mist, der dir alles wegbrennt. Wieso sollen mit REG ECC Rams nicht mehr als 128GB möglich sein? Und wie viele Zwei-Sockelsysteme verwenden denn überhaupt soviel Ram?

Das Asus Z8PE-D18 zum Beispiel hat 18 DIMM Steckplätze, darin lassen sich 1,2,4GB Module als ECC betreiben, maximal sind jedoch nur 48GB DDR3 ECC möglich. Als Reg ECC sind 1,2,4,8GB nutzbar und somit 144GB.

Ich denke 144GB sollte für die meisten zwei Sockelsysteme gerade so ausreichen. ;)
 
Hmmm, ist irgendwas bekannt zu SLI support oder so?

Finde den 5520/00 Chipsatz gerade ein wenig doof, kein crossfire/sli, und nur einen richtigen PCI-E 2.0 x16.

Wenn du Spiele spielen willst dann hol dir ein Desktop System meinetwegen x58 damit hast du dein Crossfire und SLI.

Es ist und bleibt Tatsache, dass die 5000er, 5400er und 5500/5520 in erster Linie Server Chipsätze sind.

Wegen der Memory Diskussion:

Intel sagt DDR 3 Reg ECC - für den Intel 5520 Chipsatz.

Ähmmm, alles klar bei dir? ;) Ist doch alles besser als dieser FB-DIMM Mist, der dir alles wegbrennt. Wieso sollen mit REG ECC Rams nicht mehr als 128GB möglich sein? Und wie viele Zwei-Sockelsysteme verwenden denn überhaupt soviel Ram?

FB - DIMM ist kein Mist ! FB-DIMM hat einige Vorteile gegenüber normalen DDR2. Zwar nicht unbedingt was die Performance betrifft, aber bei Servern gehts auch um Sicherheit und Zuverlässigkeit und da sind schon ein paar gute Sachen in DDR2 FB-DIMM drin.

Weiterhin geht mit DDR3 REG ECC bis zu 192 GB. (siehe Dell T7500)
 
Zuletzt bearbeitet:
Wenn du Spiele spielen willst dann hol dir ein Desktop System meinetwegen x58 damit hast du dein Crossfire und SLI.

Es ist und bleibt Tatsache, dass die 5000er, 5400er und 5500/5520 in erster Linie Server Chipsätze sind.

Geht mir um Sachen wie Inventor/AutoCAD/3Ds Max rendering, deswegen dachte ich über nen Dual CPU system nach, spielen ist zweit rangig.
SLI / Crossfire kann man auch ohne verkraften (spiele mit dem gedanken: geforce + eine quadro).

Naja hat noch nen halbes Jahr zeit :).
 
Joa okay bei AutoCAD, 3Ds Max da lohnt sich auf jeden Fall Dual Sockel System, weils einfach effektiv schneller geht.

Bei AutoCAD würde ich aber unbedingt eine Quadro nehmen.

Die FX 4800 ist da recht gut.
 
@ xChrizz
FB - DIMM ist kein Mist ! FB-DIMM hat einige Vorteile gegenüber normalen DDR2.
Du verstehst einen aber immer schon mit Absicht falsch, oder? ;)

Keiner hat hier von normalem DDR2 gesprochen und ich wüsste auch nicht warum man das hier in diesem Forumsbereich besprechen sollte?

Das die FB-DIMM Technik jetzt vielleicht nicht die beste Lösung war, lässt sich ja schon daran leicht erkennen, dass die Nehalem Systeme nun auch mit ECC und REG Speicher arbeiten und nicht mit DDR3 FB-Dimms. ;)

Ich denke, allen hier wäre es zu Sockel 771er Zeiten lieber gewesen, DDR2 Reg ECC wie bei den Opteron Systemen zu verbauen, als die höllisch heißen und stromfressenden DDR2 FB-Dimms. Die Sicherheit wäre wohl die gleiche gewesen.

FB-DIMM hat einige Vorteile gegenüber normalen DDR2........aber bei Servern gehts auch um Sicherheit und Zuverlässigkeit

Vielen Dank, da wäre ich ja alleine nie drauf gekommen. ;)

Für die Zukunft bitte genau lesen was gemeint sein könnte, ich denke die meisten anderen haben meine Aussage schon richtig verstanden. Das erspart uns hier unnötige Diskussionen. Es muss nicht immer zusätzlich geschrieben sein was gerade alles nicht gemeint wurde. ;)
Wenn du z.B. FX 4800 schreibst, kannst du in diesem Forumsteil auch erwarten, das die User sofort wissen was du meinst, genauso wie man ahnen kann, dass ich keinen Vergleich zu normalem DDR2 gezogen hab.
 
Da habe ich wirklich eine 30-40% Auslastung über alle 8 Kerne verteilt.
Ohne jetzt eine schön beerdigte Diskussion wiederbeleben zu wollen, aber hier möchte ich kurz drauf hinweisen dass auch ein einzelner Thread mehrere Kerne benutzen kann .. nacheinander halt (er is ja schließlich nicht alleine in der Processing Unit). Durch dieses Core Hopping lässt sich nicht immer ganz einfach erkennen, ob ein Programm nun multithreaded oder nicht (es sei denn es hängt sich fix an einen Kern).
Was jetzt aber nicht heißen soll, dass ich behaupte, GRID wäre nicht multithreadingfähig - das weiß ich nicht und interessiert mich auch nicht, weils bei mir gut läuft.. ;)
 
Ohne jetzt eine schön beerdigte Diskussion wiederbeleben zu wollen, aber hier möchte ich kurz drauf hinweisen dass auch ein einzelner Thread mehrere Kerne benutzen kann .. nacheinander halt (er is ja schließlich nicht alleine in der Processing Unit). Durch dieses Core Hopping lässt sich nicht immer ganz einfach erkennen, ob ein Programm nun multithreaded oder nicht (es sei denn es hängt sich fix an einen Kern).
Was jetzt aber nicht heißen soll, dass ich behaupte, GRID wäre nicht multithreadingfähig - das weiß ich nicht und interessiert mich auch nicht, weils bei mir gut läuft.. ;)

Das "Core Hopping" sollte aber vom gutem OS vermieden werden, denn
dadurch sinkt die Rechenleistung...
 
Das "Core Hopping" sollte aber vom gutem OS vermieden werden, denn
dadurch sinkt die Rechenleistung...
Hmm .. warum? Wegen dem fremden Cache? .. muss ich bei Gelegenheit mal genauer googlen.
Ich weiß nur, dass es bei verschiedenen Anwendungen unterschiedlich ist. Inwiefern das OS mit reinspielt kA. Aber ich denke es wird durchaus in jedem OS Situationen geben können, in denen es Sinn macht einen Thread auf einem andern Core weiterlaufen zu lassen - z. B. wen ein andrer Thread auf einmal den Ursprungscore blockiert. Besser auf nem andern Core weitermachen, als warten bis zum Sankt Nimmerleinstag (in Transistortagen gezählt.. :d ). Aber wie gesagt, muss ich mal genauer googlen, meine Erinnerung an dieses Thema ist sehr verblasst.. ;)
 
Hmmm, ist irgendwas bekannt zu SLI support oder so?

Finde den 5520/00 Chipsatz gerade ein wenig doof, kein crossfire/sli, und nur einen richtigen PCI-E 2.0 x16.

Ne leider so recht noch nicht...
Und ob Crossfire wirklich gehen wird am Ende, steht wohl auch noch in den Sternen...
Beim 5000er Chipsatz ging CF ja auch nicht immer und überall, angeblich soll mein i5000XL kein CF unterstützen. Das XT hingegen schon.
Die 5400er Chipsätze haben wohl auch alle CF Support.

SLI wird aber wohl wenn dann nur in Verbindung mit ner Skulltrail ähnlichen Platform einzug erhalten, wenn es sowas überhaupt geben wird...

Ich denke, allen hier wäre es zu Sockel 771er Zeiten lieber gewesen, DDR2 Reg ECC wie bei den Opteron Systemen zu verbauen, als die höllisch heißen und stromfressenden DDR2 FB-Dimms. Die Sicherheit wäre wohl die gleiche gewesen.

Da hast du wohl recht...
Vor allem die Performance bei Speicherlastigen Anwendungen oder bei Verwendung von Virtuellen Maschinen leidet ein wenig unter der Fehlenden Bandbreite und der hohen Latenz von FB-DIMMs.
Aber es gab ja dann den 5100er Chipsatz mit Reg. ECC DDR2 Unterstützung ;) Wobei bin mir grad nicht ganz sicher, ich glaub der hatte nur 4 Speicherbänke!?

Ohne jetzt eine schön beerdigte Diskussion wiederbeleben zu wollen, aber hier möchte ich kurz drauf hinweisen dass auch ein einzelner Thread mehrere Kerne benutzen kann .. nacheinander halt (er is ja schließlich nicht alleine in der Processing Unit). Durch dieses Core Hopping lässt sich nicht immer ganz einfach erkennen, ob ein Programm nun multithreaded oder nicht (es sei denn es hängt sich fix an einen Kern).
Was jetzt aber nicht heißen soll, dass ich behaupte, GRID wäre nicht multithreadingfähig - das weiß ich nicht und interessiert mich auch nicht, weils bei mir gut läuft.. ;)

IdR sind die Programme der heutigen Zeit schon Threadoptimiert, die Frage ist eher, können diese Thread nebeneinander arbeiten oder müssen sie Permanent auf die Ergebnisse anderer Threads warten.
Und hier liegt der Punkt vor allem bei Spielen...

Und ja Grid kann mit 4 Cores ganz gut was anfangen soweit mir bekannt, aber mit 8 Cores skaliert es eher gar nicht.
Vor allem, wenn man sieht, er schriebt 30-40% Auslastung...
Rechnet man das mal hoch, 50% Auslastung von 8 Cores entsprechen genau 4 Vollausgelasteten Kernen ;)
Von 8 Cores, welche nutzen bringen kann hier also nicht die Rede sein ;)

Das "Core Hopping" sollte aber vom gutem OS vermieden werden, denn
dadurch sinkt die Rechenleistung...

Da hast du recht, aber solange sich die CPU einen einzellnen L3 oder L2 Cache teilt, geht das imho recht passabel.
Schlimm wirds beispielsweise bei Intel mit den pseudo Quads und das ganze am besten noch auf ner Dual CPU Maschine...
Da müssen permanent die Daten aus dem Cache mit über den lahmen Bus...
 
also Boards mit mehreren PCIe 2.0 16x gibst sehr wohl von Supermicro ... Crossfire sollte da eigentlich kein Problem sein oder hast du irgend wo was gegenteiliges gelesen.

mfg

Aber sind das nun PEG Slots oder "normale" x16 Slots?
Das ist wichtig, weil PEG Slots wesentlich mehr Strom liefern können als "normale" Slots!
 
Die grakas haben doch meist eh ne zusätzliche 'externe' versorgung? Dadurch ist das doch egal?
 
Aber sind das nun PEG Slots oder "normale" x16 Slots?
Das ist wichtig, weil PEG Slots wesentlich mehr Strom liefern können als "normale" Slots!

Soweit ich weiß sind alle x16 Slots für max. 75W ausgelegt, also
sollte kein Problem sein. Es gibt nämlich keine anderen Karten mit
x16 außer den Grakas...
 
Die Leistung wird nicht für den Slot bestimmt sondern für die Karten.
LP-Karten sollen nur 10W ziehen.
Normale PCIe Karten 25W und PEG Karten 75W

Aber, der erste(vom Slotblech aus) Abschnitt der PCIe Slots ist für die Spannungsversorgung.
Dieser ist bei ALLEN PCIe gleich. Erst ist für 75W ausgelegt.

Die einzelnen Slots unterscheiden sich nur in der Anzahl der TX und RX Lanes, das wars.

Es gibt in dem Sinne keinen PEG Slot, hardwaretechnisch ist der mit jedem anderen PCIe x16 Slots identisch.
Dieser PEG Slots wird nur vom MB anders bewertet, sonnst nix.

Er wird zwar als "for graphics" betitelt, da es aktuell keine "schnelleren" Karten gibt. Wenn aber in Zukunft mal 100Port SAS Controller kommen sollten (;)), dann werden die darin auch laufen.

EDIT:
Es ist sogar ein x32 vorgesehen, aber nicht als Steckplatz sondern als reiner Link auf dem MB.

Wo wir grad bei PCIe sind.
http://www.cyclone.com/products/expansion_backplanes/index.php
 
Zuletzt bearbeitet:
Und ja Grid kann mit 4 Cores ganz gut was anfangen soweit mir bekannt, aber mit 8 Cores skaliert es eher gar nicht.
Vor allem, wenn man sieht, er schriebt 30-40% Auslastung...
Rechnet man das mal hoch, 50% Auslastung von 8 Cores entsprechen genau 4 Vollausgelasteten Kernen
Von 8 Cores, welche nutzen bringen kann hier also nicht die Rede sein

Da muss ich dich mal etwas korrigieren. Richtig ist, auf 2 Quadcores sind 30-40% Last ca. 80-90% auf einem Quadcore.

Grid ist defintiv multithreaded programmiert. Das auf einem System mit zwei Quadcores alle 8 Kerne gleichzeitig mit "nur" 30-40% ausgelastet werden hat nichts damit zu tun, dass Grid nicht von 2 Quads profitiert.

Es bringt kein Vorteil, das ist richtig.

Aber Tatsache ist, dass Grid nicht so viel CPU Leistung braucht, dass alle 8 Kerne mit 80-90% ausgelastet werden. Und das ist momentan bei allen Games der Fall. Kein Game braucht so viel CPU Power, dass man 2 Quadcores braucht. Dann lieber einen Dualcore auf 4,5 GHz das kommt dann wahrscheinlich besser.

Weiterhin ist ja "nur" eine 8800 GTX drin und da langweilen sich 2 Quadcores um die mit Daten zu vesorgen.

Zum Thema "Core Hopping"

Gibts das Wort überhaupt? Das macht jedes Betriebssystem. Dafür verantwortlich ist der Scheduler im OS Kernel und das ist beabsichtigt. Bei Software die multithreaded programmiert ist, arbeitet Windows so optimal alle verfügbaren Kerne gleichmäßig auszulasten um maximale Resourcen und Skalierbarkeit zur Verfügung zu stellen. Das ist auf keinem Fall ein Nachteil.
 
Durch das "Core-Hopping" soll gewährleistet werden, wenn eine Software zusätzlich Power braucht (peak) diese direkt zur Verfügung gestellt werden kann. Wenn man erst umständlich den Thread auf einen andere Core packen muß, ist das kontraproduktiv.

W2k8 R2 soll dieses Core-Hopping wieder abgeschafft oder eingeschränkt werden. Hier gehts darum, dass man ungenutzte Cores abschaltet um Strom zu sparen. Hoffentlich ist das eine optionale Funktion.
 
Mit Server 2008 R2 wird das nicht abgeschafft. Ich habe damit aus beruflichen Gründen viel zu tun.

Server 2008 R2 hat dieselbe Codebasis und denselben Kernel wie Windows 7 nur mit ein paar anderen Settings.

Das ist genauso wie bei Windows Vista SP1 = Code für Server 2008.

Windows Vista/Server 2008 wechselt schnell die Kerne bzw. CPU´s ständig hin und her. Bei Windows7 / Server 2008 R2 wird am Kernel und besonders am Scheduler ein bisschen was verändert.

Das ändert aber nichts an der Tatsache, dass richtige multithreaded Software trotzdem alle Kernel ausnutzt.

Dazu muss man aber sagen, dass das immer sehr stark auf die Programmierer ankommt. Es gibt Programme die im Vergleich bei Tests zwischen Server 2008 und R2 kaum Performance Vorteile bringen bzw. genau gleich skalieren. Anderen Applications hingegen profitieren spürbar davon, dass am Kernel etwas verändert wurde.

Das Problem ist: Multithreaded Software progammieren ist schwer und gerade bei Endanwender Software wie Games usw. wird da gespart um die Sachen schnell rauszukommen und selbst nach 10 Patches sind diese Spiele immernoch total unsauber programmiert und viel zu schnell auf den Markt gebracht.
 
Zuletzt bearbeitet:
@underclocker2k4:
Thx für die Info, aber ganz so sicher bin ich mir da ehrlich gesagt nicht ob wirklich JEDER PCIe Slot auf jedem Board in der Lage ist, 75W zu liefern.
Das wären bei den üblichen 7 Slots auf nem Board immerhin 525W!
 
Da muss ich dich mal etwas korrigieren. Richtig ist, auf 2 Quadcores sind 30-40% Last ca. 80-90% auf einem Quadcore.

Grid ist defintiv multithreaded programmiert. Das auf einem System mit zwei Quadcores alle 8 Kerne gleichzeitig mit "nur" 30-40% ausgelastet werden hat nichts damit zu tun, dass Grid nicht von 2 Quads profitiert.

Es bringt kein Vorteil, das ist richtig.

Aber Tatsache ist, dass Grid nicht so viel CPU Leistung braucht, dass alle 8 Kerne mit 80-90% ausgelastet werden. Und das ist momentan bei allen Games der Fall. Kein Game braucht so viel CPU Power, dass man 2 Quadcores braucht. Dann lieber einen Dualcore auf 4,5 GHz das kommt dann wahrscheinlich besser.

Weiterhin ist ja "nur" eine 8800 GTX drin und da langweilen sich 2 Quadcores um die mit Daten zu vesorgen.

Du hast mal wieder nicht richtig gelesen... und wiederspricht dir sogar selbst, siehe das "Dicke" :wall:
Wer schreibt bitte, das Grid nicht Multithreaded ist? Kein Mensch...
Ich schrieb oben, das Grid soweit mir bekannt, sogar nutzen aus 4 Cores ziehen kann.

Ändert aber nix an der Tatsache, das Grid nicht von 8 Cores profitiert, und das eine Auslastung von 30-40% auf allen 8 Cores in Summe sogar weniger Leistungbedarf entsprechen würde, als ein gleichgetakteter Quadcore liefern könnte...
Das hat auch nix mit der Grafikkarte zu tun, ob du dort nun ne horn alte 6600GT drin hast oder ein Quad SLI aus 2x295GTXen ist vollkommen egal, die CPU Auslastung bleibt relativ gleich. Die meiste Last die beim Gamen erzeugt wird, kommt vom Game ansich, sprich ist für die Berechnung der Gamedaten verantwortlich, wie KI, Physik Sound usw.
Das bisschen Last, was der Treiber verschlingt um die Grafikkarte mit Daten zu versorgen geht nahezu immer unter...

Und nochmals nein, wenn ein Game threadbasiert aufgebaut ist, sprich mehrere Threads nutzt, heist das lange nicht, das diese auch gleichzeitig abgearbeitet werden können.
Einfaches sinnbildliches Beispiel, du willst Kaffee kochen, und hast folgende Arbeitsschritte:
- Filter in Maschine
- Kaffee in Filter
- Wasser in Maschine
- Kanne in Maschine
- Maschine starten

Wenn du das ganze nun threadbasiert abarbeiten willst, kannst du folgender maßen optimieren:
- du kannst Arbeitsschritt Filter in Maschine gleichzeitig mit dem Arbeitsschritt Wasser in Maschine abarbeiten.
- dann kannst du den Arbeitsschritt Kaffee in Filter gleichzeitig mit dem Arbeitsschritt Kanne in Maschine abarbeiten. (das kann aber erst nach der beendigung der ersten beiden Arbeitsschritte passieren, weil der Kaffee erst in den Filter kann, wenn dieser in der Maschine ist, und du die Kanne ja ebenfalls brauchst um das Wasser in die Maschine zu bringen)

Mehr geht aber nicht zu optimieren.
Mit einer Recheneinheit brauchst du für das Prozedere 5 Arbeitsschritte
Mit 2 Recheneinheiten sind es nur noch 3 Arbeitsschritte, wobei aber beim letzten Arbeitsschritt die zweite Recheneinheit schon nix mehr zu tun hat...
Mit 3 oder mehr Recheneinheiten holst du leider keine Mehrleistung aus dem "Programm"

Aber du könntest mit 4 Recheneinheiten zum Beispiel 2x das ganze machen, hättest also in Summe nicht einen Kaffee in der hälfte der Zeit (zur 2 Recheneinheiten Version) sondern hättest 2 Kaffee in der gleichen Zeit...

Und hier liegt der springende Punkt bei den Games, es gibt vieles, was sich nicht einfach so ohne weiteres parallelisieren lässt, aber man kann mit mehr Recheneinheiten mehr dieser Berechnungen ausführen, sprich zusätzliche Effekte erzeugen.
Es ist und bleibt aber nach wie vor die Pro Core Leistung ein wichtiges Indiz der Spielbarkeit. Wenn diese nicht stimmt geht primär erstmal gar nix...

@underclocker2k4:
Thx für die Info, aber ganz so sicher bin ich mir da ehrlich gesagt nicht ob wirklich JEDER PCIe Slot auf jedem Board in der Lage ist, 75W zu liefern.
Das wären bei den üblichen 7 Slots auf nem Board immerhin 525W!

Kann das Board glaub ich nicht...
Da gabs die Tage schon mal ne Diskusion im Grakaforum drüber...
Irgendwo in den PCIe Spezifikationen steht da was niedergeschrieben, das ein PEG Slot, diese 75W liefern muss.
Aber ein normaler Slot eben nicht. Theoretisch könnte aber soweit mir bekannt die Leistung aber auch aus nen 1x Slot kommen. Weil die Stromanbindung der Slots ja identisch ist.
Aber es scheint da irgendwo noch ne Grenze des machbaren zu geben...
 
Zuletzt bearbeitet:
Die Slots(als die Kartenaufnahme) selber sind für diese 75W ausgelegt, da die überall identisch sind.

(nochmal nachgelesen)
Man hat aber den Standard so aufgeweicht, dass bis x8 nur 25W gezogen werden dürfen. Viel mehr dürfen normale (non Graka) nur 25W ziehen. (LP Karten sogar nur 10W)
Danach richten sich dann auch die Boardhersteller.
Wenn man also ein anständiger Boarddesigner ist, braucht man nur bis 25W planen, denn mehr können die Karten eh nicht ziehen. Alles andere wäre Resourcenverschwendung.
Wobei es auch schwer wird mir non Grakaanwendungen die 75W umzusetzen. Das geht eigentlich nur durch IC ähnlich den Grakas, oder richtige aufgebohrte IOPs.

Fraglich ist die Ausstattung bei Boards wie das P6T6 WS Rev. Dort sind ja 6 mechanische x16 Slots. Aber nur die 3 blauen sind x16 und diese müssen somit die 75W liefern, da ja PEG. Die schwarzen und der Weiße sind ja mit weniger angebunden.

Die Frage ist jetzt, wie hat ASUS das umgesetzt. Denn letztendlich sind hier 300W über die Slots zu ziehen. Aber die SV ist ziemlich weit weg und 300W übers ganze Board zu ziehen halte ich für suboptimal und auch schwer umsetzbar. Die müssen da also einen Kompromis eingegangen sein.
 
Zuletzt bearbeitet:
Durch das "Core-Hopping" soll gewährleistet werden, wenn eine Software zusätzlich Power braucht (peak) diese direkt zur Verfügung gestellt werden kann. Wenn man erst umständlich den Thread auf einen andere Core packen muß, ist das kontraproduktiv.

Also diese Aussage ist Wirr...
Was meinst du mit Software (ein Programm, ein Thread?), woher soll das OS wissen,
ob die Software nur einen Peak braucht oder mehr?
Unter Windof hat mein keine Informationen dazu (bei M$ ist alles perfekt, da läßt
sich nix mehr verbessern, somit braucht man auch keine technischen Informationen
raus zu geben)...
Ich habe auf der Linux-Kernelliste die Diskussion über das CPU-Thread Wechsel
gelesen, es wurden dort auch Tests gemacht und schließlich ist man davon weggegangen
- genauso wie das ständige (neu)zuordnen der IRQ's zu den CPUs...
Denn die CPU's leben heutzutage von Ihren Caches - wenn die nachgeladen werden
müssen (aus dem langsammen Speicher) dann dauert das lange...
 
Wirr?

Ich versuchs mal ausführlicher zu machen.

Nehmen wir mal an, du hast viele viele Threads auf der CPU laufen, mitunter hast du auch Threads die kurzzeitig mehr Power brauchen (peak), wofür auch immer.

Jetzt bauen wir die Threadverwaltung so auf, dass immer erst ein Core "vollgemacht" wird, bevor der nächste "angefangen" wird.
Wenn jetzt ein Thread der mal kurz mehr Power braucht. Dann wird dieser Thread auf einen anderen Core ausgelagert, dass kostet Zeit und erst danach steht die Mehrpower zur Verfügung. = Performanceverlust
(Das geschieht nicht im Vorfeld sondern es wird einfach nur reagiert.)

Wenn man aber die Cores immer gleich auslastet, dann können diese Peak-Threads schneller mit mehr Power versorgt werden, da hier keine Umverteilung stattfindet.

Das Hauptproblem ist hier der Cache. Wenn alle Cores auf ein und den selben Cache zu greifen könnten (L1-L3) dann würde es da minimale Engpässe geben. Das ist aber leider nur beim L3 so und dieser ist doch relativ langsam, aber eine deutlich Verbesserung zu den ersten DC und QC.
 
Zuletzt bearbeitet:
Also diese Aussage ist Wirr...
Was meinst du mit Software (ein Programm, ein Thread?), woher soll das OS wissen,
ob die Software nur einen Peak braucht oder mehr?
Unter Windof hat mein keine Informationen dazu (bei M$ ist alles perfekt, da läßt
sich nix mehr verbessern, somit braucht man auch keine technischen Informationen
raus zu geben)...
Ich habe auf der Linux-Kernelliste die Diskussion über das CPU-Thread Wechsel
gelesen, es wurden dort auch Tests gemacht und schließlich ist man davon weggegangen

Wenn man Windoof schreibt, disqualifiziert man sich schon mal im voraus, weil jeder davon ausgeht, dass es sowieso nur in eine Richtung geht.

Unter Linux wird auch nicht nur ein Kern ausgelastet. Ich weiss nich wer sowas erzählt oder ob du das in der LKML falsch verstanden hast. Linux verhält sich bei multithreaded Server Anwendungen fast genauso wie der Windows Kernel.

Da wird genauso "Core hopping" betrieben wie bei Windows, weil das vom Scheduler ausgeht und der Scheduler sich danach richtet wie das Programm prorgammiert ist.

Vergleich mal die Performance von Oracle Datenbanken oder SPEC Benchmarks zwischen Windows & Linux. Da ist so gut wie kein Unterschied.. beide Systeme erreichen dieselbe Performance.

Weiterhin ist bei Microsoft nicht alles geheim. Die Funktionsweise des Schedulers die ganzen Schnittstellen kannst du alle bei MSDN einsehen.

Lediglich der Source Code ist bei Closed Software geheim, nicht jedoch die Funktionsweise und die ganzen Schnittstellen die Microsoft den Developern zur Verfügung stellt.
 
Wo wir grad dabei sind, kann ich mir bei WIN für die einzelnen Prozesse die Coreaufteilung anzeigen lassen? Vorzugsweise im TM.
 
Wo wir grad dabei sind, kann ich mir bei WIN für die einzelnen Prozesse die Coreaufteilung anzeigen lassen? Vorzugsweise im TM.

Du meinst mit TM Taskmanager?

Die Coreaufteilung in wiefern? Windows erkennt alles als CPU´s.. CPU0,1,2,3,4 usw.


Wenn du im Task Manager auf View > Select Columns gehst kannst du auswählen was du alles sehen willst.

u.a. z.B. auch die Threads. Schau selbst, das alles hier aufzuführen würde jetzt den Rahmen sprengen.

Zur Coreaufteilung: Ich weiss nicht was du damit meinst, prinzipiell arbeitet Windows so, dass jeder Prozess jeden Core bzw. jede CPU die im System eingebaut ist benutzen kann. Wenn du also einen Quadcore mit 4 CPU´s hast kann ein Windows Prozess (Programm) jede CPU0,1,2 & 3 by default ansprechen und je nach Last und abhängig vom Scheduler benutzen.

Der Scheduler teilt dem Prozess standardmäßig zu auf welcher CPU er die Anwendung rechnen lässt.

Wenn man das nicht will und sagst ich habe ein Programm und will damit nur einen oder zwei Cores nutzen...

Dann geh im Task Manager auf Prozesse und dann auf > Rechtsklick (des jeweiligen Prozesses) und dann Set Affinity und dann kannst du dem Programm die CPU´s beliebig zuweisen wie du gerade lustig bist oder es haben willst.
 
Zuletzt bearbeitet:
Möchte halt gerne sehen, welche Core ein Prozess grad in Anspruch nimmt.

zB svchost ist grad auf core x, y und z so und so stark aktiv.

Die Möglichkeiten die ich im TM (ja Task Manager) bisher gefunden haben geben das nicht preis.

EDIT:
Wenn zB ein bestimmter Core stark ausgelastet ist, kann man daran erkennen, welcher Prozess dafür verantwortlich ist, um so zB das Nutzungsverhalten diesen Prozesses zu erkennen. (also Takt basiert oder Core basiert)
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh