Ergebnis 1 bis 12 von 12
  1. Beitrag #1
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    18.760
    Danke Danke gesagt 
    9
    Danke Danke erhalten 
    7.359
    Blog-Einträge
    23

    AMD nimmt Stellung zu "Low-Res-Schwäche" von Ryzen

    Am 2. März stellte AMD seine neuen High-End-Prozessoren der Serie Ryzen offiziell vor. Dabei konnte AMDs neue Prozessor-Architektur Zen die Erwartungen weitestgehend erfüllen und bot jede Menge Leistung zu gegenüber Intels 8-Kern-Prozessoren deutlich geringeren Preisen. In niedrigen Auflösungen hinkte Ryzen den Intel-Systemen bei einigen Spielen jedoch hinterher, weshalb sofort der Begriff „Low-Res-Schwäche“ die Runde machte. Die Spekulationen begannen.

    (…)

    » Artikel lesen

  2. Die folgenden 6 Benutzer sagen Danke zu Nero24. für diesen nützlichen Beitrag:

    drSeehas (15.03.2017), Krümel (15.03.2017), MrBad (15.03.2017), Thyler Durden (15.03.2017), Unbekannter Krieger (15.03.2017), wolle23 (15.03.2017)

  3. Beitrag #2
    Commander
    Commander
    Avatar von MacroWelle

    Registriert seit
    15.02.2008
    Beiträge
    197
    Danke Danke gesagt 
    3
    Danke Danke erhalten 
    0
    Ich weiß nicht welches Video ihr gesehen habt, aber der Artikel bei pcper sagt was anderes: https://www.pcper.com/image/view/795...n=node%2F67315

    The Windows scheduler was already keeping those threads within the same CCX. This was repeatable (some runs were on the other CCX) and did not appear to be coincidental. Further, the example shown in the first (bar) chart demonstrated a workload spread across the four cores in CCX 0.
    Hätte nicht gedacht, dass ich hier mal Windows verteidigen muss :-)

  4. Beitrag #3
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    18.760
    Danke Danke gesagt 
    9
    Danke Danke erhalten 
    7.359
    Blog-Einträge
    23
    @MacroWelle: Du hast recht, hab ich Aussage etwas entschärft. Was aber nichts daran ändert, dass die Latenzen durch die Decke gehen sobald Kerne über CCX-Grenzen hinweg miteinander kommunzieren müssen.

  5. Beitrag #4
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    18.760
    Danke Danke gesagt 
    9
    Danke Danke erhalten 
    7.359
    Blog-Einträge
    23
    Was mich überrrascht hat ist, dass die Kommunikation zweier logischer Kerne innerhalb eines physischen Zen-Kerns nach diesen Messungen etwa 26 ns dauert, wohingegen bei Intels Haswell-E nur 14 ns vergehen. Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel.

  6. Beitrag #5
    Vice Admiral
    Special
    Vice Admiral
    Avatar von DonL_
    • Mein System
      Desktopsystem
      Prozessor: AMD Phenom X6 @ bis 3,7 GHZ
      Mainboard: Asrok 870 Extreme3
      Kühlung: CPU: Arctic Freezer Pro 64
      Arbeitsspeicher: 4 x 2048 MB Kingston DDR 3 - 1333
      Grafikkarte: Saphire RX 460 Nitro 4G
      Display: AOC G2460VQ6
      SSD(s): Samsung Evo 840 250GB
      Festplatte(n): 1 x Samsung HD501LJ SATA, Samsung HD 204UI
      Optische Laufwerke: LG DVDRAM
      Soundkarte: On Board
      Gehäuse: Chiftec Mesh Tower
      Netzteil: BE Quiet Pure Power 430W
      Betriebssystem(e): Windows 7
      Browser: Firefox

    Registriert seit
    11.11.2001
    Ort
    Hannover
    Beiträge
    660
    Danke Danke gesagt 
    2
    Danke Danke erhalten 
    0
    @ Nero24

    Wie sieht es denn bei euren Tests aus, seit ihr schon ein paar Geheimnissen auf der Spur?

  7. Beitrag #6
    Commodore
    Special
    Commodore
    Avatar von Hotstepper

    Registriert seit
    12.04.2005
    Beiträge
    448
    Danke Danke gesagt 
    3
    Danke Danke erhalten 
    15
    Zitat Zitat von Nero24. Beitrag anzeigen
    Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel.
    Na ich weiss nicht. SMT lastet ja in erster Linie die Pipelines besser aus. Wie wie lang ist die denn bei Ryzen und by Skylake? Ich glaube nicht das sich das auf die Latenzen runterbricht.

    Irgendwo hab ich übrigens gelesen das es eben nicht so sei das der Scheduler CCX aware verteilt, und wenig verwunderlich abhängige Threads die auf einem laufen schneller sind als auf CCX0 und CCX1.

    ich such mal....

    EDIT: hier

    https://www.youtube.com/watch?v=JbryPYcnscA

    macht bis 20% aus.... ziemlich eindeutig wie ich finde...Kann ja auch sein das es eine Kombo aus beidem ist. Kann Software dem Scheduler Anweisungen in irgendeiner Form mitteilen?
    Geändert von Hotstepper (15.03.2017 um 13:19 Uhr)

  8. Beitrag #7
    Captain
    Special
    Captain

    Registriert seit
    06.04.2010
    Beiträge
    215
    Danke Danke gesagt 
    7
    Danke Danke erhalten 
    7
    Nach einer News auf heise.de soll der Ryzen einen Bug bei hoch optimierten FMA3 Code besitzen. Wird aber wahrscheinlich durch ein Update des Microcodes behoben werden oder zumindest der Systemabsturz umgangen.

  9. Beitrag #8
    Cadet

    Registriert seit
    04.03.2017
    Beiträge
    36
    Danke Danke gesagt 
    4
    Danke Danke erhalten 
    0
    Die Control Fabric scheint irgendwo zu wenig Energie zu liefern, wenn man die Spannung erhöht tritt der Fehler nicht auf.
    Sollte also per AGESA behebbar sein, ohne Geschwindigkeitsverlust.

    Ryzen Locking on Certain FMA3 Workloads

  10. Beitrag #9
    Admiral
    Special
    Admiral

    Registriert seit
    16.02.2011
    Beiträge
    1.562
    Danke Danke gesagt 
    0
    Danke Danke erhalten 
    0
    Zitat Zitat von Nero24. Beitrag anzeigen
    Was aber nichts daran ändert, dass die Latenzen durch die Decke gehen sobald Kerne über CCX-Grenzen hinweg miteinander kommunzieren müssen.
    Das ist der Nachteil der Architektur die auf solche Cluster von Kernen aufbaut und bei Naples dürfte es noch schlimmer werden, wenn die Kerne nicht auf dem gleichen Die sind.
    Zitat Zitat von Nero24. Beitrag anzeigen
    Was mich überrrascht hat ist, dass die Kommunikation zweier logischer Kerne innerhalb eines physischen Zen-Kerns nach diesen Messungen etwa 26 ns dauert, wohingegen bei Intels Haswell-E nur 14 ns vergehen.
    Intel hat in dem Bereich signifikant investiert und die TSX Befehle sind nur ein Zeichen dafür, wie intensiv Intel an dem Problem der Kommunikation zwischen den Kernen gearbeitet hat. AMD kommt bei RYZEN mit 10% weniger Fläche aus, obwohl die signifikanten Strukturen bei GFs 14nm Prozess größer als bei Intels 14nm Prozess sind, es gibt also erheblich weniger Transistoren, dies hilft Energie zu sparen und damit der Effizienz, aber es hat eben auch einen Preis, wenn man die Dinge dort einfacher hält.

    Zitat Zitat von Nero24. Beitrag anzeigen
    Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel.
    Wenn SMT effizienter ist, dann ist immer etwas andere ineffizienter, da SMT immer nur ein Lückenbüßer ist und man damit die Rechenwerke auslasten kann, während ein Thread warten muss. In einer optimalen Architektur bei der alle Vorhersagen für die Sprünge und die Daten die als nächsten in den Cache zu laden sind perfekt funktionieren würde, wäre SMT sinnlos, weil es dann keine solche Lücken geben würde in denen man die Rechenwerke mit Abarbeitung der Befehle eines zweiten Threads sinnvoll auslasten kann. Die gute Effizienz von SMT könnte also die Folge der langsamen Kommunikation zwischen den Threads sein, da ist nicht wirklich ein Widerspruch vorhanden.

  11. Beitrag #10
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dalai
    • Mein System
      Notebook
      Modell: Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
      Desktopsystem
      Prozessor: AMD Athlon II X4 640 (Propus), C3
      Mainboard: Gigabyte GA-M56S-S3 mit Xigmatek Porter-N881
      Kühlung: Noctua NH-U9B
      Arbeitsspeicher: 2x 2048 MB Kingston DDR2-800 (3,0 GiB nutzbar mit x86)
      Grafikkarte: Gigabyte GeForce GTX 650 Ti, 1024 MiB, Rev 2.0
      Display: Dell U2410, 24 Zoll, IPS, 16:10
      Festplatte(n): WD1001FALS (WD Black) 1000GB SATA2, WD20EZRX (WD Green) 2000GB SATA3
      Optische Laufwerke: Pio DVR-212 (DVD-RAM), Pio DVD-106S Slot (DVD-ROM), ASUS E818AT (DVD-ROM), TEAC CD-W540E (CD-RW)
      Soundkarte: Creative SoundBlaster Audigy 2 ZS PCI
      Gehäuse: Lian Li PC-8NB Midi-Tower
      Netzteil: Enermax EPR425AWT Pro82+, 425W
      Betriebssystem(e): Windows XP Professional SP3 und immer mal wieder ein neues Linux :-)
      Browser: Mozilla Firefox mit diversen Erweiterungen
      Sonstiges: 2x 120mm Gehäuselüfter (Front und Rückwand), WinTV Theater

    Registriert seit
    13.06.2004
    Ort
    Meiningen, Thüringen
    Beiträge
    6.809
    Danke Danke gesagt 
    382
    Danke Danke erhalten 
    47
    Zitat Zitat von Nero24. Beitrag anzeigen
    Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel.
    Das ist IMO kein Widerspruch. Man muss hier eine Sache berücksichtigen: Kommunizieren die Threads viel miteinander oder bekommen die nur ihre Arbeit, erledigen diese und melden sich danach mit dem Ergebnis zurück.

    Die Verarbeitung mittels SMT kann durchaus effizient sein, aber in dem entsprechenden knapp 30minütigen Videobeitrag von PC Perspective kommt klar raus, dass die Kommunikation von Threads zwischen den beiden CCXs - also über die Inifinity Fabric - zu deutlich mehr Latenz führt. Wenn die Threads aber einfach eine bestimmte Arbeit bekommen und nach Abarbeitung nur das Ergebnis zurückgeben müssen, findet kaum Kommunikation zwischen den Threads statt, die relevant Einfluss auf die Latenz und damit auf die Performance hätten.

    Man kann davon ausgehen, dass die Kommunikation zwischen Threads bei Spielen deutlich intensiver ausfällt (Reaktion auf Eingaben des Benutzers, Aktionen der KI im Spiel etc), als das beispielsweise bei Cinebench der Fall ist, das "nur" Workers auf die vorhandenen Kerne verteilt und deren Ergebnisse darstellt.

    Grüße
    Dalai

  12. Beitrag #11
    Technische Administration
    Dinosaurier

    Avatar von tomturbo
    • Mein System
      Notebook
      Modell: Microsoft Surface Pro 4
      Desktopsystem
      Prozessor: Phenom II X6 1045T
      Mainboard: Gigabyte 970A-UD3
      Kühlung: CoolerMaster Hyper 412S
      Arbeitsspeicher: 2x8GB Crucial Ballistix Tactical DDR3-1866
      Grafikkarte: Sapphire R7 250E ultimate / lüfterlos
      Display: HP ZR2740w (2560x1440)
      SSD(s): 2xSamsung 830 128GB
      Festplatte(n): Seagate ST31500341AS 1500GB
      Optische Laufwerke: Samsung Brenner
      Soundkarte: onboard
      Gehäuse: Fractal Design Define R4
      Netzteil: XFX 550W
      Betriebssystem(e): Arch Linux, Windows VM
      Browser: Firefox + Chromium + Konqueror
    • Mein DC

      tomturbo beim Distributed Computing

      Aktuelle Projekte: SETI@HOME
      Lieblingsprojekt: SIMAP
      Rechner: i2600; Xeon E3-1245V2
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    30.11.2005
    Ort
    Österreich
    Beiträge
    6.416
    Danke Danke gesagt 
    204
    Danke Danke erhalten 
    8
    Ich glaube nicht, dass eine Kommunikation von Threads tatsächlich direkt zwischen Kernen erfolgt.
    Dazu sind die Programmiersprachen viel zu weit von der tatsächlichen Hardware entfernt.
    Variablen werden befüllt und landen in Caches auf die zugegriffen wird. Kontextswitches finden statt, usw.
    Dies ist die maßgebliche Geschwindigkeit.
    Es gibt ja nichtmal direkte Maschinenbefehle für eine Interprozessorkommunikation.
    Daher denke ich, dass dieses "Problem" keines ist und überbewertet wird.

  13. Beitrag #12
    Admiral
    Special
    Admiral

    Registriert seit
    16.02.2011
    Beiträge
    1.562
    Danke Danke gesagt 
    0
    Danke Danke erhalten 
    0
    Die Kommunikation zwischen den SW Threads läuft immer auf eine Kommunikation zwischen den Kernen/Threads der CPU hinaus, anderes kann es ja nicht gehen, wenn die SW Threads auf unterschiedlichen Kernen/Threads der CPU laufen.

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •