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 einen alternativen Browser verwenden.
NewsProzessorgerüchte: Core i9-9900K, i7-9700K und i5-9600K im Detail
Das es eine Hardware Erweiterung ist , eine in Hardware ausgeführte Funktion vielleicht ? https://de.wikipedia.org/wiki/Advanced_Vector_Extensions
Es hat Zeiten gegeben in dem das FHD encodieren eines 90 min Films in H264 einen ganzen Tag gedauert hat , grade mal 10 Jahre zurück ..
Warum ? Eben weil es da noch nicht die ganzen Hardware Erweiterungen gab , die Software diese Funktionen übernehmen mußte .
PS: Bei den neueren Intel CPU s muß der Takt bei intensiver AVX Nutzung sogar gesenkt werden weil sie sonst zuviel Leistung aus der Steckdose ziehen und zu heiß werden .
Der x86 ist ein CISC, der seit jeher mit den meisten Generationen neue Funktionen aka Instruktionen bereitstellt.
Dass die immer spezieller werden, liegt in der Natur der Sache.
SIMD Instruktionen hat der x86 seit 1997.
Das man mit AVX jetzt möglicherweise schneller Videos encoden kann, liegt daran, dass diese Funktionen früher eher in DSPs zu finden waren.
Intel: "Intel® AVX-512 is a set of new instructions that can accelerate performance for workloads and usages such as scientific simulations, financial analytics, artificial intelligence (AI)/deep learning, 3D modeling and analysis, image and audio/video processing, cryptography and data compression."
Das ist immer noch general purpose und hat meiner Meinung nach wenig mit ASICs zu tun.
Ergänzung ()
Herdware schrieb:
Dabei sollte man aber ebenfalls nicht vergessen, dass Zen in weiten Teilen eher wieder eine Rückbesinnung auf eine konventionellere x86-Architektur ist, gegenüber der radikal neuen Bulldozer-Architektur. Genauso wie Intels Core wieder ein Rückgriff war auf das alte P3-Design, nachdem sich Netburst als Sackgasse erwiesen hatte.
Man macht es sich zu einfach zu sagen, dass eine Architektur "veraltet" ist und nur mit einer neuen größere Performancesteigerungen erreicht werden können, und deshalb etwas "neues" her muss. Größere Architekturänderungen können sich als positiv herausstellen, aber auch leicht als Irrweg. Die Lektion der letzten Jahrzehnte lehrt eher, vorsichtig mit so etwas zu sein.
Die verlässlichen Performancesteigerungen kommen doch in aller Regel eher aus "gradlinigen" Verbesserungen wie höhere Taktfrequenzen, mehr Recheneinheiten, größere Caches usw. (was alles durch kleinere Strukturgrößen möglich wird) und ab und an neuen Befehlserweiterungen (z.B. AVX). Revolutionäre, grundlegende Veränderungen an der Architektur sind dafür gar nicht nötig, wenn der "Unterbau" bewährt und solide ist.
Wobei ich durchaus auch der Meinung bin, dass AMD mit Zen jetzt erst mal mehr Potential für deutliche Steigerungen hat. Nicht weil Zen grundsätzlich "moderner" wäre als Core, sondern weil in AMDs neuer Architektur im Detail sicher noch einiges an Optimierungspotential steckt (kleinere Fehler, nicht optimal abgestimmte Cache-Latenzen, versteckte Flaschenhälse usw.), gegenüber Intels Core-Architektur, bei der diese Optimierungen halt nach all den Jahren überwiegend schon drin sind.
Letztlich wird es darauf hinaus laufen, dass Zen und Core sich von der Leistungsfähigkeit der Architektur her auf sehr ähnlichem Niveau einpendeln werden, wenn erst mal beide gleichermaßen ausgereift und optimiert sind. Es kochen halt alle mit Wasser. Die Performancesteigerungen kommen dann wie gesagt fast nur noch aus langweiligem Wachstum in die "Breite".
Schöner Beitrag!
Ich frage mich, wieviel Wachstum in der Breite noch möglich sein wird. Von mehr als 8 Kernen erwarte ich für die meisten Anwendungen nicht mehr viel. Selbst eine Verdopplung der Kerne bringt dann vielleicht noch 10%. Gleichzeitig erwarte ich nur noch kleinere, inkrementelle Taktsteigerungen.
Was ich erwarte, aber das beruht nur auf amateurhaften Wissen, ist weniger Verbrauch bei gleicher Leistung durch die Veringerung der Strukturbreiten.
Ich denke ein Hemmnis für mehr Fortschritt ist die x86-Kompatibilität. Intel/AMD könnten mit der tollsten neuen Architektur aufwarten, aber wenn Windows, Office, Steam und die ganzen Games nicht darauf laufen, könnten sie das Teil gleich in Tonne treten.
Ich denke ein Hemmnis für mehr Fortschritt ist die x86-Kompatibilität. Intel/AMD könnten mit der tollsten neuen Architektur aufwarten, aber wenn Windows, Office, Steam und die ganzen Games nicht darauf laufen, könnten sie das Teil gleich in Tonne treten.
Back when AMD first announced its intentions to extend the x86 ISA to 64-bits I asked Fred Weber, AMD's old CTO, whether it really made sense to extend x86 or if Intel made the right move with Itanium and its brand new ISA. His response made sense at the time, but I didn't quite understand the magnitude of what he was saying.
Fred said that the overhead of maintaining x86 compatibility was negligible, at the time around 10% of the die was the x86 decoder and that percentage would only shrink over time. We're now at around 8x the transistor count of the K8 processor that Fred was talking about back then and the cost of maintaining x86 backwards compatibility has shrunk to a very small number. ...
AMDs K8-CPUs hatten 2003 etwas über 100 Millionen Transistoren.
Ein K10 Anno 2008 knapp 800 Millionen.
Moderne Epyc-CPUs haben jetzt über 19 Milliarden. (Zugegeben, da sind mehrere x86-Decoder drauf, aber trotzdem... )
Ich denke deshalb nicht, dass es viel bringen würde, x86 aufzugeben. Das bisschen Befehlsdecoder-Overhead geht komplett unter, gegenüber der schieren Größe und Komplexität moderner CPUs. (Was die eigentlichen Recheneinheiten und das sonstige Drumrum wie Caches, Speichercontroller usw. angeht, ist der Befehlssatz eh wurscht.)
x86-Kompatibilität aufzugeben wäre heute, in Zeiten von plattformübergreifender Softwareentwicklung, natürlich viel weniger schmerzhaft als vor 15 oder 10 Jahren, aber trotzdem lohnt es sich wohl eher noch weniger.
@Herdware
Ich bin mir nicht sicher, ob ich das verstanden habe, aber ich meinte nicht, den x86 zu erweitern, sondern eine brandneue Architektur unter Aufgabe der Kompatibilität.
Edit: Und darum scheint es in dem Artikel ja zu gehen:
The concept Fred was trying to get me to understand back in 2002 was this idea of having x86 everywhere. The instruction set didn't matter, what mattered was being able to run the same code on virtually any device. I've always pointed out that Apple must have hated making the iPhone because it became the only computer-like device in its product lineup that didn't run x86. It meant Apple had to maintain a completely separate software stack, specifically for the iPhone.
Und bespielsweise Windows und Office unter ARM zum Laufen zu bringen, hat Microsoft schon zweimal versucht. Der erste Versuch ist meines Wissens gescheitert (RT), der zweite Versuch läuft wohl noch, aber vielversprechendes habe ich noch nicht gehört.
@R1ng0
Genau darum geht es ja in dem zitierten Artikel. Es war schon vor 15 Jahren nicht mehr sinnvoll x86 zu opfern und es würde heute weniger bringen als jemals zuvor. Ein Wechsel auf einen komplett anderen Befehlssatz würde an 99,9...% einer modernen CPU nichts ändern und hätte entsprechend wenig Einfluss auf die Leistung.
Für die Kompatibilität zum x86-Befehlssatz ist nur noch ein winzig kleiner Teil (Decoder) auf modernen CPUs verantwortlich. Der Rest ist davon eh unabhängig und wird grundsätzlich z.B. auf einem ARM nicht viel anders aussehen als auf einer Core- oder Zen-CPU.
Intern haben ja moderne x86-CPUs eh lange nicht mehr viel mit einem 8086 zu tun. Die arbeiten mit Micro-Ops, sind also im Kern eher RISC-CPUs, die nur nach außen so tun, als wären sie noch CISC.
Dem ganzen sonstigen Drumherum (was früher mal North- und Southbridge war und jetzt Teil der CPU ist) ist der Befehlssatz eh wurscht.
Ich will nicht ausschließen, dass es, abseits von der CPU-Hardware selbst, gewisse Vorteile haben könnte, von x86 abzurücken. Wobei heutige Softwareentwickler wahrscheinlich eh nicht mehr besonders viel mit den eigentlichen Befehlssätzen der CPU in Berührung kommen. Eben wegen der modernen, plattformunabhängigen Entwicklungswerkzeuge mit diversen Abstraktionsschichten/APIs.
Man entschuldige, wenn ich da falsch liegen sollte. Ich bin kein Profi in Sachen CPU- und Software-Entwicklung, sondern nur ein interessierter Laie.
Nein sind sie nicht , es sind x86 Prozessoren ...
wobei der Ryzen einen Risc Coprozessor hat ( Sicherheitscoprozessor , generiert Hash Werte zum verschlüsseln )
Das mit den 720p geht mir auch auf den Sack. Das ist kompletter Schwachsinn. Dass das später nicht stimmen muss, hat irgendein Youtube-Kanal mal genauer gezeigt.
So, jetzt hab ich das tatsächlich wieder gefunden. Das war das Video "Ryzen - The Tech Press Loses The Plot" von AdoredTV. Da hat man sich die Performance-Ratings von CPUs über die Jahre angeguckt und den FX-8350 (bzw. den annhähernd gleichen FX-8370) mit dem i5-2500K verglichen.
Der i5 hat 4C/4T und lag 2012 klar vorne. Der FX-83x0 konnte zunächst aus seinen 8 Integer-Kernen kein Kapital schlagen. Das blieb auch bei neuen Grafikkarten so, allerdings wurde die Lücke teilweise schon kleiner, von zunächst 10,4% auf 8,2% in 1080p. Und bei den ja eigentlich extra für den Ausblick auf kommende Jahre gedachten Messungen in 480p/720p schrumpte der Vorsprung des i5 sogar von 17,2% auf 10,6% ein. Mit einem Wechsel des Spiele-Parcours auf eine breitere Auswahl und der Nutzung einer Titan Xp in 2017 kehrte es sich dann sogar dramatisch um und nun lag der FX-83x0 um 9-10% vorne.
Das ist also ein konkretes Beispiel, wie sich die Zukunft dummerweise genau umgekehrt zur ursprünglichen Prognose mit niedriger Auflösung verhalten hat. Der zunächst schnellere Prozessor blieb eben nicht vorne. Warum? Weil irgendwann halt doch Spiele kamen, die mehr als 4 Threads nutzen können. Und eventuell wäre der Umschwung auch früher passiert, wenn man häufiger die Auswahl an Spielen geändert hätte.
Die Tests mit niedriger Auflösung sind also nur in sehr begrenztem Maße für den gedachten Zweck brauchbar. Sobald die verglichenen CPUs stark in ihren Charakteristika voneinander abweichen, ist die Zukunftsprognose bloße Makulatur.
RISC und CISC sind doch Eigenschaften der ISA, die beschreibt, wie ich mittels eines Assemblers Programme für diese Architektur erstellen kann.
Und das Instruktionsset auch moderner x86er ist doch eindeutig CISC (und das Developer's Manual hat immerhin 4844 Seiten, nicht besonders 'reduced').
Wie diese ISA dann von Intel implementiert ist, sei mal dahingestellt, ist aber auch Intels Geschäftsgeheimnis und nicht dokumentiert.
Naja, in 2018 etwas als Workstation zu bezeichnen, was nur 6 Kerne hat (und womit ohnehin schon der bessere SpielerHochleistungsgamer unterwegs ist), insbesondere zu einer Zeit, wo acht Kerne und mehr erschwinglich genug geworden sind, daß sich neuerlich selbst der Durchschnittsbürger solche leisten kann, ist doch etwas … skurril.
Ich für meinen Teil bin dazu über gegangen, nicht länger Hardware zu nutzen, die mir eventuell in vereinzelten Konstellationen eine leicht schnellere Ausführung erlaubt – mir zeitgleich aber die Zukunft in dem Sinne verbaut, daß ich die deutlich größeren Vorteile (multipler & synchroner weil zeitgleicher Ausführung) der Arbeit die Entwickler in ihre Produkte investieren, die sich endlich einmal die Mühe machen, dem Markt entgegen zu arbeiten (i.S.v mit dem Markt), nicht werde nutzen können.
Wir hängen seit Urzeiten (+10 Jahre) software-technisch in begrenzenden Single-Threaded-Leistungen und belohnen damit oft genug direkt die Bequemheit der Entwickler, noch immer auf völlig veralteten Single-Thread-Routinen zu setzen. Auf der anderen Seite hat man die letzten +2–4 Jahre gesehen, daß viele Entwickler oder Systemhäuser plötzlich sehr wohl auf Mehrkern-Prozessoren optimieren können (wenn sie denn wollen …).
Ja, ich weiß, es gibt immer Dinge, die sich nicht in stärkerem Maße parallelisieren lassen werden und nicht großartig von Mehrkern-Prozessoren profitieren. Trotz allem erlebt man immer wieder, daß plötzlich Software A oder B nach gegebenen Aktualisierungen doch ganz gut multi-threaded laufen kann – und daß, obwohl der Entwickler über Jahre immer wieder betont hat, daß eine Mehrkern-Optimierung a) nicht wirklich umsetzbar ist oder b) den Aufwand nicht lohnt.
Kurzum, wenn ein Programm noch immer nur Single-Threaded ist, versuche ich es seit ein paar Jahren entweder gar nicht mehr einzusetzen oder aber mich nach Alternativen umzuschauen. Überraschenderweise bin ich damit bisher doch erstaunlich gut gefahren!
Denn, seien wir mal ehrlich; Selbst die angesehensten Entwickler und größten Namen haben sich bis jetzt noch immer bewegt, wenn sie merken mußten, daß der Kreis der Anwender immer kleiner wird und es plötzlich anfängt auch finanziell weh zu tun.
Und da darf ich aus Erfahrung sprechen, weil selber zeitweise in der bequemen Position auf der Gegenseite:
Als Entwickler lebt es sich trotz der vielen und oftmals nervenden Wehklagen der Anwenderschaft obschon einer Mehrkern-Unterstützung und/oder nicht-kritischen/kleineren Bug-Reports doch recht entspannt, wenn man ein etabliertes weil alt eingesessenes Produkt mit Namen sein eigen nennt – solange die Lizenz-Gebühren von Stammkunden und Verkaufserlöse von eher unwissenden Neukäufern monatlich herein kommen. Da ist man dann ganz schnell bei der Devise „Läuft. Weitermachen!“ und man legt auf gut Deutsch „die Beine hoch“. Warum denn auch nicht – es läuft ja. Jedenfalls wird da nichts am Bestehenden geändert, solange das Haus nicht unmittelbar in Flammen steht, und da ist die Motivationsschwelle seitens der Entwickler und/oder Geschäftsführung doch schon etwas höher …
Naja, in 2018 etwas als Workstation zu bezeichnen, was nur 6 Kerne hat (und womit ohnehin schon der bessere SpielerHochleistungsgamer unterwegs ist), insbesondere zu einer Zeit, wo acht Kerne und mehr erschwinglich genug geworden sind, daß sich neuerlich selbst der Durchschnittsbürger solche leisten kann, ist doch etwas … skurril. Anhang anzeigen 696933
Skurril wäre es, wenn ich mir eine CPU aussuchen würde die in allen anderen Anwendungen die schnellste wäre, nur nicht in denen die ich beruflich tagtäglich nutze -> Solidworks
Die Links hast Du ja hoffentlich gesehen und auch angeschaut ...
Im Prinzip arbeiten heutige x86/x64-kompatible Prozessoren von Intel wie AMD zu größeren Teilen tatsächlich wie RISC-Prozessoren, die intern zu großen Teilen doch sehr ähnlich funktionieren – und nur nach außen hin sich als CISC-Architektur verhalten. Da hat @MK one schon nicht ganz unrecht …
Zwar verwenden sie keine unmittelbaren RISC-Befehlssätze irgendeiner RISC-Architektur, allerdings arbeiten sie (insbesondere AMD) mit Micro-Ops, die mehrere (Einzel-) Befehle in mehrkettigen Mikro-Operationen und damit kombinierten Befehlsketten zusammen fassen und damit innerhalb eines Taktzyklus be- und abarbeiten können (AMD's Zen-Architektur kann glaube ich gar sechs die Micro-Ops je Takt ausführen). Eben auf diesem einfachen Prinzip beruhen sämtliche RISC-Architekturen.
RISC ist daher auch weniger eine explizite Architektur (auch wenn in der Vergangenheit definierte Standards von Befehlssätzen zu 'einer', oder der RISC™-Architektur zusammengefaßt wurden) als vielmehr eine Beschreibung der Eigenart der Befehlssatzverarbeitung. Das bedeutet, auch wenn sie (x86/64) keine echten RISC™-Architekturen sind und als CISC gelten mögen, vom Prinzip her verhalten sie sich intern gemäß der RISC-Logik.
R1ng0 schrieb:
Und das Instruktionsset auch moderner x86er ist doch eindeutig CISC (und das Developer's Manual hat immerhin 4844 Seiten, nicht besonders 'reduced').
Die Dicke und der Umfang der Dokumentation ist aber in diesem Fall doch hoffentlich nicht ein Für und Argument, was in diesem Falle die Nähe zur CISC-Architektur nahelegenbelegen soll, oder?
Sehr geil. Danke. Hätte ich mir ja fast denken können, dass der es war.
Mit meinen Scuhbegriffen (Comaprison, CPU, analysis, generations etc. pp.) hatte ich leider kein Glück.
)
