Das deckt sich mit dem was ich in #46 aufgrund der berichteten Zahlen formuliert hatte.
Ist halt nur ne Schlussfolgerung
Ob die Last jetzt vom Cache limitiert wird oder nicht, das siehst du nicht von extern
Never ever...
Hier kann man bestenfalls im Quertest mit IF OC auf nem Ryzen ab Zen2 mal testen ob es schneller wird wenn man die IF anzieht oder nicht. Wenn ja, bringt sehr wahrscheinlich Cache vom X3D auch was. Wenn nicht, dann eher nicht.
Es gibt übrigens Tools, wo man sowas viel besser troubleshooten kann als mit nem Taskmanager, Process Explorer oder via HWInfo... Das Ding ist nicht Single Threaded, das nutzt ne ganze Menge Threads. In meinem Fall deutlich über 100 Stück.
Aber die Masse der Zeit geht in meinem Fall (
20,5s bei einem 5950X mit 5150MHz max. Boost) dafür drauf, die Objekte zu Zeichnen. Was offenbar ein Loop ist einer sich selbst aufrufenden Funktion.
Er nutzt btw. auch im späteren Verlauf (das ist der Ausreißer nach oben) mehr als einen Core/Thread parallel. Nur halt nicht sehr lange.
Nach der Ruhepause von paar wenigen Sekunden macht er dann nochmal was - das Fenster reagiert kurz und man kann kurz drin rum klicken, bis es wieder für ne ganze Zeit einfriert.
Das Problem ist hier gar nicht so sehr Multithreading bzw. scheinbar das aufheben der Gruppe, sondern dass die Zeit offenbar für das Zeichnen der Objekte drauf geht und das im GUI Thread, der nicht sonderlich parallel gehalten ist für die Powerpoint GUI. Deswegen hängt die GUI auch die ganze Zeit über. Kann man schön im Trace sehen, wie er dann immer wieder in die oart.dll rein greift, was wenn ich das richtig sehe, was mit den Objekten die da gemalt werden, zu tun hat.
Hier kommt halt leider PowerPoint an sein Ende. Wie auch gern kritisiert wird, dass bei riesigen Dokumenten mit hunderten bis tausenden Objekten das nicht mehr nutzbar ist...
Auf nem Ryzen schubst der Task Scheduler auch die Last nicht so wild hin und her wie scheinbar bei Intel. Dem Lastdiagramm zur Folge steht das teils länger oben auf Anschlag, für x-Sekunden. Bei mir switcht ein Großteil der Arbeit zwischen Thread 5 und 15.
Fragt sich immer noch, warum z.B. der i5-8250U drei bis viermal so schnell ist wie der i7-8550U 🤔
Das kann man auch mit dem Tools wie dem WPA troubleshooten. Bspw. ob der langsamere Prozessor aus Gründen die Cores Parken schickt oder so. Einfach irgendwas via Task Manager und Co. sehen zu wollen ist wie Blindflug im Nebel. Da siehste nicht viel...
Btw. in deiner Kurve da mit dem festpinnen auf einen Thread sieht man, dass bei dir zwischendurch immer mal wieder nicht volle Last anliegt. Das franzt oben relativ stark aus. Wäre das 1T Anschlag, wäre das ein gerader Strich oben. Das wird also limtiert von irgendwas. Was zumindest auch logisch den Schluss zulässt, warum da teils drastisch schwankende Ergebnisse kommen.
CPU Mitigations könnten hier auch einen Starken Einfluss haben. Gerade bei Intels alten CPUs.
Beim 13600K sind es als 6+8 CPU 12 Threads auf P-Kernen und nur 8 auf e-Kernen würde er dann nur 40% der Zeit auf einem e-Kern laufen.
Wie kommst du auf solche Zahlen?
Das hast nichts mit Zeit zu tun, wie lange ein Thread auf einem P oder E Core läuft... Nur weil es mehr oder weniger P- oder E-Cores gibt, läuft das nicht länger oder kürzer da drauf... Ich empfehle weniger Theorie, mehr praktisches selbst Testen.