Rocket Lake-S: Angeblich mit über 5 GHz, 10 Prozent mehr IPC - aber hoher TDP

Ich würde einfach raten ein wenig selbst zu Programmieren.
Bei Programmiersprachen wäre da Pascal bzw. wenn es noch hardwarenäher sein soll klassisches C zu empfehlen.

Und dann kannst du im Debugger auch einfach mal schauen, was der Compiler so an Assembler draus macht.

Übrigens: Fehlende Leerzeichen hinter den Punkten erschweren das Lesen, gerade zur aktuellen Uhrzeit.
 
Ich würde einfach raten ein wenig selbst zu Programmieren.
Bei Programmiersprachen wäre da Pascal bzw. wenn es noch hardwarenäher sein soll klassisches C zu empfehlen.

Und dann kannst du im Debugger auch einfach mal schauen, was der Compiler so an Assembler draus macht.

Übrigens: Fehlende Leerzeichen hinter den Punkten erschweren das Lesen, gerade zur aktuellen Uhrzeit.

Ja sorry,scheine wohl auch schon etwas müde zu sein.Habe was interessantes im Forum gelesen.Weis nicht ob das interessant ist.Aber da wird ebenso darüber unterhalten. Scheint wohl generell beim VIdeoumwandeln so Probleme zu haben. Zietiere Text ausschnitt und Quell seite dazu.



ch lach mich kaputt... Da gibt's noch genügend Baustellen bei HEVC, die größte ist, daß es keine Authoringsoftware für H265 gibt. Ist quasi wie beim Flughafen Berlin. Da faseln die schon vom Nachfolger. Abgesehen davon hat sich die UHD-BD noch nicht durchgesetzt - noch zäher, als bei der BD. Erstens mangelte es an Abspielgeräten, zweitens mangels Rohlingen (BD-XL und UHD-BD sind leider nicht kompatibel), drittens wegen fehlender Authoring-Software für privat übliche Zwecke. Ich habe zum Glück für mich mit unglaublich viel Ausprobieren 'ne "Krücke" gefunden, wie man UHD-Scheiben herstellt, die wie gewohnt mit Menü, Kapiteln usw. im Player laufen (aber nicht 100%ig UHD-BD-kompatibel sind, was heißt, daß sie möglicherweise nicht in jedem Gerät laufen).

Das nächste Thema ist die Geschwindigkeit:

Mein i9-9900K schafft ein HD-Filmchen bei H264 mit ~40fps mit Einstellungen, die für extrem gute Qualität bei mittleren VBR-Bitraten 10-15MBit/s (TV sendet auch nicht mit viel mehr!) optimiert sind, da ist die CPU noch nicht mal zu 100% ausgelastet. Bei UHD sind es noch so ~10fps. Nehme ich dafür H265 mit gar nicht mal so aggressiven Einstellungen, komme ich noch auf ~5fps. Schuld daran ist auch das 10 Bit-Encoding, aktuelle CPUs sind dafür nicht ausgelegt (alle Datentypen sind 8, 16, 32 und 64 Bit), es fehlen schlicht und einfach Befehle dazu bei SSE/AVX. BMI1 & 2 enthalten zwar passende Befehle (pdep, pext, pextr, ...) die funktionieren aber nur mit den allgemeinen Registern - nix mit Parallelverarbeitung. Die Pixelformatumwandlung in Einheiten, die die CPU beackern kann (und zurück) ist also ein Flaschenhals.

Angesichts dessen frage ich mich, wie lange es dauert, einen 2h-Film in 8K mit H266 zu kodieren und ob ich das Ende der Kodiersession mit heute aktueller Hardware überhaupt noch erlebe...


Quelle: HEVC-Nachfolger VVC/H.266 - Feature requests - Voukoder



Und dann noch das hier :


Ja, das wird mir jetzt auch klar... Habe mal selbst vor nicht allzu langer Zeit überlegt (AVISynth), um 'ne >8Bit-Unterstützung irgendwie in die verbreitete v2.58 reinzubekommen, also wie man die in RGB angeforderten Bilder vom Dekoder irgendwie in 4:2:0 10Bit kommt. Also 'ne DLL selber schreiben. Ich dachte, das geht mit SSE und AVX fix, so der Plan:

1. Mit "pmovsxbd" in 32Bit wandeln,

2. mit "cvtqd2ps" nach single wandeln,

3. Farben von RGB nach YV12-32Bit umfräsen (mulps/addps, die Umrechnungskonstanten für BT601/709/... stehen sogar in de Wikipedia),

4. Skalieren mit 1024 und in Integer zurückwandeln,

5. Ja, genau danach kommt das Problem: Jetzt muß man die wichtigen Bits zusammenschieben und es gibt zwar shifts für 8/16/32/64 Bit, aber trotz 256Bit Recheneinheiten nichts für das gesamte Register. Der Plan, die nicht benötigten Bits rauszushiften und das mit Bitmaske in ein Auffangregister zu schießen, geht leider nicht. Da hat Intel leider bei den mittlerweile 256 Bit breiten Recheneinheiten Befehle für die Bearbeitung von 128/256 Bit in einem ganze Stück vergessen. (Genau so, wie 'ne Integerdivision fehlt!)

Ich hab's dann entnervt gelassen. Konvertierung mit FFMPEG und eine 2 Kilometer lange Kommandozeile war nämlich erheblich schneller.


Ma zurück: Von YUVA float nach YUVA word kann man mit SSE/AVX aber schon ziemlich fix erledigen? Mit mulps skalieren, nach 32 Bit Int konvertieren und in 16 Bit umpacken. 3-4 Befehle??? (Und den Loop natürlich wenigstens 2fach entrollt!)

Quelle: Exception on Voukoder startup - Bug reports - Voukoder


Mir sagen diese Dateitypen überhaupt nichts.Es scheinen dort wohl Entwickler unterwegs zu sein.Denn was mit umschreiben und so,was die berichtet hatten.Scheint wohl halt doch nicht so einfach zu sein.Und ich der wo nur vielleicht etwas Programier Sprache C sich ein wenig auskennt,der hat da Null Chancen.
 
Hängt dann aber wie immer natürlich vom Compiler ab. Der GCC sollte es zumindest ab einer bestimmten Optimierungsstufe automatisch machen.
Automatisch, passiert Garnichts ;) Man muss das Zeug schon vernünftig programmieren.

@latiose88
Keine Ahnung womit du recodierst/umwandelst, aber AVX bringt auf Intel immer was und auf AMD spätestens seit Zen2 (3000er). Die angeblichen 2x 128bit AVX des Sandy/Ivy gegenüber 1x 256bit Haswell z.B., sind schwierig theoretisch zu beurteilen, da die erstgenannten eine leistungsfähigere "vector permute execution unit" haben. Da spielen etliche etliche Sachen dabei rein, was denn am Ende real bei rauskommt. Fortlaufend gibt es bei den Architekturen irgendwas mit Latenzen und Units wo man immer mehrmals drübersschauen könnte. Könnte, nur als Benutzer aber nicht müsste.

ExtremeTech hat damals sehr schön Ivy und Haswell verglichen und auch auf AVX ( x264 r2334) geschaut. Ohne AVX ist 4770k bei 1pass 13.5% schneller als 3770k, bei 2pass 7% schneller. Mit AVX, gewinnt 3770k 34%, 4770k 45%.
Ergo: AVX bringt immer was. Auf Intel schon immer, auf AMD garantiert seit Zen2. Es macht also viel mehr Sinn zu schauen, ob jemand die Soft brauchbar testet mit der man arbeite, auf einer angedachten CPU. Und mehr auch nicht ;)
Haswell review: Intel's Core i7-4770K takes over the pole position - Page 2 of 4 - ExtremeTech

edit:
Agner hat in der vector class library eine integer Division Routine implementiert und die ist schon ziemlich ziemlich flink. Man muss halt nur die Lib nutzen (oder die Sources analysieren...)
Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X
 
Ah OK, es geht also doch um avx. Mit hat einer mal gesagt gehabt das die IPC Leistungssteigerung unabhängig von avx wäre. Man könne wenig Instruktionen verwenden und da dann dennoch ne hohe ipc mehrleistung erwarten oder man kann viele verwenden und dabei dennoch sehr wenig zugewinn. Weiß nicht was mir die person dabei eigentlich mir damit sagen wollte. Am Ende fasste ich es so auf das für die IPC Steigerung somit avx unwichtig sei. Dann frage ich mich wofür dann das ganze wenn für die IPC Rechnung avx nicht entscheidend ist. Also sprich egal ob AMD oder Intel. Bestimmt sagt ihr dann das alles für ipc ne Rolle spielt. Ob direkt oder indirekt ist wohl ne andere frage.
 
Für Anwendungen wie zippen, Video encoden, Programmieren, Rendern etc. sicher.
Bei Spielen kommt es auf das Spiel an ... 4Kerne 8Threads gehen so gerade noch. die Vier Kern i5 mit nur vier threads haben mittlerweile heute oft echte Probleme gute Frametimes zu halten. Oder brechen allgemein auch mal bei den Average FPS weg. Death Stranding skaliert z.b. extrem von 4 bis 24 Kerne. Da merkt man das durchaus.

Death Stranding beeindruckt mich nicht von der Skalierung her. Bzw. habe ich vielleicht die falschen Benchmarks gesehen.
Bei CB kommen dreimal so viele Kerne nur auf 40% mehr Leistung, bei höherer Verlustleistung. Also bei selbem Verbrauch, sind es weniger als 40%. Das haut mich nicht um.

Außerdem laufen hier 4 Kerner mit HT/SMT, bei rund 140Fps mit minimum 90Fps. Da glaube ich nicht, das man ausgerechnet in so einem Spiel den Unterschied sieht.
 
Zuletzt bearbeitet:
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.

Der 10400F hat ein PL2 von 134 W, der 8700K von 118 W. Das dürfte den größten Einfluss haben. Im übrigen ist der 10400F gemäß Spiele-Index 2 Prozent langsamer und im, etwas empfindlicheren und bei gleicher Architektur gut für Rohleistungsvergleiche geeigneten, Anwendungs-Index sogar gut 4 Prozent. Das passt ziemlich exakt auf den knapp 5 Prozent niedrigeren All-Core-Turbo und ergibt demnach einen IPC-Zuwachs von 0 zwischen 8000er 6-Kern-Chip und 10000er 6-Kern-Chip. Allein die Unterschiede zwischen Mainboards können größer ausfallen und bislang haben wir keinen Weg gefunden, beide CPUs auf der gleichen Platine zu testen. ;-)
 
@PCGH_Torsten
Wunderbar :D

@latiose88
Diese Überlegungen die du aufstellst, die sind doch ein Weg zu irgendeinem Ziel oder? Was ist das für ein Ziel?
(ich hatte heute Albträume davon :( ;))
 
Ist bloß nicht der Fall. Die CPUs werden eher gerade so die 5 GHz schaffen, so wie es bisher anzunehmen ist.



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)






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

Woher kennst du den finalen Takt? Intel sagt das der Takt höher sein soll, als bisher. ein 9900KS hatte schon 5GHz, ein 10900k bis zu 5,3GHz. Höher sind dann nur Werte über 5,3GHz ;)
 
@PCGH_Torsten
Wunderbar :D

@latiose88
Diese Überlegungen die du aufstellst, die sind doch ein Weg zu irgendeinem Ziel oder? Was ist das für ein Ziel?
(ich hatte heute Albträume davon :( ;))

Echt gleich Albträume wegen sowas,sorry das tut mir leid.Das ist wirklich heftig.Ich sage dir aber gerne mein Ziel.

