CPU Leistung seit 2600k stagnierend?

Ich sag mal so, wenn die Software nicht in der Lage ist, die Threads entsprechend gleichzeitig auszufahren, kann man auch nix sehen... Logisch.
Ändert aber nix an der Tatsache, dass das: "da er nicht genutzt werden kann. Stichwort NUMA" eben Unsinn ist...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"Genutzt" war wohl tatsächlich der falsche Ausdruck, es gibt aber keine Spiele die Numa affin entwickelt werden, warum auch?

Daher wird die Leistung wohl (stark) verringert wenn Prozesse zwischen den CPUs hin und her geschoben werden.

Gesendet von meinem A0001 mit der Hardwareluxx App
 
Das kannst du mit 2 Dual Cores ja testen :)

Am Ende ist es wie bei Grafikkarten, eine CPU mit mehr Leistung ist besser als 2.
 
Die letzten dual CPU fähigen 2-Kern CPUs waren die Xeons auf Core2 Basis, da gibts eh nur einen Speichercontroller.

Edit:
OK krass, es gibt sogar Zweikern Sandy-EP Xeons...
Nichtsdestotrotz geht nen Haufen Leistung verloren wenn Prozesse vom einen auf den anderen Speichercontroller verschoben werden

Gesendet von meinem A0001 mit der Hardwareluxx App
 
Zuletzt bearbeitet:
Dann muss man eben 1366 oder 2011 nehmen, gott, ohne Aufwand geht es halt nicht.
 
Die kleinsten Xeons für den S. 2011-3 haben schon je 4 Kerne womit der Test schwer wird, zumal die meisten Spiele kaum mehr als diese 4 Kerne auslasten werden.
Stimmt. Aber zu Testzwecken kann man die Anzahl der Cores im BIOS reduzieren - bei den meisten mir bekannten 2x So. 2011-3 Brettern geht das.
Ansonsten: Nach meiner Erfahrung sind context switches nicht sooo schlimm, wie es hier beschrieben wird. Durch Festlegen von Affinities kann man nur einen geringen Leistungszuwachs (nach meinen Messungen um 1%) erzielen.
 
Ich seh prinzipiell kein Problem darin mit zig Kernen flüssig zu zocken, es muss halt nur klar sein dass das Ergebnis nicht besser sein wird als mit 4 Kernen.
Seh ich ja bei mir am 3930k, nur wenige Games schaffen es die CPU zu mehr als 25% auslasten, GTA V z.B. schafft stellenweise 40-50%.
D.h. von 6 Kernen / 12 Threads liegen meistens 3/4 brach.

Was mir mehr Sorgen machen würde als die NUMA Thematik ist dass es Software gibt die wenn sie 32 Threads aufwärts sieht einfach abstürzt.
Beim Kollegen haben wir deshalb auf dem System mit 2x 8-Core HT deaktivieren müssen weil AutoCAD sonst reproduzierbar abstürzt.

Gesendet von meinem Nexus 5 mit der Hardwareluxx App
 
"Genutzt" war wohl tatsächlich der falsche Ausdruck, es gibt aber keine Spiele die Numa affin entwickelt werden, warum auch?

Daher wird die Leistung wohl (stark) verringert wenn Prozesse zwischen den CPUs hin und her geschoben werden.

Das kann man so pauschal nicht sagen... Es hängt von vielen Faktoren ab, Software, die wenig Cache/Speicherlastig ist, wird sich davon weitestgehend unbeeindruckt zeigen. Kommt dann noch hinzu, das die "Workerthreads" mehr oder weniger unabhängig von einander arbeiten, dürfte der Nachteil effektiv gegen Null gehen.
Warum? Anwendung fordert Rechenzeit von der CPU durch lasterzeugende Threads, das OS schubst diese auf die CPUs los, die CPUs rechnen und irgendwann kommt ein Ergebnis hinten raus, dann wird der Thread terminiert und ggf. ein anderer/neuer dafür aufgemacht -> und weiter gehts.
Anders schaut das bei Software aus, die Threads sehr lange am Leben hält, wo große Datenmengen durch die Caches fließen und vor allem, wo die Threads starke Abhängigkeiten zueinander haben. NUMA ist ja nicht "nur" Speicher vom anderen Prozessor. Real geht es ja dabei gerade auch um Cachezugriffe. Wenn ich da mal keine Ahnung, 20MB L3 Cache Inhalt "benötige", die aber auf nem anderen Prozessor im Cache liegen, muss entweder über den langsameren Interconnect zugegriffen werden oder die Software holt die Daten in den eigenen Cache.
Sinnvollerweise sollte man, wenn man solche Systeme ansprechen möchte, möglichst derartige Konstruke verhindern/vermeiden... Also eher Ursachenbekämpung anstatt reagierende Maßnahmen.


