[MTKalkhoff]

meine Informationen basieren einfach auf über 35 Jahre Erfahrung in der EDV (Support, Administration, Programmierung, Compilerbau). Zum Einen bekommt dadurch einen sehr tiefen Einblick in die Hardware - zum Anderen werden Fallstricke und Performancelücken erkannt.

Das Ryzen einige (vorläufige) Vorteile bieten wird ist unumstritten. Insbesondere die erhöhte Anzahl von PCIe Lanes ist von Vorteil.

Nichts desto trotz wage ich zu bezweifeln das Ryzen der große Bringer auf Dauer wird. Vermutlich erfolgt ein Hype wie beim Phenom II X6 oder FX, welcher verhältnismäßig schnell wieder abflaut - natürlich mit dem erhöhten Wertverlust einer AMD CPU. Man braucht sich doch nur die Preis für gebrauchte CPUs anschauen. Intel hat in der oberen Klasse max. 30% bei der letzten/vorletzten Generation. LGA1155 CPUs sind nur vergleichsweise billig geworden weil der Markt an passenden und guten Board recht beschnitten ist. Bei AMD CPUs verlierst du locker 50% bei einer Generation...

[Grenor]

Also Single-Core Performance ist immer noch nen Ding. Gibt genug Applikationen die nicht ausreichend Kerne unterstützen. Da is schon wichtig das der einzelne Kern wumms hat.

[MTKalkhoff]

Ich glaube hier liegt ein grundlegender Irrglaube vor. Die Zeiten da ein Task abgearbeitet wird sind seit DOS vorbei !? Lasst Ihr etwa eine Applikation ohne Betriebssystem laufen ? Schaut einfach mal in den Task Manager was alles aktiv ist, dann wisst Ihr auch warum mehrere Kerne heutzutage benötigt werden.

Bestes Beispiel: Deaktiviert mal im Bios Kerne. Ergebnis ist ein lahmes System. Was nützt da die Single Core Performance ? Rein gar nichts !

Es ist nicht nur entscheidend das Applikationen die Kerne unterstützen/nutzen. Ein wesentlicher Aspekt ist das Environment (OS, Sicherheitspaket, etc.)

[RalphS]

Naja, es gibt leider immer noch viel zuviele Softwarebauer, die sich an MT nicht rantrauen und die entsprechend Applikationen entweder komplett single-thread bauen oder aber zeitaufwendige Routinen zwar MT-splitten *könnten* - aber dies nicht tun.

Oder die in der Theoretischen nicht aufgepaßt haben und bubblesort single-threaded verwenden.

Oder die schlicht nicht die Zeit zur Verfügung bekommen: Gestern muß das fertig sein und nun mach ma.

Will sagen, die schlicht suboptimal programmieren, komme was wolle, hauptsache das Ergebnis funktioniert hinterher irgendwie und reift dann beim Kunden.

Letztens hatte ich irgendwo auch was gelesen von wegen "nächstes Release verbraucht 50% weniger Ressourcen". Sagt ja schon alles. Wie schlecht muß man programmieren, damit sowas überhaupt erstmal möglich wird?

In unter anderem solchen Situationen profitiert man dann schon von single-core Performance. Klar, für "richtige" Anwendungen gilt, mehr Thread gleich mehr Power, aber diese Applikationen sind dann auch ordentlich programmiert. Entsprechend gibt's genug "lahme" Xeons für die DP/MP-Konfiguration wie E5-2603(DP) oder E5-4610(MP) mit 6 bzw 10 Kernen drin und einem Basistakt von 1.6 bzw 1.7GHz, die performancetechnisch mit sagen wir dual-bis-quadcore UP schlicht nicht verglichen werden können.

Aber daß es halt nicht so das Nonplusultra ist sieht man nicht zuletzt auch daran, daß Intels Quadcores mit oder ohne HT AMDs Octacores in die Tasche stecken. Das dürfte, wenn man eine vernünftige Implementierung annimmt, "eigentlich" nicht passieren.

Dieser Beitrag wurde von RalphS bearbeitet: 06. Januar 2017 - 05:43

[Gispelmob]

Zitat (MTKalkhoff: 05. Januar 2017 - 11:25)

meine Informationen basieren einfach auf über 35 Jahre Erfahrung in der EDV (Support, Administration, Programmierung, Compilerbau). Zum Einen bekommt dadurch einen sehr tiefen Einblick in die Hardware - zum Anderen werden Fallstricke und Performancelücken erkannt.

Das zeigt aber auch dass du in dieser Sichtweise festhängst und davon ausgehst das auch alle anderen das gleiche Wissen besitzen. Ist aber leider nicht so. Ich geb dir mal ein Beispiel:

Als Battlefield 4 erschien hatte es arge Probleme auf Multicore CPUs von AMD. Der Grund war ganz einfach dass die Macher davon ausgingen dass es schon laufen wird wenn man die Verwaltung vom Multithreading einfach dem BS überlässt. Leider wurden dann die AMD CPUs auf einzelnen Kernen so hoch belastet dass es zur Überlastung der CPU kam und das Spiel entweder Endlosschleifen beim laden der Map oder ständige Abstürze produzierte. Vorallem auf Shanghai stürzte es regelmäßig ab als der Tower zerstört wurde.

Bei Intel CPUs trat dicht gar nicht oder selten auf weil die eben bis zu 50% mehr Singlecoreperformance hatten. Und nichtmal ich mit 8 Cores konnte bei Release das Spiel spielen und musste erst auf Patches warten. Erst als dort ordentlich Multithreading in die Software implementiert wurde lief es stabil auf allen CPUs.

Wie du siehst gibt es dein Fachwissen zwar, aber es hat eben nicht jeder und vorallem bei den großen Softwareschmieden muss man sich immer wieder fragen wer denn da eigentlich programmiert und testet.

Genau aus dem Grund, weil der Großteil der Software immer noch keine ordentliche Multithreadunterstützung hat, ist Singlecoreperformance derzeit noch das A und O. Auch wenn es eigentlich nicht mehr so sein müsste. Die Entwicklung der Software hängt da ca. 10 Jahre hinter der Hardware her.

Ja, neue Projekte werden gleich mit Multithreaduntersützung aufgebaut wenn nötig, aber alte über viele Jahre gewachsene Projekte, die tun sich sehr schwer das einzubauen oder machen es gar nicht erst. Leider leider.

[RalphS]

Na nope. Multithreading kommt nicht von alleine.

Es kommt nur insoweit von alleine, wie das BS überhaupt was damit zu tun hat.Beispiel: Ich bau ne Form und ich häng da ein modeless Dialogfeld dran, dann wird das vom BS in einen eigenen Thread gesteckt. Sonst könnte es auch nicht modeless sein. Entsprechend läuft ein Fenster, so man eins hat in seiner Anwendung, ebenfalls im eigenen Thread (als Endlosschleife).

Aber die Implementierung, das was das Ding am Ende TUN soll, das muß man schon selber machen. Wenn ich jetzt schreib, for i = 1 to endoftheworld do sit+wait, dann wird NACHEINANDER gesittet und gewaitet für jedes I. Das muß auch so sein, weil das BS nicht einfach unterstellen darf, daß die einzelnen Iterationen UNABHÄNGIG sind voneinander (was Vorbedingung ist für Threading).

Ergo, wenn ich will daß for i = 1 to endoftheworld jedes i für sich(!) sitten und waiten soll, dann muß ich in der Schleife eben SAGEN, daß sit+wait in den Background geschoben werden soll und daß die dann da sitten und waiten sollen bis sie fertig sind und daß ich mich da jetzt erstmal nicht für interessiere.


Hier punkten dann die extra Kerne. Denn die bilden seit Intels Einführung der Core-Architektur Threads direkt ab (vorher war das symmetrisches Multiprocessing mit mehreren CPUs).


Was bei den AMD Octacores schiefgelaufen ist, keine Ahnung, bin ich nie drangeblieben. Aber irgendwas haut auf jeden Fall nicht hin damit. 4core+HT (oder auch nicht) sollte 8core nicht überflügeln. Wer weiß, vielleicht hängt es ja schon daran, daß die logischen Threads (aus der Software) nicht richtig auf die Kerne abgebildet werden. Aber das ist pure Spekulation meinerseits.

[Gispelmob]

AMD oder wie man ein Produkt vergurken kann.

Ich muss mich hier mal selbst zitieren.

Zitat (Gispelmob: 05. Januar 2017 - 07:47)

AMD bringt damit eine hohe Singlecore- und Multithreadingleistung, gepaart mit einer niedrigen TDP, 36 oder mehr PCIe Lanes, USB 3.1 und M.2 nativ.

Es geht genau genommen um die PCIe Lanes.

Die neueren Intel CPUs bieten 16 PCIe 3.0 Lanes in der CPU und weitere 24 über den Chipsatz. Also ingesamt 40. Davon müssen zwar welche für USB 3.1 Gen2 abgezweigt werden aber so bleiben dann etwa 38 für die PCIe Steckplätze übrig.

Jetzt bringt AMD den Ryzen mit 20 PCIe 3.0 Lanes (also 4 mehr als die Intel CPUs) und nun ging die Fachwelt davon aus das neuen im Chipsatz (wie bei Intel) 24 oder mehr Lanes enthalten sein werden.

Aber hier kommt die Überraschung. Es sind bei Maximalausbau nur 4 zusätzliche PCIe 3.0 enthalten. Da kann man sich nur an den Kopf greifen. Wenigstens müssen für USB 3.1 Gen2 keine Lanes abgezweigt werden, weil das nativ geboten wird. Trotzdem für mich eine große Enttäuschung.

Wie kann man so eine viel versprechende CPU dann mit so einem schrottigen Chipsatz kombinieren?

Quelle: https://www.computer...satz-vergleich/

Dieser Beitrag wurde von Gispelmob bearbeitet: 07. Januar 2017 - 09:36

[RalphS]

Eh, miese Chipsätze sind doch bei AMD Tradition.

Ist jetzt natürlich die Frage, ob und in welcher Form alternative Chipsätze auf den Markt kommen werden.

Dann womöglich mit mehr Lanes.