App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
News 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
(…)
» Artikel lesen
MacroWelle
Captain Special
- Mitglied seit
- 15.02.2008
- Beiträge
- 236
- Renomée
- 1
Ich weiß nicht welches Video ihr gesehen habt, aber der Artikel bei pcper sagt was anderes: https://www.pcper.com/image/view/79526?return=node/67315
Hätte nicht gedacht, dass ich hier mal Windows verteidigen muss
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
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.
DonL_
Vice Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 765
- Renomée
- 12
- Standort
- Hannover
- Prozessor
- AMD Phenom X6 @ bis 3,7 GHZ
- Mainboard
- Asrok 870 Extreme3
- Kühlung
- CPU: Arctic Freezer Pro 64
- Speicher
- 4 x 2048 MB Kingston DDR 3 - 1333
- Grafikprozessor
- Saphire RX 460 Nitro 4G
- Display
- AOC G2460VQ6
- SSD
- Samsung Evo 840 250GB
- HDD
- 1 x Samsung HD501LJ SATA, Samsung HD 204UI
- Optisches Laufwerk
- LG DVDRAM
- Soundkarte
- On Board
- Gehäuse
- Chiftec Mesh Tower
- Netzteil
- BE Quiet Pure Power 430W
- Betriebssystem
- Windows 7
- Webbrowser
- Firefox
@ Nero24
Wie sieht es denn bei euren Tests aus, seit ihr schon ein paar Geheimnissen auf der Spur?
Wie sieht es denn bei euren Tests aus, seit ihr schon ein paar Geheimnissen auf der Spur?
Hotstepper
Vice Admiral Special
- Mitglied seit
- 12.04.2005
- Beiträge
- 831
- Renomée
- 117
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?
Zuletzt bearbeitet:
Pinnacle Ridge
Vice Admiral Special
- Mitglied seit
- 04.03.2017
- Beiträge
- 528
- Renomée
- 7
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
Sollte also per AGESA behebbar sein, ohne Geschwindigkeitsverlust.
Ryzen Locking on Certain FMA3 Workloads
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.Was aber nichts daran ändert, dass die Latenzen durch die Decke gehen sobald Kerne über CCX-Grenzen hinweg miteinander kommunzieren müssen.
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.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.
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.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.
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
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.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.
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
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
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.
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.
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.
Ähnliche Themen
- Antworten
- 8
- Aufrufe
- 2K
- Antworten
- 0
- Aufrufe
- 806
- Antworten
- 7
- Aufrufe
- 2K
- Antworten
- 12
- Aufrufe
- 3K