AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

[Complicated]

Nunja, hier ist sicherlich etwas Wahres dran. Z.B. gehe ich davon aus, dass Intel bewusst im Vorfeld Informationen streut, um die nach Mehr gierende Anhängerschaft bei Laune zu halten. Andererseits halte ich es für unmöglich, dass wir nur deshalb keine Informationen über eventuelle weitere Plattformen zu Ryzen haben, weil AMD so gut ist und keine Info-Löcher mehr hat. Die Wahrheit liegt hier sicherlich irgendwo dazwischen. Leaks minimieren ja, komplett abstellen sicherlich nein.

Dazu empfehle ich dir diesen Artikel bei Anand zu Evergreen und wie AMD damals Geheimhaltung für einzelne Features etablieren konnte, nicht nur vor den Medien sondern auch vor dem eigenen Management - schon lustig was ein Ingenieur heute so alles machen muss damit seine Arbeit im Endprodukt auch enthalten ist
Preventing Espionage at AMD: How The Eyefinity Project Came to Be

 

[Yoshi 2k3]

Irgendwie hab ich jetzt den Überblick verloren... Sind die 2x x8 3.0 denn jetzt Fakt oder Gerücht?

 

[Limit64]

Ryzen auf AM4 hat 24 PCIe3-Lanes, von denen 1x16 oder 2x8 für die GPU(s) vorgesehen sind. Diese Informationen sind in der Präsentation der neuen Chipsätze enthalten.

 

[Complicated]

Die Ryzen CPUs für AM4 haben keine 32 PCIe 3.0 Lanes die man benötigen würde für mehr als 2x 8 PCIe3 Setups. Das selbe gilt auch für sämtliche 1151-basierenden Systeme von Intel. Hier ist der Stromverbrauch einfach die wichtigere Größe im Konkurrenzkampf.#

Edit: jo zu spät.

 

[MusicIsMyLife]

Im Zweifel gibt es bestimmt Boards mit PLX PCIe-Brückenchip, der aus den PCIe x16 zur CPU zwei x16 für jede GPU macht. Bei halbwegs intelligentem Routing der Daten, kann das bei Multi-GPU sogar schneller sein als den Umweg über die CPU für jeden Mist (z.B. das Ausgabebild) nehmen zu müssen.

Richtig, es gibt Lösungsmöglichkeiten. Was dabei aber für ein Chaos rauskommt, wenn Mainboard-Hersteller die Limitierungen der CPU-Hersteller zu umschiffen versuchen, kann man hier gut erkennen:

The PCI-E layout of the X99-Designare EX is one of the most complex so I will go slowly. For starters, the two U.2 ports, the M.2, and the Alpine Ridge each require 4x of PCI-E 3.0, so GIGABYTE is using a PEX8747 to expand lanes. Next up, both 28 and 40 lane CPUs provide 4x PCI-E 3.0 directly to Intel's Alpine Ridge USB 3.1/Thunderbolt 3 controller. CPUs with 40 lanes will get both U.2 ports; one is directly wired to the CPU, and the other comes from the PEX8747, but 28 lane CPUs won't have the U.2 directly wired to the CPU. Instead, they will get only one through the PEX8747. The third PCI-E 16x slot is a 4x electrical PCI-E 2.0 slot connected to the PCH. Next, for both 28 and 40 lane CPUs, the first slot is routed 16x of bandwidth, and the last slot gets 8x from the first slot if it is occupied.

Now, a 40 lane CPU will provide the remaining 16x of bandwidth to the PEX8747, and a 28 lane CPU will provide 8x to the PEX8747. The PEX8747 will output 32 lanes, even if it only gets 8x, so the PCI-E layout is the same for both lane count CPUs. The second to last PCI-E 16x slot (slot number four if we skip the 1x slot), gets 16x of bandwidth and will downshift to 8x if an M.2 drive is installed (it will give 4x to the M.2 slot, and 4x will just not be used). The second PCI-E 16x slot is given the other 16x from the PEX8747, and it will downshift to 8x if the first U.2 slot is used (4x to U.2 and 4x not used). If you need further clarification, please read the manual to determine bandwidth allotment and determine how to proceed.

It's clear that both 28 and 40 lane CPUs get the same PCI-E slot layout/bandwidth, but the 28 lane CPU gets one less U.2 port, and the PEX8747 will provide fewer lanes. With this layout, 40-lane CPU users will be able to use both U.2, M.2, USB 3.1/TB3, and all PCI-E ports simultaneously.

Ich bin der Meinung, letztens einen Artikel darüber gelesen zu haben, wo verschiedene Z170-Boards hinsichtlich ihres PCIe-Routings und der PLX-Switche verglichen wurde. Leider finde ich den Artikel nicht mehr. Fakt ist aber, dass dieses mitunter extrem komplexe Routing dazu führt, dass die Mainboards unnötig komplex, dadurch teurer und durch Verwendung von einem oder gar mehreren Switchen noch zusätzlich teurer werden.

Ich selbst muss mich zwischen M.2 und einem bestimmten PCIe-x16-Slot entscheiden, kann trotz 40 Lanes nicht beides gleichzeitig verwenden. Soll heißen: Ich finde selbst die 40 Lanes für das Jahr 2017 nicht mehr angemessen (die 40 Lanes 3.0 bietet Intel inoffiziell seit 11/2011 und offiziell seit 9/2013).

LGA1151 Boardpreise 48,79 - 574,85 und LGA2011-3 Boardpreise 196,94 - 802,96 - da brauch man nicht diskutieren welche Plattform teuer ist. Was man kauft hängt von den eigenen Ansprüchen ab.

Dagegen gibt es von mir ja auch kein Veto. Ein Veto gibt es deshalb, weil ein 2011-3-Setup nicht automatisch deshalb teurer als ein S1151-Setup ist, nur weil es eben 2011-3 ist. Denn diese Aussage ist falsch und du belegst sie selbst.

Nach deiner Argumentation ist die RX 480 auch High-End weil AMD nichts schnelleres im Portfolio hat. Das kann definitiv als falsch bezeichnen, wodurch dein Argument auch seine Gültigkeit verliert.

AMD bietet noch eine Fury X an, welche je nach Auflösung auch mal rund ein Drittel schneller sein kann als die RX 480. Also kann auch nach meiner Definition die RX 480 kein High End sein.

Bisher habe ich dieses Thema gerne gelesen und intensiv verfolgt. Schon wieder okkupieren hier einige Personen das Thema um Kleinigkeiten die mit dem eigentlichen Thema nur am Rande zu tun haben bis ins Letzte auszudiskutieren. Brechfaktor hoch 15.

Ob jetzt Rizen High-End oder nur High-Performance bietet. Ob es 2x16 PCIe oder 2x8 entweder als 3.0 oder 2.0 sind ist doch eigentlich totoal egal. AM4 ist als Plattform für den Desktop vorgesehen. Nicht als HIGH-MEGA-ULTRON-MULTI-GPU-PLATTFORM. Auch wenn ein Board 2 oder mehr PCIe 16x Slots besitzt heißt es noch lange nicht: Alles TipTop angeschlossen. Dafür ist die Architektur des Prozessors als auch der Plattform gar nicht entwickelt worden. Ich möchte gar nicht wissen wieviele Mainboards verkauft werden die vermeindlich für 2-4 Grafikkarten gebaut wurden und trotzdem nicht wirklich schneller damit sind als eine andere Kiste mit einer Top-Grafikkarte. Ist ungefähr genau das Gleiche ob ich einen Feuerwehrschlauch an der Badewannenarmatur anschließe. Geht zwar, ist aber prinzipiell kac|<e.

Oder ist das hier nur der Wunsch von AMD-Anhängern einer GTX-Titan nahekommen zu wollen mit 2 oder 3 AMD Karten? Standardausstattung wird ein Mittel- bis Unterklassenmainboard mit genau einer Grafikkarte sein.

Ob AMD mit einem Enthusiasten wirklich mehr Geld verdient als mit 12 Normalkunden lasse ich jetzt mal dahingestellt, da AMD oder INtel mit hochpreisigen Mainboards nicht mehr verdient als Chipsatz bzw. CPU-Lieferant.

Auch ich habe hier sehr gerne mitgelesen. Und wenn in ich einem Thread im Tech-Talk-Forum der Meinung bin, meinen Standpunkt darzulegen und zu verteidigen, dann tue ich das.

Dass dir und p4z1f1st das missfällt tut mir einerseits leid, lässt mich andererseits aber doch etwas fragend zurück. Denn ohne dass jemand was schreibt, könnt ihr auch nichts im Thread lesen. Und okkupiert halte ich angesichts meiner vielleicht ein Dutzend Beiträge in einem mehr als 3.300 Posts enthaltenen Thread auch für die falsche Bezeichnung.



Dennoch habe ich verstanden, dass ich hier mit meiner Meinung nicht willkommen bin und beende das Thema hiermit. Zerpflückt meine Aussagen und macht daraus, was ihr wollt - meine Meinung steht.

Viel Vergnügen weiterhin im Thread...

 

[Captn-Future]

Auch wenn der Eindruck entstehen sollte, dass ich oder auch andere jemdanden nicht willkommen heißen könnten oder Beiträge nicht erwünscht wären: Dem ist eigentlich nicht so. Mir geht es nur darum, dass die Anzahl an PCI-Lanes dieser neuen Architektur hier bis ins kleinste auseinander genommen werden. Es ist schon länger bekannt, dass es nur 24 Lanes sind. Natürlich hätte man auch 40 oder 56 haben wollen. Das sind Erwartungen oder Bedürfnisse von einer geringen Anzahl von Usern. Wenn AMD gesagt hätte: Das ist der Mount Everest der Computer nicht blos der Feldberg, dann würde ich jedem der statt 24 40 Lanes haben wollte beifplichten. Aber es ist leider nur das Matterhorn geworden. Deswegen wird AMD jetzt nicht alles einstampfen nur weil in bestimmten Fällen Leistungseinbußen zu erwarten sind. Jeder wird sich wünschen mehr Leistung, mehr Bandbreite, mehr mehr mehr zu bekommen.

Auch wenn wir hier in einem Tech-Talk-Forum sind, hatte ich das Gefühl, dass hier einige Tauziehen spielen, aber beide das Seil um einen Baum geschwungen haben.

 

[Yoshi 2k3]

aber 1 x16 3.0 sollte doch für 98% der Anwender genügen?! Verstehe die Aufregung auch nicht so ganz. Berechtigte Kritik, ja. Aber aktuell auch "marktüblich". Außerdem stehen bei den Server-CPUs doch dann mehr Lanes zur Verfügung. Also auch für dicke Workstations ist dann gesorgt, zum entsprechenden Preis.

@Complicated / Limit64: Danke für die Infos.

 

[Complicated]

AMD bietet noch eine Fury X an, welche je nach Auflösung auch mal rund ein Drittel schneller sein kann als die RX 480. Also kann auch nach meiner Definition die RX 480 kein High End sein.

Wie jetzt
Trotz dem High-End 8GB Speicherausbau? Sag bloß der AMD 32-Core Naples wird dann der High-End sein mit 128 PCIe-Lanes und nicht der Ryzen mit 8-Core und 24 Lanes?
Da sind wir uns doch jetzt einig, oder?

Was du als Unterscheidung einbringst ist lediglich der Launchtermin. Das funktioniert allerdings auch nur wenn jeder Hersteller so wie Nvidia von Tops abwärts seine Produkte in den Markt bringt. Das nenne ich typisch dem falschen Marketing aufgesessen, auch wenn sie es gut machen. AMD hat ganz klar eine Zielgruppe definiert mit Ryzen und das ist der Gamer.

 

[derDruide]

aber 1 x16 3.0 sollte doch für 98% der Anwender genügen?! Verstehe die Aufregung auch nicht so ganz.

So ist es.

 

[Dresdenboy]

Grundsätzlich ist Intels Hyperthreading (HTT) kein richtiges vollwertiges SMT. Siehe Basisinfo:
https://de.wikipedia.org/wiki/Hyper-Threading

Jetzt war ich doch etwas platt über das, was bei Wikipedia steht.

Ich mache es kurz:

Intel’s Hyper-Threading Technology brings the concept of simultaneous multi-threading to the Intel Architecture.

http://www.intel.com/content/dam/ww...2002-vol06-iss-1-intel-technology-journal.pdf