Ich habe bspw. Jahrelang mit nem Dual Xeon Setup gearbeitet. 2x Dualcore, später 2x Quadcore auf Core2 Basis. Das geht schon... Der hat zwar den Memory am Chipsatz klemmen, die Cachezugriffsproblematik ist dort aber (sogar schlimmer noch, durch den lahmen FSB) ebenso gegeben. Zwingt man bspw. SuperPI (was ja eigentlich nur einen Thread nutzt!) auf Thread 1 von Prozessor 1 und Thread 1 von Prozessor 2 (über den Taskmanager), geht sichtbar Leistung verloren. Weil der Worker mal links, mal rechts läuft und damit Cacheinhalte nicht zur Verfügung stehen bzw. erst übertragen werden müssen. Das gleiche (allerdings nicht ganz so stark) kann man beobachten, wenn man zwei Threads bei nem Quadcore Core2 über beide internen DIEs verteilt (2x L2 Cache).
Oder auch mit anderen Modellen aka AMDs G34 Opterons -> unter der Decke 2x NUMA Nodes zu je 2x64Bit Speicheranbindung...

Wer es also real mal testen möchte wird möglicherweise mit nem Single Sockel G34 Workstation Brett und nem G34 Opteron auf Bulldozer, ggf. K10 aka MagnyCours Basis sehr günstig an ein Dual NUMA Setup ran kommen...
Oder halt auf die neuen Server Zens warten. Das 32 Core Teil wird mindestens 2x NUMA Nodes haben...

Am Ende ist es wie bei Grafikkarten, eine CPU mit mehr Leistung ist besser als 2.

Theoretisch ja, allerdings stellt sich hier oftmals die Preisfrage... Und, was im Serverbereich dazu kommt, die breiten CPUs sind im Takt teils massiv reduziert!
Such mal nach aktuellen Broadwell-E Xeons für S2011-3 mit deutlich über 3GHz und keine Ahnung 12+ Cores... Wird es nicht geben.
Heist also, mit 2x6 oder 2x8 Cores als HighClock Modelle könnte es in so mancher Situation doch deutlich besser gehen als mit einem 12/16 Core bei deutlich niedrigerem Takt. -> Alles eine Frage der Anwendungen.
Auch im Serverbereich lässt sich bei weitem nicht alles derart zerhacken, dass es bedingungslos in allen Situationen über die Breite streut. Denn auch dort wird sehr häufig "nur" das Mittel der gleichzeitigen Ausführung bei entsprechend vielen Anfragen gewählt.
Simples Beispiel, ein Apache Webserver streut bei entsprechend vielen Anfragen klar massiv in die Breite. Was bringen mir aber xx Threads auf dem Prozessor, wenn das Teil dann nur noch im mittleren zweistelligen GHz Bereich taktet, meine Abfragen auf die Dauer einer Abfrage runtergebrochen aber zu langsam ist/sind?

Ich seh prinzipiell kein Problem darin mit zig Kernen flüssig zu zocken, es muss halt nur klar sein dass das Ergebnis nicht besser sein wird als mit 4 Kernen.
Seh ich ja bei mir am 3930k, nur wenige Games schaffen es die CPU zu mehr als 25% auslasten, GTA V z.B. schafft stellenweise 40-50%.

Ich hab bei GTA V schon streckenweise 80-90% CPU Load bei mir mit 16 Threads beobachten können ;)
 
Fd klar, ich rede auch eher für Otto Normalo.

Cinebench ist z.B. auch über mehrere CPUs gut nutzbar.
 
Ja natürlich, aber ob das nun Otto Normalo Anwendungen sind oder harter Serverstuff, spielt ja eigentlich weniger eine direkte Rolle...
Mir ging es eher darum aufzuzeigen, dass es nicht pauschal so zu benennen geht. ;)

