Hmm.. Aber irgendwie schon komisch. Nach dem Diagramm ist jetzt die Leistung mit einem Core am höchsten
Mit 5 Core am niedrigsten und auch
mit 8 Core deutlich unter einem???
Nein, darum gehts nicht. Es geht darum, dass die Leistung beim ersten Core im Vergleich zu Haswell eigentlich viel zu hoch ist. Und mit jedem weiteren zugeschaltetem Core/Thread Haswell aufholt. -> oder Skylake einbüßt. Worauf hin man eine Vermutung aufstellt, inder irgendwie in Skylake Ressourcen anderer physischer Cores möglicherweise mitgenutzt werden, was die deutlich höhere Leistung bei einem oder auch zwei Cores erklärt. -> logisch ist, dass Haswell bei 1-4 Cores nach oben skaliert. Etwas komisch erscheint, dass Skylake dies genau nicht macht -> allerdings ist das vielleicht auch eine Scheduler Konsequenz oder ähnliches.
Das ist alles andere als komisch. Dieser Benchmark ist ja absichtlich nur singlethreaded ausgelegt.
Erzwingt man nun das der Bench auf einem Kern läuft, versucht windoof nicht ihn zu verteilen -> maximale Geschwindigkeit.
Lässt man windoof aber verwalten (das kostet zeit/Leistung) so wird der singlethread Bench verteilt und somit ausgebremst.
Darum gehts aber gar nicht... Auch wenn du potentiell recht hast mit der Aussage. In dem Fall gehts aber gerade um das Verteilen, was der Prozessor ggf. intern für sich übernimmt und wo er somit Ressourcen anderer physischer Cores ranzieht um mehr Leistung zu erzielen.
Logisch ist, dass bei Last auf nur einem Thread und unter herranziehen von Ressourcen der anderen drei Cores das "schnellste" Ergebnis erwartbar ist.
Eine Erklärung für den niedrigeren Wert bei Core 2-4 wäre bspw., dass die interne MT Umsetzung des Benchtools für diesen Test schlechter funktioniert als diese spekulierte Ressourcennutzung anderer physischer Cores des Prozessors!
Jetzt gehen wir allerdings wieder etwas zu weit!
Was sich nicht wirklich aufsplitten lässt sind natürlich Dinge die direkt aufeinander basieren. Also willst du C berechnen und es gilt C = A + B, dann musst du A, B und C auch in dieser Reihenfolge auf einem Thread berechnen.
In der Praxis sind das aber nur kleine Teile von Programmen - nichts was für spürbare Verzögerung sorgt.
Du denkst zu kurz... Nicht die einzelne Berechnung ist das Problem, sondern das Problem ist, dass einige/mehrere dieser Berechnungen in gewissen Sinnabschnitten zueinander stehen... Und du entsprechend diese Sinnabschnitte in einem Thread zusammen fassen wirst -> oder pro Sinnabschnitt dann wieder einen Thread baust, welcher die Arbeit auf mehrere Unterthreads aufsplittet.
Am Ende bleibt aber trotzdem der Sinnabschnitt vorhanden und dieser Sinnabschnitt lässt sich idR oftmals bei dynamischem Kontent NICHT! beliebig zerhackstückeln... Games sind Programme mit viel dynamischem Kontent. Sachen wie das Rendern einer fixen Szene hingegen ist klar statischer Kontent. Letzteres kannst du nahezu beliebig zerhackstückeln um somit die Leistung zu steigern. Bei Games hingegen basiert alles auf wenigen Basisdaten gepaart mit einigen dynamischen Werten, die dort einfließen. Die Zeitlänge der Berechnung kommt einfach dadurch zustande, dass diese wenigen Werte sehr oft berechnet werden. Nämlich mit jedem Rundendurchlauf. Das Spielbackend ist dabei noch losgelöst vom Grafikbackend. -> letzteres läuft auf die FPS raus. Ersteres hingegen läuft davon völlig losgelöst -> sonst hättest du da bei mehr Leistung und mehr FPS auch ein schnellers Spiel (was früher mal so war!)
