Ja hast du selbst keine und suchst noch welche oder was meinst du?
Schon bei den beiden erfährt man mehr als 90% auf Steam jemals sonst beim Zocken mitbekommen würde. Meinst du pixelgenaue Verläufe von einer halben Stunde an Frametimes oder sowas?
Rocket Lake-S: Angeblich mit über 5 GHz, 10 Prozent mehr IPC - aber hoher TDP
- Ersteller PCGH-Redaktion
- Erstellt am
Schon bei den beiden erfährt man mehr als 90% auf Steam jemals sonst beim Zocken mitbekommen würde. Meinst du pixelgenaue Verläufe von einer halben Stunde an Frametimes oder sowas?
G
gaussmath
Guest
So kurz dabei und bereits in so hoher Konzentration mit Hingabe heiße Luft verströmt. Reife "Leistung".
Bspw. haben die SSE (bzw. SIMD) -Befehlssätze noch einen anderen großen Vorteil: Sie können einigen, in Zeiten von Multithreading möglicherweise etwas "kernschwachen" CPUs ein wenig auf die Sprünge helfen.
Ben Supnik, einer der Entwickler des Flugsimulators X-Plane, beschreibt das in seinem Entwickler-Blog etwas genauer:
Und da recht häufig darauf zurückgegriffen wird, sollte sich kein X-Plane-User über die doch recht heftig gestiegenen CPU-Temps beim Spielen wundern.
Ah verstehe,SSE Einheiten sind also gut.Sie lasten also weniger Kerner besser aus,bei mehrkernigen sieht die Sache ja dann ganz anders aus.Ist dennoch interessant was die Vorgänger von AVX also die SSE EInheiten dazu m stande sind.Da ja die SSE Einheiten die Vorgänger sind,sind freilich das ja dann ebenfalls Floingpoint EInheiten.AVX ist somit nicht die einzige EInheit die drauf basiert.Die MMX Einheiten basieren jedoch auf Integer weil sie ja anders als die SSE EInheiten sind.Es stand zwar auch was von Integer,aber ich weis halt leider nicht weil es im wickipedia so undeutlich ist.DIe wissen halt auch nicht so genau zu was es am ende ja gehört.Aber nun gut,so wie es ist ist es halt.
Nennst du das eine sachliche Antwort auf die sachliche Frage? Beschäftigst dich lieber mit der Person statt mit der Sache?
@espacko
Wer im Netz ist heutzutage vertrauneswürdig? Es gilt immer, schau trau wem. Am besten auch jedes Mal aufs Neue.
Methusalem
Freizeitschrauber(in)
Ja, warum sollte das was Schlechtes sein?
Prinzipiell sind die ganzen MM-Extensions, angefangen von Intels Pentium MMX und AMDs 3DNow! bis hin zum heutigen AVX usw. sogar eine ziemlich gute Sache.
Wenn, sagen wir, 4 gleichartige Operationen gleichzeitig auf 4 Kernen stattfinden, muss ja das Ziel, nämlich die Zusammenführung der einzelnen Threads zu einem bestimmten Zeitpunkt - bspw. zum Zweck der Ausgabe eines Bildes - trotzdem gewährleistet sein. Dazu ist CPU-interner Verwaltungsaufwand nötig, der etwas Zeit kosten kann. Vorteil ist hier allerdings die bessere Lastaufteilung auf einzelne Kerne, d.h., die CPU sollte kühler bleiben, ein Riesenvorteil bei Konsolen, die ja bekanntlich über recht enge und weniger gut be- und entlüftete Gehäuse verfügen.
Dagegen kann der Verwaltungszeitaufwand u.U. durch den Gebrauch der MMX (und aller Nachfolger) - Befehle minimiert werden. Ein Input reicht, um die Arbeit der 4 Kerne aus obigem Beispiel zu ersetzen, der Verwaltungsaufwand ist geringer, insgesamt die Ausführung dadurch schneller. Da die Last allerdings von nur einem Kern getragen wird, wird dieser entsprechend wärmer. Und das ist halt der Nachteil von AVX und Co, für mich aber ein eher kleinerer Nachteil.
Zum Lesen als kleine Einführung (vielleicht sind kleine Programmiervorkenntnisse nicht von Nachteil
):SIMD Programmierung mit GCC
Ja, warum sollte das was Schlechtes sein?
Prinzipiell sind die ganzen MM-Extensions, angefangen von Intels Pentium MMX und AMDs 3DNow! bis hin zum heutigen AVX usw. sogar eine ziemlich gute Sache.
Wenn, sagen wir, 4 gleichartige Operationen gleichzeitig auf 4 Kernen stattfinden, muss ja das Ziel, nämlich die Zusammenführung der einzelnen Threads zu einem bestimmten Zeitpunkt - bspw. zum Zweck der Ausgabe eines Bildes - trotzdem gewährleistet sein. Dazu ist CPU-interner Verwaltungsaufwand nötig, der etwas Zeit kosten kann. Vorteil ist hier allerdings die bessere Lastaufteilung auf einzelne Kerne, d.h., die CPU sollte kühler bleiben, ein Riesenvorteil bei Konsolen, die ja bekanntlich über recht enge und weniger gut be- und entlüftete Gehäuse verfügen.
Dagegen kann der Verwaltungszeitaufwand u.U. durch den Gebrauch der MMX (und aller Nachfolger) - Befehle minimiert werden. Ein Input reicht, um die Arbeit der 4 Kerne aus obigem Beispiel zu ersetzen, der Verwaltungsaufwand ist geringer, insgesamt die Ausführung dadurch schneller. Da die Last allerdings von nur einem Kern getragen wird, wird dieser entsprechend wärmer. Und das ist halt der Nachteil von AVX und Co, für mich aber ein eher kleinerer Nachteil.
Zum Lesen als kleine Einführung (vielleicht sind kleine Programmiervorkenntnisse nicht von Nachteil
SIMD Programmierung mit GCC
Ah OK. Du willst mir damit sagen das mmx, sse genau wie avx die selbe kerbe schlägt. Das sk d also alles floing point gleitkomma befehlsätze. Und das davon ist denn dann integer. Gehe mal davon aus das die SSE Einheiten eben nicht zu integer gehören. Was davon gehört denn zu den integer Einheiten von den befehlsätzen?
Methusalem
Freizeitschrauber(in)
Damit sind also alle SSE Einheiten von 1-4 gemeint und nicht nur SSE1 oder?
Ich verstehe. Mit single floing point sind es also 32 bit Einheiten. Wären es ja double dann würde es ja 64 bit sein ich verstehe.
Zu Business-Vertragsmodalitäten kann ich nichts sagen, auch weiß ich nicht in welchen Zeiträumen Dell welche Office-AMD-Produkte angeboten hat – privat betrifft es mich nicht (wir haben kein Dell auf Arbeit ^^) und "... gibt es nicht" hat mich nur vereinzelt zum Nachschauen angeregt. Ich weiß aber noch aus den 0er Jahren, dass Dell nach dem großen Einstieg mit AMD (unmittelbar nach Ende der Intel-exklusiv-Verträge wurden quasi 20 Prozent des Portfolios alternativ auch mit Athlons angeboten) sehr enttäuscht über die Absatzzahlen war. Danach werden sie vermutlich nach und nach die ohnehin nicht nachgefragten Modelle aus dem Angebot gestrichen habe und ich zum Beispiel wüsste nicht, wie ich unsere IT überhaupt dazu bewegen sollte, für eine leistungsfähigere IGP im Arbeitsnotebook mehr Geld auszugeben. Da kommt, vollkommen zu Recht, die Antwort "du sollst arbeiten, nicht zocken"
Ryzen 3100 und 3500 haben zur Hälfte deaktivierte Caches in ihren CCX.
Die meisten CCDs mit defekten Cache-Bereichen scheinen aber als Epyc zu enden.
Der Programmierer muss da von Hand gar nichts machen (auch wenn er kann), das übernimmt im Normalfall der Compiler. Bedeutet allerdings aber dennoch: Software, bei deren Erstellung neue Befehlssätze nicht berücksichtigt wurden, kann diese nicht benutzen.
Die AVX-Register sind für Gleitkomma:
Die 80-Bit Floatingpoint Register (extended) sind auf dem Schaubild in türkis mit ST. Dort scheint dann noch ein Unterregister für 64-bit Floatingpoint (double) als Teilregister enthalten zu sein.[/QUOTE]
80 Bit sind die alten x87-Register, eng vernküpft mit MMX. Die haben zumindest formell (bei der physischen Umsetzung weiß ich es gerade nicht) nichts mit den SIMD-Konzepten seit KNI/SSE zu tun.
Bspw. haben die SSE (bzw. SIMD) -Befehlssätze noch einen anderen großen Vorteil: Sie können einigen, in Zeiten von Multithreading möglicherweise etwas "kernschwachen" CPUs ein wenig auf die Sprünge helfen.
Ben Supnik, einer der Entwickler des Flugsimulators X-Plane, beschreibt das in seinem Entwickler-Blog etwas genauer:
Und da recht häufig darauf zurückgegriffen wird, sollte sich kein X-Plane-User über die doch recht heftig gestiegenen CPU-Temps beim Spielen wundern.
Ich glaube, da liegt ein Missverständnis vor: Zwar ist der beschriebene Workload offensichtlich gut für SIMD geeignet (und es war somit reichlich dämlich, ihn zunächst via x86 berechnen zu lassen), aber die Reduzierung der Thread-Anzahl hat damit weniger etwas zu tun. Dank SSE _kann_ man die Berechnungen in einem Kern ablaufen lassen, aber man muss es nicht. Die Entwickler sind aber offensichlicht zu dem Schluss gekommen, dass der zusätzliche Overhead und Latenzprobleme von zu vielen Threads auf kleineren CPUs mehr Schaden als sie auf großen nützen, deswegen hat man diese Möglichkeit zur Reduktion der Threadzahl ergriffen. Man hätte aber auch an anderer Stelle sparen können. Umgekehrt hat man dadurch die CPU-Anforderungen dieses Sub-Tasks deutlich gesteigert: Er muss jetzt in einem Thread berechnet werden. Alte CPUs mit vielen Kernen, aber wenig Single-Thread-Leistung hätten damit ein Problem. (Aber vermutlich ist es für die Entwickler wichtiger, dass der neue FS auf einem Core i3 läuft, als auf einem 16-Kern-Atom-Xeon oder einem runtergetakteten FX)
Siehe den bereits geposteten Link: Drei von vier großen Mainboard-Herstellern investieren in die PCI-E-4.0-Kompatiblität ihrer heutigen Sockel-1200-Platinen. Sämtliche Leaks sprechen von PCI-E-4.0-Tauglichkeit. Intel hat sonst keine CPUs mehr auf der Roadmap, von denen nicht PCI-E 4.0 erwartet wird oder sogar schon zugesagt wurde.
Man soll böse Überraschungen nie ausschließen (gerade bei neuen Intel-CPUs ^^), aber noch sicherer kann man die Frage nach PCI-E 4.0 für RKL wohl erst beantworten, wenn die CPUs offiziell vorgestellt werden.
Gute Frage. Die meisten Leute denken beim Pentium 4 an die letzte Generation (auch wenn er da nur noch die Billig-Alternative zum D war) und damit an eine fehlgeleitete Architektur, die trotz guter Fertigung nicht wirklich überzeugen konnte. Also das genaue Gegenteil des Problems sämtlicher Skylake-Nachfolger.
(Die erste Netburst-Generation war dagegen, genau wie RKL, ein Backport und hatte deswegen massive Taktprobleme. Wer bei heutigen Intel-News wirklich spontan "PGA423!" denkt und nicht nur trollen will, darf sich also einen Keks nehmen.)
SIMD steht allgemein erstmal nur dafür dass man den selben Befehl gleichzeitig auf mehrere Daten anwendet.
In der Umsetzung SSE war das meistens 32-64Bit FP. AVX ist quasi der Nachfolger und hat 256Bit und Integer hinzugefügt. AVX512 gar bis zu 512Bit.
Fieß wird es wenn ein Prozessor den Befehlssatz zwar unterstützt aber intern wenig dafür geeignet ist weil die FP-Unit und ALU das Ganze doch wieder seriell lösen müssen. Dann bleibt die erhoffte Beschleunigung aus oder ist wegen teurer Kontextwechsel unter Umständen sogar langsamer als eine Umsetzung mit alten Befehlen. Bei AMD haben zur AVX Einführung z.B. 256Bit Befehle immer zwei Zyklen gebraucht. Ergo war man oft 0% schneller als mit SSE Code.
Ryzen 3100 und 3500 haben zur Hälfte deaktivierte Caches in ihren CCX.
Die meisten CCDs mit defekten Cache-Bereichen scheinen aber als Epyc zu enden.
Vielen Dank für den Hinweis/Anstoß. Habe daraufhin noch einmal nachgesehen und die zugehörige Slide gefunden. Konkret wird der Cache nur im Ryzen 3 3100 teildeaktiviert. Der Cache scheint also bei Zen2 zumindest aus zwei Slices zu bestehen.
Im Ryzen 3 3300X wird tatsächlich ein komlettes CCX deaktiviert, d. h. alle vier Kerne residieren mit den vollen 16 MiB L3 in einem CCX, was zudem die Core-2-Core-Latenz im Mittel geringer halten sollte i. V. z. Ryzen 3 3100.Hatten wir das nicht schon vor kurzem?
SSE kann schon ab SSE2 üb er die 128bit "Vektoren" auch
AVX kann man übrigens auch mit 128bit fahren. AVX-128. Das macht Sinn wenn man ggf. sachte migrieren sollte, eben das im ersten Schritt zu machen, wenn man seine SSE-Routinen überarbeitet. Der Wechsel von SSE auf AVX innerhalb der Instanz ist nämlich sonst ganz böse was Strafzyklen angeht. Das ist böse mehr als nur die "70" Zyklen die im Netz rumgeistern, weil das einer von Apple bei Intel
mal einen Blog machte. Das kratzt meist und real fast am Doppelten davon.Etwaige Umschalterei zwischen AVX-128 und AVX (256) wenn man dann alles nach und nach erweitern sollte, kostet dagegen nichts mehr nennenswertes.
Dem Glauben, der Compiler erledigt die meiste Arbeit, dem kann ich mich leider nicht anschließen
Spätestens wenn einem die Brocken vom Kernel aus dem L2Data kurz rausgeworfen werden kostet das schon schmerzhaft Leistung bei AVX.Kann man imho leicht auseinanderhalten. Zen1 hatte das so, Zen2 zieht alles in einem durch. Fertig.
Zuletzt bearbeitet:
Verstehe 2,4 und 8 bit Integer,das sind aber niedrige EInheiten die gebraucht werden. Das heißt wenn das also Zen 3 genau das alles verbessern,dann ist davon auszugehen das es niedrigere Leistungssteigerungen zu erwarten sind.Ohne AVX sind die zahlen somit bei Integer und Floingpoint verdammt niedrig.Das Potenzial schöpfe ich somit weniger aus.Das führt zu niedrigere Leistungssteigerung.Ich darf somit keine hohen Leistungssteigerungen erwarten.Denn das wäre ja wohl zu unrealistisch.Bin gespannt welchen Instuktionen AMD und Intel wirklich beschleunigen am ende.Denn ich kann mir nicht vostellen das alle Instuktionen gleichermaßen bescheunigt werden können.AMD Optimiert ja nicht viel von Zen 2 zu Zen 3.Was ich also dank euch allen so gelesen habe,ist meine Leistungssteigerungs erwartungen weiter gesunken.Das dürfte denke ich mal dann auch weitaus realistischer sein,als zu hohe erwartungen zu haben. Cache Optmierung wie es die neuen Ryzen 3 CPUS erreichten,brachte bei mir ebenso keine richtigen Verbesserungen bei der Leistung.
Und bis auf das was wir ja so wissen,kommt ja nichts weiteres bei AMD raus was noch Optimiert wird und bei Intel ist es ja ebenso offensichtlich was sie da so Verbessert haben.Ist somit nicht viel.Hatte wohl zu hohe Erwartungen.Aber gut das ich auf den boden der Tatsachen geholt wurde.
PS: Bezieht sich diese 2,4 und 8 bit Integer also auf alle SSE Befehlsätze also Sprich SSE1,SSE2,SSE3,SSSE3,SSE4 und SSE4.2 oder nur auf SSE2 alleine?
Und bis auf das was wir ja so wissen,kommt ja nichts weiteres bei AMD raus was noch Optimiert wird und bei Intel ist es ja ebenso offensichtlich was sie da so Verbessert haben.Ist somit nicht viel.Hatte wohl zu hohe Erwartungen.Aber gut das ich auf den boden der Tatsachen geholt wurde.
PS: Bezieht sich diese 2,4 und 8 bit Integer also auf alle SSE Befehlsätze also Sprich SSE1,SSE2,SSE3,SSSE3,SSE4 und SSE4.2 oder nur auf SSE2 alleine?
Zuletzt bearbeitet:
Danke. Hab da was "durchgewürfelt" 
Das sollte wohl Bytes sein...
Hier beschäftigt sich jemand mit AltiVec vs. SSE2 (und Integer)
Hardware - SSE Performance Programming
Deine Texte verwirren mich... Bist du ein Programmierer?
Das sollte wohl Bytes sein...Hier beschäftigt sich jemand mit AltiVec vs. SSE2 (und Integer)
Hardware - SSE Performance Programming
Deine Texte verwirren mich... Bist du ein Programmierer?
Zuletzt bearbeitet:
Meinst du mich damit,wenn ja wie kommst du zu der Annahme das ich ein Programierer wäre?Danke. Hab da was "durchgewürfelt"
Hier beschäftigt sich jemand mit AltiVec vs. SSE2 (und Integer)
Hardware - SSE Performance Programming
Deine Texte verwirren mich... Bist du ein Programmierer?
R
Rotkaeppchen
Guest
Es sind in beiden Fällen 2666er RAM
Aber das mit den Sicherheitspatch ist natürlich ein Argument. Ich habe es auch erst einmal nur erstaunt festgestellt, dass der neue kleine i5 dem vermutlich baugleichem Chip deralten 8000er i7er Reihe in nix nachsteht und das mit 10 weniger Takt.
Weil du dir dauernd Gedanken über Register & Co. machst. Das wirkt irgendwie seltsam
Achso verstehe.Ich will halt genau herausfinden,welche Einheiten für das Videoumwandeln am wichtigsten ist.Nun weis ich ja dank euch mehr.
Das die Instuktion BMI1 der Takt am wichtigsten ist,da es auf 1 Kern begrenzt ist.Und das es ab SSE2 Integer wichtiger ist.
Und ich habe auch gelesen wieviel IPC steigerung welche Generation zwischen Zen1 und Zen+ bei 10 % IPC steigerung gewesen war.Nach abzug von IPC sind es somit bei 33 % -10 % also 23 % reine Leistungssteigerung außerhalb von IPC.
Bei Zen+ zu Zen 2 sind es 13 % IPC Steigerung und da waren es nur noch 27 % mehrleistung,macht somit 14 % auserhalb von IPC steigerung.
Und mit Zen 3 sind es somit da es ja 15 % sind außerhalb nur noch 4 % mehr Leistungssteigerung.Das macht dann alles die SSE Einheiten aus.
Da ich ja garkein AVX verwende,da ich dies ja abgeschaltet habe also sprich bei allen CPU und auch den gleichen Takt,nämlich bei 4 ghz.
Somit kann man sagen SSE zählt ja ebenso zu der Achetektur verbesserung.Cache L1 sowie L3 scheint für SSE EInheiten wichtig zu sein.
Nun kann ich also die Leistung besser einschätzen.Ist halt fraglich ob ich richtig liege,denn die AGUS sind wichtig für diese SSE Einheit.
Da sich jedoch das sich ja nicht so verändert wie bei Threadripper 2950x zu 3950x erwarte ich somit keine sehr hohe Leistungssteigerung.
DKK007
PCGH-Community-Veteran(in)
Ist bloß nicht der Fall. Die CPUs werden eher gerade so die 5 GHz schaffen, so wie es bisher anzunehmen ist.
Danke. Hab da was "durchgewürfelt"
Natürlich sind es Byte. Auf einzelne Bit lässt sich im Hauptspeicher gar nicht zugreifen.
Wie die Datentypen heißen hängt von der Programmiersprache ab.
Für Ganzzahlen:
int8 = 1 Byte (8 Bit)
int16 / Word = 2 Byte (16 Bit)
int32 / Integer = 4 Byte (32 Bit)
int64 / Longint = 8 Byte (64 Bit)
Weil du dir dauernd Gedanken über Register & Co. machst. Das wirkt irgendwie seltsam
Was aber genau das Problem ist. Ohne Verständnis der Datentypen aus der Programmierung ist es schwer dann gleich die CPU-Register zu verstehen.
Hängt dann aber wie immer natürlich vom Compiler ab. Der GCC sollte es zumindest ab einer bestimmten Optimierungsstufe automatisch machen. Beim FPC weiß ich es nicht.
Geht auch aus dem Wiki nicht klar hervor.
Vectorization - Lazarus wiki
Optimization - Free Pascal wiki
Zuletzt bearbeitet:
Das heist diese Erkenntnisse bringen mir am ende doch nichts,weil ich den Programiercode nicht kenne.
Das heißt wie viel die Beschleuniger also in dem Sinne Instuktionen ,sagt am ende also doch nichts aus.
Ich weis nur das ich an den EInstellungen beim Programm nichts verändert habe.Ich messe somit am ende das was bei allen CPU dabei raus kommt.
Ich merke zwar nen Geschwindigkeitsunterschied,weis allerdings nicht welchen Datentyp das Programm so alles verwendet.Man kriegt es somit wirklich nicht so einfach dabei raus.Schade.Werde das gleiche mal beim I9 18 Kerner mal ausprobieren ob ich da ebenfalls 10 Sekunden Leistungsunterschied bei alle MMX sowie SSE EInheiten haben werde.Wenn es am ende weniger ist,dann beschleunigt am ende was anderes das ganze.
Und es spielt ja auch das verwendete Betriebsystem ne Rolle.Bei den anderen CPUs waren es allesamt WIndows 10.Bei mir wird allerdings nur WIndows 7 verwendet.Ich bemerkte das es bei mir rund 7 Sekunden schneller ist.Selbst als ich WIndows 10 verwendet hatte,war es langsamer gewesen.Im Grunde müsste ich therretisch bei allen Ergebnissen außer bei mir 7 Sekunden abziehen.Dann würde es am ende wohl anders aussehen.
Klar ist auch je niedriger ich die Settings beim Umwandeln einstelle,desto mehr verlieren noch mehr vielkerner an Leistung.Das ist mir aufgefallen als ich da Bewegunsanalyse reduziert sowie Mp3 anstatt AAC verwendet hatte.So hatte sich der abstand zwischen 3950x zu 3970x sich verringert gehabt.Denn die Leistungssteigerung war beim 3970x nicht so hoch gewesen wie beim 3950x.Somit war der Abstand statt zuvor 19 & 18 Sekunden am ende nur noch bei 11 &13 Sekunden.
Therretisch müsste somit wenn ich das totale minimum also schlechtesten settings einstelle die man so einstellen kann,der abstand am ende bei unentschieden rauskommen.
Man kann also sagen das da am ende mehr entscheidet als nur die Beschleuniger Instuktionen.
Ähnliche Themen