Cinebench bzw. Cinema4D und andere Rendertools bspw. bedienen sich dem Mittel, möglichst viele Threads gleichzeitig zu nutzen und das "Problem" im Ganzen damit durch viele Teilprobleme anzugehen. Das geht schon weitestgehend unabhängig... Weswegen der Spaß auch recht gut über die Breite skaliert. Oder auch im Videoencoding bereich ist das der Fall. Da kannste teils pro Frame einfach nen Thread aufmachen und loslegen. Völlig ohne Abhängigkeit zum Rest der Worker.
 
Zocken auf nem Dualsockel-System kann extrem nervenaufreibend sein. Habe ich heute gemacht.
Die PCIe-Slots sind zur Hälfte von CPU0 gestellt und zur Hälfte von CPU1. Jetzt sitzt die Grafikkarte in Slot 1, welcher mit CPU1 verbunden ist. Windows wirft die Threads des Spiels standardmäßig erstmal auf CPU0, also muss der Datenverkehr zur Grafikkarte durch CPU0->QPI->CPU1. Das resultierte bei mir bei 24/48 x 2.4 GHz und einer GTX470 in etwa 10-15 fps in Half Life 2...
Wenn dann die Affinität der Spielethreads auf CPU1 gesetzt wurde, war alles super bei >70 fps.

Das Ganze auf einem X10Dai, bei dem der erste PCIe-Slot an CPU1 hängt. Kann also sehr nervig werden, wenn man nicht weiß, wo man den Fehler suchen muss. Hat mich ne Stunde gekostet. :kotz:
 
Kannst du verifizieren ob das mit neueren Titeln ebenso auftritt?

Weil rein formal ist HL2 nun nicht unbedingt geeignet für solche Tests. Warum? Da ist nicht sonderlich viel Multithreading drin in der alten Software...
Theoretisch müsste es eigentlich recht entspannt machbar sein, dass eine Software "Worker" für die Spieleberechnung, also KI, Sound, Physik und Co. auf der einen CPU, den wichtigen Part zur 3D Bilderzeugung aber auf der anderen CPU stemmt, sinnvollerweise die, wo die PCIe Slots dran klemmen...
Andererseits wundert es mich doch ein Stück, dass es so extrem einbrechen soll... Der Interconnect sollte in der Lage sein, das bisschen PCIe 2.0 zu bedienen, was dort maximal durchfließen kann. Und ne GTX 470 ist nun nicht unbedingt neueste Gamerware. Mit nem 8x Interface auf 2.0 Basis kommt man da oftmals dicke hin. Das sind real in etwa 4GB/sec potentieller Durchsatz... Wäre das ein Bandbreitenproblem, hätten sehr viele Server mit entsprechend hohen Bandbreitenanforderungen ja ein massives Problem. Denn dort gibts ebenso keine zwingende CPU Zuweisung für Treiber und dergleichen. Eine FibreChannel/Infiniband Karte mit entsprechendem Durchsatz läuft auch mal links, mal rechts, was die Treiber und deren Berechnungen angeht. Nach deiner Aussage müsste der Durchsatz extrem wegbrechen, wenn da der falsche Prozessor am Werk wäre.
 
Zuletzt bearbeitet:
wo die Threads starke Abhängigkeiten zueinander haben. NUMA ist ja nicht "nur" Speicher vom anderen Prozessor. Real geht es ja dabei gerade auch um Cachezugriffe. Wenn ich da mal keine Ahnung, 20MB L3 Cache Inhalt "benötige", die aber auf nem anderen Prozessor im Cache liegen, muss entweder über den langsameren Interconnect zugegriffen werden oder die Software holt die Daten in den eigenen Cache.
Auch das ist ja nur der Anfang des wahren Problems, denn die Daten im Cache werden ja nicht nur gelesen, da wird ja auch geschrieben und dazu müssen die Threads synchronisiert und die Cacheinhalte dann auf der anderen CPU aktualisiert werden.