Nun ich habe unterschiedliche Intel und AMD CPUS getestet.Und aufgrund dessen mir ein Ryzen 3950x System zusammenbauen lassen durch meinem Bruder.Das System geht zwar noch nicht,aber dieses Hindernis werde auch ich schon noch sobald mal mein Bruder Zeit hat,auch noch gelöst werden.Wollte aufgrund des ganzen wissen und durch berechnungen wieviel dann der 4950x wirklich an Leistung sich steigert.Damit ich es genau abschtzen kann,ist das alles notwendig.Damit ich weis auf was ich achten muss.Denn je näher ich mit solchen CPU dem 3970x bin bzw komme,desto besser.Denn damit brauche ich dann nicht mehr so viel Geld auszugeben und der Stromverbrauch leidet ebenfalls nicht darunter.
Den 3950x auf 4,3 ghz zu übertakten konnte den abstand zum 3970x etwas verringern.Es sind nur noch 14 und im schlimmsten Fall 20 Sekunden Unterschied.
Der 4950x wird mit sicherheit den abstand weiter verringern.Wenn es blöd wird ,wird der IPC auch noch AVX mit einbezogen.Ohne dem dann weniger IPC verbesserungen und schwups ist dann der abstand zum 3950x weit geringer als ich mir erhoft hatte.Nur darum wollte ich alles so genau wissen.
Nun dank einer seite wo hobby Entwickler geschrieben hatten,wusste ich zwar dann welche Dateitypen verwendet werden.Allerdings weis ich halt nicht genau welche Rolle diese ganzen Dateitypen so spielen.Also es zu Wissen ist das eine,es zuzuordnen das andere.Ich weis also im Grunde immer noch nicht genau.Da wird mir halt am ende nur der Entwickler der Software Persönlich mir wohl noch helfen können.
Nun ich merkse schon,ich komme doch nicht weiter,egal wie genau ich das ganze weis.Habe wohl vergeblich gehofft,daraus was abzuleiten.Es ist doch weit aus Komplexer als ich gedacht hatte.Aber gut,dennoch danke für die ganze Hilfe von dir und anderen.
 
Woher kennst du den finalen Takt? Intel sagt das der Takt höher sein soll, als bisher. ein 9900KS hatte schon 5GHz, ein 10900k bis zu 5,3GHz. Höher sind dann nur Werte über 5,3GHz ;)

Weil durch den Backport das Taktpotential eingeschränkt ist und bisher die Frage war, ob überhaupt die 5 GHz geschafft werden.
 
Weil durch den Backport das Taktpotential eingeschränkt ist und bisher die Frage war, ob überhaupt die 5 GHz geschafft werden.

Der Backport dient eigentlich im Gegenteil dazu, das Taktpotenzial zu steigern. Allerdings sagt einem das im Vergleich zu sehr niedrigen Takt Intels bisheriger 10-nm-CPUs nicht, wie gut Rocket Lake im Vergleich zu Comet Lake abschneidet.
 
Für mich verwirrend.
Dachte Intel macht Backports, weil die 10nm Architektur, mit 14nm hergestellt werde muss... Das kann man ja bekanntlich nicht 1:1 hin und her schieben.

Daß Backports Taktpotenzial steigern wäre mir neu. Warum macht man das nicht schon ewig so? ;)
 
Zuletzt bearbeitet:
Architektur, Layout und Prozess ergeben zusammen das Taktpotential. Wenn du eines davon durch etwas ersetzt was mehr Takt kann bekommst du mehr Gesamttakt. Und das ist bei 10nm zu 14nm+(...)+ der Fall.
 
Für mich verwirrend.
Dachte Intel macht Backports, weil die 10nm Architektur, mit 14nm hergestellt werde muss... Das kann man ja bekanntlich nicht 1:1 hin und her schieben.

Daß Backports Taktpotenzial steigern wäre mir neu. Warum macht man das nicht schon ewig so? ;)

Normalerweise ist es so, dass neue Prozesse das Taktpotenzial steigern. Aber Intels bisherige 10-nm-Veröffentlichungen sind das klare Gegenteil dieser Regel. Die Yield-Raten sollen seit einiger Zeit gut sein und die niedrig taktenden Mobile-Chips sind auch problemlos lieferbar, die niedrig taktenden Skylake-SP-Server-Prozessoren scheinen sogar soweit vor den Erwartungen zu liegen, dass Cooper Lake auf ein paar OEM-Designs zusammengestrichen wurde. Aber deutlich über 4 GHz in 10 nm werden bislang ausschließlich von Tiger Lake berichtet (der parallel zu Rocket Lake entwickelt wurde und als erster 10 nm ++ nutzt); Ice Lake dagegen läuft außerhalb des Single-Core-Boosts eher im niedrigen 3er-Bereich und wird selbst im mobile-Markt von Comet Lake für die oberen Leistungsebenen ergänzt.
 
Ein Bild sagt mehr als tausend Worte:

intel nm.png
 
Zurück