Sinnlos diese SMT/HTT Diskussion.
Warum bei Intels HTT eine Priorisierung genutzt wird?
Weil eine gleichwertige Nutzung in dem Markt dieses Produktes das denkbar dämlichste ist was man machen kann.
IBMs Prozessoren treffen auf eine hoch optimierte Softwareumgebung, Intels Prozessoren wohl eher selten und müssen sich mit Software mit einem mehr als mangelhaften Multicore Support rumschlagen. Aufgrund dessen hätte man einen massiven Leistungseinbruch wenn z.B. 2 Threads anstatt auf 2 physischen Kernen auf den beiden virtuellen Kernen eines Kerns laufen würden.
Zudem kann man dafür nicht ernsthaft einen Skalierungsfaktor festlegen weil aufgrund der Arbeitsweise z.B. bei 2 fach SMT im Bereich zwischen einer Verdoppelung der Leistung und einem Leistungsrückgang alles drin ist.

Ich mache es auch hier kurz:

Priority is not given to one logical processor above the other.

http://www.cs.sfu.ca/~fedorova/Teaching/CMPT886/Spring2007/papers/hyper-threading.pdf
Und meine eigenen Untersuchungen auf einem Broadwell haben das als immer noch gültig bestätigt (low prio FPU-Threads bremsen high prio Prime95-Threads auf bis zu 50% ab). Ich hatte mich ja einmal damit befasst, als ich die Patente von AMD zu SMT-Prioritäten sah.

 

[sompe]

Dann bist du aber bereits im Bereich der Nutzung aller Kerne bei dem alle Threads des Prozessors genutzt werden, was ich schrieb ist der Bereich der Teilauslastung bei dem zuerst ein Thread der Kerne belegt werden soll bevor der zweite drauf kommt, gerade damit sich die beiden Threads nicht gegenseitig das Wasser abgraben oder im Fall der Bulldozer Architektur die FPU nicht aufgespaltet werden muss. Das ist auch eine Priorisierung.

 

[Dresdenboy]

Dann bist du aber bereits im Bereich der Nutzung aller Kerne bei dem alle Threads des Prozessors genutzt werden, was ich schrieb ist der Bereich der Teilauslastung bei dem zuerst ein Thread der Kerne belegt werden soll bevor der zweite drauf kommt, gerade damit sich die beiden Threads nicht gegenseitig das Wasser abgraben oder im Fall der Bulldozer Architektur die FPU nicht aufgespaltet werden muss. Das ist auch eine Priorisierung.

Ach, du meintest das Scheduling. Richtig, da wird auch priorisiert.

 

[Novasun]

Jetzt war ich doch etwas platt über das, was bei Wikipedia steht.

Ich mache es kurz:

http://www.intel.com/content/dam/ww...2002-vol06-iss-1-intel-technology-journal.pdf



Ich mache es auch hier kurz:

http://www.cs.sfu.ca/~fedorova/Teaching/CMPT886/Spring2007/papers/hyper-threading.pdf
Und meine eigenen Untersuchungen auf einem Broadwell haben das als immer noch gültig bestätigt (low prio FPU-Threads bremsen high prio Prime95-Threads auf bis zu 50% ab). Ich hatte mich ja einmal damit befasst, als ich die Patente von AMD zu SMT-Prioritäten sah.

Jetzt bin ich etwas verwirrt. Welche Meinung untermauerst du hier?

Ich sehe aber aufgrund deiner Infos und dieser Info
https://en.wikipedia.org/wiki/Bulldozer_%28microarchitecture%29 das wir im Sprachgebrauch sehr ungenau waren.
Ich für meinen Teil bleibe noch immer auf dem Standpunkt: Intels HT ungleich AMD`s CMT.

Intel - Zitat:
Hyper-Threading Technology makes a single physical processor appear as two logical processors; the physical execution resources are shared
and the architecture state is duplicated for the two logical processors.

Kurz die nutzen die Hardware zur Laufzeit besser aus - nur der "architecture state" ist verdoppelt.

AMD - Zitat:
Bulldozer introduced a "Clustered MultiThreading"(CMT) where some parts of the processor are shared between two threads and some parts are unique for each thread.

In terms of hardware complexity and functionality, the Bulldozer CMT module is equal to a dual-core processor in its integer power, and to either a single-core processor or a dual core in its floating-point power, depending on whether the code is saturated in floating point instructions in both threads running on the same CMT module, and whether the FPU is performing 128-bit or 256-bit floating point operations.

Kurz, streng genommen eine Mischform aus zur Laufzeit die Hardware besser nutzen + Hardwareressourcen doppelt vorhalten (splitten im Fall der 128 Bit Befehle FPU?).

Jetzt macht auch eines Sinn für mich - bei Zen spricht man im Moment von SMT - und ich meinte auch Gerüchteweise ghört zu haben nicht unähnlich von Intel. Inzischen spekulieren hier ja einige eher in Richtung der Implementation von IBM. Ist das nun eher klassisches SMT (ich sag mal leistungssteigerung durch Pipline pro Takt besser füllen) oder CMT (Leisterungssteigerung durch doppelt vorhandene "Hardware")?

 

[Dresdenboy]

Jetzt bin ich etwas verwirrt. Welche Meinung untermauerst du hier?

Dich hatte ich doch gar nicht zitiert.
Meine Meinung ist: Intel HT = SMT, AMD BD = CMT, AMD BD-FPU = SMT, Zen = SMT mit Priorisierung (steht alles irgendwo in Papers oder Präsentationen)

IBM hat seit Power 5 SMT mit expliziter Priorisierung (also nichts, wo sich der Prozessor mit irgendwelchen Metriken automatisch anpasst).

Daher kann ich deinen Punkten zustimmen mit kleinem Klärungsbedarf. Ansonsten müssten wir mit alternativen Fakten arbeiten.

Bei AMD könnte man noch etwas korrigieren:

AMD - Zitat:
Bulldozer introduced a "Clustered MultiThreading"(CMT) where some parts of the processor are shared between two threads and some parts are unique for each thread.

In terms of hardware complexity and functionality, the Bulldozer CMT module is equal to a dual-core processor in its integer power, and to either a single-core processor or a dual core in its floating-point power, depending on whether the code is saturated in floating point instructions in both threads running on the same CMT module, and whether the FPU is performing 128-bit or 256-bit floating point operations.

Kurz, streng genommen eine Mischform aus zur Laufzeit die Hardware besser nutzen + Hardwareressourcen doppelt vorhalten (splitten im Fall der 128 Bit Befehle FPU?).

Jetzt macht auch eines Sinn für mich - bei Zen spricht man im Moment von SMT - und ich meinte auch Gerüchteweise ghört zu haben nicht unähnlich von Intel. Inzischen spekulieren hier ja einige eher in Richtung der Implementation von IBM. Ist das nun eher klassisches SMT (ich sag mal leistungssteigerung durch Pipline pro Takt besser füllen) oder CMT (Leisterungssteigerung durch doppelt vorhandene "Hardware")?

AMD schreibt bei der FPU ganz klar "SMT" hin (siehe Legende):

Was sie oben im Zitat meinen könnten, ist wohl: "either a physical processor or two logical processors", also wie eine FPU in einem SMT-fähigen Kern, wo ein oder zwei Threads aktiv sind. Und natürlich blocken sich zwei Threads auch mal die Ressourcen, erst recht, wenn die zwei FMAC-Einheiten FPU für einen 256-Bit-Befehl sozusagen verbunden werden.

Zens SMT wird eher so etwas wie eine Zwischenvariante von HT und IBM SMT-2.

 

[WindHund]

Oder ist das hier nur der Wunsch von AMD-Anhängern einer GTX-Titan nahekommen zu wollen mit 2 oder 3 AMD Karten? Standardausstattung wird ein Mittel- bis Unterklassenmainboard mit genau einer Grafikkarte sein.

?
Wer gibt sich bitte mit einer GTX Titan zufrieden, wenn er schon mal Multi-GPU hatte?
Klar geht das nicht über all, aber wenn es läuft dann musst schon größere Geschütze auffahren um mit Muli-GPU mitzuhalten.
+50% sind da keine Seltenheit, wann gab es bei einer GPU Neuvorstellung zu letzt ein Performance + von 50% gegenüber dem Vorgänger?
Es ist inzwischen sogar so, dass es weniger Leistung gibt bei GPUs (DP).

Ich weiß nicht ob ich diese Spar-Maßnahmen wirklich gut heißen soll, als könnte der Kunde nicht selbst entscheiden was er braucht.

Was jetzt noch interessant wäre, wenn nun alle bei PCIsig antanzen und ihre Mainboards zertifizieren: https://pcisig.com/developers/compliance-program
könnte ich mir ein Stau vorstellen, so das zuerst wirklich nur Boards mit 1x x16 kommen, da 2x x16 einfach länger dauert um es zu testen.

 

[Novasun]

IBM hat seit Power 5 SMT mit expliziter Priorisierung (also nichts, wo sich der Prozessor mit irgendwelchen Metriken automatisch anpasst).

Zens SMT wird eher so etwas wie eine Zwischenvariante von HT und IBM SMT-2.

Bezüglich des "wo sich der Prozessor mit irgendwelchen Metriken automatisch anpasst" - in meiner Theorie hätte das nie der Prozessor selbst gemacht sondern eher der Treiber/OS. Wenn ich IBM aber richtig verstehe ist es noch viel besser. Es kann der Programmierer und somit die Applikation selbst. Natürlich in Zusammenarbeit mit dem OS - da man ja wissen muss was sonst noch so läuft.

Aber genial ist auch, IBM`s Lösung kann sich dynamisch anpassen und fährt Workload der durch SMT verlangsamt werden würde dann halt gar nicht mit SMT. So kommt wenigstens im Worstcase keine schlechtere Leistung raus als bei einem NON-SMT Prozessor. Muss schon sagen, bei IBM schaffen schon Käpsele...

 

[Limit64]

Ich für meinen Teil bleibe noch immer auf dem Standpunkt: Intels HT ungleich AMD`s CMT.

Gab es daran Zweifel? Es gibt zwar fließende Übergänge dazwischen, aber die beiden sind so, wie sie bei Intel und AMD implementiert sind eindeutig zu unterscheiden. IBMs SMT-Implementierung steht noch zwischen den beiden.

Jetzt macht auch eines Sinn für mich - bei Zen spricht man im Moment von SMT - und ich meinte auch Gerüchteweise ghört zu haben nicht unähnlich von Intel. Inzischen spekulieren hier ja einige eher in Richtung der Implementation von IBM. Ist das nun eher klassisches SMT (ich sag mal leistungssteigerung durch Pipline pro Takt besser füllen) oder CMT (Leisterungssteigerung durch doppelt vorhandene "Hardware")?

Du kannst SMT unterschiedlich auslegen. Hauptstellschraube ist dabei die Zahl der Ausführungseinheiten (ALUs, FPUs, usw.). Intels Kerne sind von der Breite so ausgelegt, dass ein einzelner Thread die Einheiten unter optimalen Bedingungen durchaus auslasten kann. IBM legt seine Power-CPUs breiter aus. Mit einem einzelnen Thread lassen sich die Kerne kaum auslasten. Man verschwendet also im Single-Thread Betrieb Resourcen. Der Vorteil ist aber, dass man mehr freie Resourcen für einen zweiten Thread hat und die Gewinne durch SMT entsprechend höher ausfallen. IBMs Methode verlagert also einen Teil des Parallelisierungsaufwandes von der CPU auf die Entwickler und deren Tools. Bei gut parallelisierbaren Problemen kann man so die Effizienz deutlich steigern, denn die Kerne müssen nicht so stark optimiert werden um sie auszulasten. Der Haken liegt bei schlecht parallelisierbaren Aufgaben. Dort kommt es auf die Leistung pro Thread an und da haben die Intel-CPUs Vorteile.
AMD wird vermutlich versuchen ähnlich wie Intel die Leistung pro Thread möglichst hoch zu bekommen. Herankommen an Intel werden sie vermutlich aber nicht, denn die sind sehr gut darin und haben lange Zeit gehabt zu optimieren. Diesen Nachteil wird AMD durch mehr Resourcen für SMT versuchen auszugleichen. Im Endeffekt würde das bedeuten: schlechtere Leistung und Effizienz bei wenigen Threads. Im Gegenzug steigt bei vielen Threads die Leistung und Energieeffizienz bei AMD stärker an als bei Intel. Daher könnte es sein, dass sie im Server-Bereich gegenüber Intel konkurrenzfähiger sein werden als im Desktop-Segment.

Bezüglich des "wo sich der Prozessor mit irgendwelchen Metriken automatisch anpasst" - in meiner Theorie hätte das nie der Prozessor selbst gemacht sondern eher der Treiber/OS. Wenn ich IBM aber richtig verstehe ist es noch viel besser. Es kann der Programmierer und somit die Applikation selbst. Natürlich in Zusammenarbeit mit dem OS - da man ja wissen muss was sonst noch so läuft.

Das erinnert mich an meine Studienarbeit. Dabei ging es darum die Performance-Counter der CPU zu benutzen um Profile der Threads zu erzeugen und diese im Scheduler zu nutzen um ähnliche Threads nicht auf die selben physischen Kern zu legen.

 

[Captn-Future]

?
Wer gibt sich bitte mit einer GTX Titan zufrieden, wenn er schon mal Multi-GPU hatte?
Klar geht das nicht über all, aber wenn es läuft dann musst schon größere Geschütze auffahren um mit Muli-GPU mitzuhalten.
+50% sind da keine Seltenheit, wann gab es bei einer GPU Neuvorstellung zu letzt ein Performance + von 50% gegenüber dem Vorgänger?
Es ist inzwischen sogar so, dass es weniger Leistung gibt bei GPUs (DP).

Na was denn jetzt Grafikleistung oder DP-Rechenpower? Abgesehen von wirklicher Mehrleistung in einigen Spielen, dann wohl auch nur in 4k oder entsprechend großen Auflösungen bzw. Multi-Monitor-Setups, geht es ja bei CF oder SLI meistens nur um das technisch Machbare. Oder hat man von Mikrorucklern und dem enormen Kühlbedarf auch sonst noch Vorteile?

Ich weiß nicht ob ich diese Spar-Maßnahmen wirklich gut heißen soll, als könnte der Kunde nicht selbst entscheiden was er braucht.

Was jetzt noch interessant wäre, wenn nun alle bei PCIsig antanzen und ihre Mainboards zertifizieren: https://pcisig.com/developers/compliance-program
könnte ich mir ein Stau vorstellen, so das zuerst wirklich nur Boards mit 1x x16 kommen, da 2x x16 einfach länger dauert um es zu testen.

Glaube nicht, dass da viel Zertifiziert wird. Da werden wohl nur die Spezifikationen eingehalten und dann geht das Teil auf den Markt.

 

[WindHund]

Na was denn jetzt Grafikleistung oder DP-Rechenpower? Abgesehen von wirklicher Mehrleistung in einigen Spielen, dann wohl auch nur in 4k oder entsprechend großen Auflösungen bzw. Multi-Monitor-Setups, geht es ja bei CF oder SLI meistens nur um das technisch Machbare. Oder hat man von Mikrorucklern und dem enormen Kühlbedarf auch sonst noch Vorteile?

Hm, VR ist bei deiner Aufzählung nicht dabei, Warum?
Es gibt Mittel und Wege µ Ruckler "auszuschließen" das funktioniert schon sehr gut.
DOOM 2016 mit 1080p läuft zwischen 60 und 100 (min/avg FPS) bei ~ 350W (2nd GPU im sleep state)

Glaube nicht, dass da viel Zertifiziert wird. Da werden wohl nur die Spezifikationen eingehalten und dann geht das Teil auf den Markt.

Aha, das glaubst doch selbst nicht!

 

[Meckel]

Das erinnert mich an meine Studienarbeit. Dabei ging es darum die Performance-Counter der CPU zu benutzen um Profile der Threads zu erzeugen und diese im Scheduler zu nutzen um ähnliche Threads nicht auf die selben physischen Kern zu legen.

Das kann möglicherweise die Lokalität der Daten zerstören. Oder was sind "ähnliche Threads"?

 

[Limit64]

Das kann möglicherweise die Lokalität der Daten zerstören. Oder was sind "ähnliche Threads"?

Die Ähnlichkeit von Threads war über deren Profil definiert, also in welchem Maße sie die einzelnen Einheiten des Kerns nutzen. Da das eigentliche Ziel dabei die Vermeidung von Hotspots war und die SMT-Optimierung nur ein Extra war, spielte die Lokalität der Daten keine übermäßig große Rolle bei der Untersuchung. Es wurde allerdings versucht Migrationen zu vermeiden indem zuerst einmal nur die Scheduling-Reihenfolge geändert wurde. Das hat zwar auch einen Einfluss auf die temporäre Datenlokalität aber bei ausreichend großen Caches ist der Effekt vernachlässigbar. Wenn Threads häufig unterbrochen wurden (z.B. durch Cache-Misses), passte sich das Scheduling häufig mit der Zeit von selbst an, da der CFS sich merkt wieviel Rechenzeit jeder Thread effektiv genutzt hat.
Ich weiß gar nicht, ob die SMT-Optimierungen überhaupt irgendwas gebracht haben. Bewertet (und daher getestet) wurden in erster Linie das Erstellen der Thread-Profile und das "Um-Schedulen" von gleichartigen Threads. Weiterführende Tests oder Optimierungen wurden aufgrund des Zeitrahmens nicht gemacht.

 

[MR2]

https://www.ptt.cc/bbs/PC_Shopping/M.1485365573.A.E03.html

Ein AMD Ryzen: ZD3601BAM88F4_40/36_Y in ashes
Fake? ZD360 und AMD fanboy klingt schon seltsam...
-------------------------------------------------------

edit: ist ein i7 6900K

 

[Oi!Olli]

Mich würde ja mal interessieren, wie gut SMT implantiert ist. HTT schafft ja selbst in synthetischen Benchmarks maximal 50%.

 

[BoMbY]

WhyCry von Videocardz hat anscheinend auch ein Raven Ridge Sample gefunden: AMD Eng Sample: 2M3001C3T4MF2_33/30_N with AMD 15DD iGPU

M dürfte für Mobile stehen.

Jetzt müsste man nur noch die Stelle finden, wo er das her hat.

0x15DD ist 100% die Raven Ridge iGPU PCI Device ID.

 

[Dresdenboy]

Bezüglich des "wo sich der Prozessor mit irgendwelchen Metriken automatisch anpasst" - in meiner Theorie hätte das nie der Prozessor selbst gemacht sondern eher der Treiber/OS. Wenn ich IBM aber richtig verstehe ist es noch viel besser. Es kann der Programmierer und somit die Applikation selbst. Natürlich in Zusammenarbeit mit dem OS - da man ja wissen muss was sonst noch so läuft.

Aber genial ist auch, IBM`s Lösung kann sich dynamisch anpassen und fährt Workload der durch SMT verlangsamt werden würde dann halt gar nicht mit SMT. So kommt wenigstens im Worstcase keine schlechtere Leistung raus als bei einem NON-SMT Prozessor. Muss schon sagen, bei IBM schaffen schon Käpsele...

Hier gibt es etwas zu IBMs Umsetzung inkl. Extrembeispiele mit Execution Unit Contention: http://www.cslab.ece.ntua.gr/course... Multi-threading Implementation in POWER5.pdf

Das Konzept funktioniert natürlich gut in den POWER-Zielmärkten. Bei x86 wird es natürlich nicht so schnell etwas mit von der App selbst gesetzten Prioritäten. Das OS könnte zwar solche vorgeben, aber das wäre auch nicht thread-granular und ist z.B. für die meisten Windows-Anwendungen der Normalwert. Dann macht eine Automatik sogar sinn.

--- Update ---

Die Ähnlichkeit von Threads war über deren Profil definiert, also in welchem Maße sie die einzelnen Einheiten des Kerns nutzen. Da das eigentliche Ziel dabei die Vermeidung von Hotspots war und die SMT-Optimierung nur ein Extra war, spielte die Lokalität der Daten keine übermäßig große Rolle bei der Untersuchung. Es wurde allerdings versucht Migrationen zu vermeiden indem zuerst einmal nur die Scheduling-Reihenfolge geändert wurde. Das hat zwar auch einen Einfluss auf die temporäre Datenlokalität aber bei ausreichend großen Caches ist der Effekt vernachlässigbar. Wenn Threads häufig unterbrochen wurden (z.B. durch Cache-Misses), passte sich das Scheduling häufig mit der Zeit von selbst an, da der CFS sich merkt wieviel Rechenzeit jeder Thread effektiv genutzt hat.
Ich weiß gar nicht, ob die SMT-Optimierungen überhaupt irgendwas gebracht haben. Bewertet (und daher getestet) wurden in erster Linie das Erstellen der Thread-Profile und das "Um-Schedulen" von gleichartigen Threads. Weiterführende Tests oder Optimierungen wurden aufgrund des Zeitrahmens nicht gemacht.

Das klingt interessant! Über so ein ähnliches Thema in einem Paper bin ich gestern bei der kurzen Recherche für die erste Antwort auch gestolpert..