Cinebench bzw. Cinema4D und andere Rendertools bspw. bedienen sich dem Mittel, möglichst viele Threads gleichzeitig zu nutzen und das "Problem" im Ganzen damit durch viele Teilprobleme anzugehen. Das geht schon weitestgehend unabhängig...
Eben, da greift jeder Thread vor allem auf eigene Daten zu und damit skaliert es eben auch gut über mehrere Kerne und CPUs, bei Problemen die nichts so gut zerlegbar sind weil viel auf gemeinsamen Daten gearbeitet werden muss, gibt es viel mehr Synchronisierung und damit skalieren die eben viel schlechter über viel Kerne oder gar CPUs. Da kann es dann sein, dass der Programmierer dann gleich im Programm die Affinität der Threads nur auf die Kerne/Threads eine CPUs einstellt und damit die zweite CPU gar nicht genutzt wird.

Dies setzt aber voraus, dass der Entwickler der SW sich auch Gedanken darüber gemacht hat, wie sein Programm auf Multi-CPU Systemen performt und dazu muss es erst einmal überhaupt erwarten, dass sein Programm auch öfter auf solchen Rechnern genutzt werden dürfte. Dies ist bei Spielen wohl nicht zu erwarten, sehr wohl aber bei FibreChannel/Infiniband Karten und damit deren Treibern.
 
Dies setzt aber voraus, dass der Entwickler der SW sich auch Gedanken darüber gemacht hat, wie sein Programm auf Multi-CPU Systemen performt und dazu muss es erst einmal überhaupt erwarten, dass sein Programm auch öfter auf solchen Rechnern genutzt werden dürfte. Dies ist bei Spielen wohl nicht zu erwarten, sehr wohl aber bei FibreChannel/Infiniband Karten und damit deren Treibern.

Das war ja nur ein Beispiel... Nimm halt von mir aus ein HPC Cluster mit GPUs... Selbst "Gamer" Modelle brechen dort meines Wissens nach nicht weg... Zumindest das, was ich bis dato getestet habe.
Und das verteilt auch über die CPUs bei nem Dual CPU Aufbau die PCIe Lanes. Ich hatte für gewisse Selbstzwecke dazu mal Zugriff auf nen alten Miner mit 7x Tahiti GPUs. Das skaliert schon... Je nach Software halt.

Für mich sieht das hier nicht nach einem Dual CPU oder NUMA Problem aus, sondern eher nach einem Treiber/Biosproblem. Möglicherweise ein Bug oder es ist irgendwas nicht richtig installiert, fehlende Treiber, falsche Settings oder ähnliches...
 
Ach wie schön war da noch 1366, da waren die lanes im chipsatz.

Der qpi sollte übrigens für pcie kein hindernis sein, der ist duplex-fähig und die bandbreite eigentlich nie das Problem. Das die cache sync langsam ist, ist aber wahr.
 
Ich kann da heute Abend mal ein bisschen mehr testen. Interessiert mich ja schon, woran das liegt.

€: Es ist mit Benchmarks wie 3DMark oder Spielen wie KillingFloor 2 nicht reproduzierbar. Nur Half Life 2 macht Ärger.
 
Zuletzt bearbeitet:
Ich werde auch testen wenn mein System steht.
Einmal mit meiner 7970 und einmal mit der GTX 1070.
https://www.youtube.com/watch?v=mY7GR49LfaM

Er hat mit den Prozessor einige Spiele test gemacht und wie ich sehe ist die Grafikkarte immer im GPU limit eh der CPU an seine Grenzen kommt. :d
 
Zuletzt bearbeitet:
Mit den heutigen Core i3 mit Vierkernen liegen wir fast genau wie beim bisherigen i5 :lol:

klein
 
Wenn man die ersten Kommentare von 2015 liest, merkt man erstmal was einige hier für eine Scheisse abgesondert haben. :fresse2:

AMD wird keine Konkurrenz in Zukunft sein. :hust:

Willkommen in 2018/2019 ... den Jahren in denen Intel der Arsch geht und der Schlüssel für die magische Schublade mit Wunder-CPUs unauffindbar ist.
 
Warum fleddert ihr auch Thread-Leichen?
Dass die Erkenntnis von damals nicht mehr passen muss, ist nunmal so.
 
Im CB Forum :hmm: Da bin ich nicht mal aktiv, ich lese dort lediglich auf der Startseite die Neuigkeiten. Wie kommst du auf diesen Unsinn, vor allem was hat das mit irgendwas zu tun? :stupid:
 
...

2021 wird Intel schon was nachlegen.

2020 ja "bereits" hardwareseitig gegen Spectre und Meltdown.

...
 
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