Paul Stanik
Veteran
- Mitglied seit
- Nov 29, 2018
- Beiträge
- 227
- Bewertungspunkte
- 33
- Punkte
- 27
News Ryzen 3000 erneut in Online-Shops gesichtet
- Themenstarter Paul Stanik
- Beginndatum
Was eine dumme Programierung. Wozu macht man 8 Kerne wenn davon fast alles immer noch auf 1 Läuft? Da lieber nur auf 4 Kerne laufen dafür gleichmäßig. Hmpf.
Gute Info, danke. Wird für mich Ende des Jahres wichtig wenn ich mir nen neuen CPU kaufe
Gute Info, danke. Wird für mich Ende des Jahres wichtig wenn ich mir nen neuen CPU kaufe
Affenzahn
Urgestein
Weil man nicht alles parallelisieren kann.
Manche Dinge aber schon, also hat man in einigen Szenarien eben vorteile von mehr Kernen, in anderen braucht man mehr Takt.
Bestes Beispiel wären CAD Programme. Der Viewport, also der "Baumodus" ist üblicher Weise Singlecore. Je mehr Geometrien, desto mehr CPU Last auf Kern0. Der Render dagegen lässt sich hervorragend aufteilen. Siehe Cinebench.
Manche Dinge aber schon, also hat man in einigen Szenarien eben vorteile von mehr Kernen, in anderen braucht man mehr Takt.
Bestes Beispiel wären CAD Programme. Der Viewport, also der "Baumodus" ist üblicher Weise Singlecore. Je mehr Geometrien, desto mehr CPU Last auf Kern0. Der Render dagegen lässt sich hervorragend aufteilen. Siehe Cinebench.
Was meinst du mit üblicherweise? "üblicherweise Singlecore" verstehe ich nicht so, dass Parallelisierung unmöglich ist. Sondern eher, dass es aufwändig wäre, es sauber auf mehrere Kerne aufzuteilen.
@arcDaniel und andere: Ein Kern voll ausgelastet und viele andere nur ein bisschen klingt doch eigentlich als ein gutes Beispiel für "Turbo Precision Boost 2" und "XFR 2".
Affenzahn
Urgestein
Damit meine ich dass es eine unüberschaubare Vielzahl an CAD Software gibt und ich die nicht alle nach Multicoreunterstützung untersucht hab.
Ich bin kein Programmierer, keine Ahnung wie das funktioniert. Aber im Internet wird einem ja gerne jedes Wort auf die Goldwaage gelegt, also relativier ich sowas immer.
Ich bin kein Programmierer, keine Ahnung wie das funktioniert. Aber im Internet wird einem ja gerne jedes Wort auf die Goldwaage gelegt, also relativier ich sowas immer.
arcDaniel
Urgestein
Ich denke zum einen ist es gar nicht möglich verschiedene Aufgaben auf mehrere Kerne auf zu teilen. Physikalisch stöst man aber auch langsam an die Grenzen was die Mehrleistungs pro Kern angeht, also bleibt nur die Möglichkeit in Richtung mehr Kerne.
Dass aber verschiedene Spiele wie vielleicht Anno einen Kern so stark beanspruchen, hat also vielleicht gar nichts mit schlechtem Willen oder Faulheit der Entwickler zu tun, sondern an der Art und Weise der zu erledigenden Aufgabe.
Dass aber verschiedene Spiele wie vielleicht Anno einen Kern so stark beanspruchen, hat also vielleicht gar nichts mit schlechtem Willen oder Faulheit der Entwickler zu tun, sondern an der Art und Weise der zu erledigenden Aufgabe.
HerrRossi
Urgestein
- Mitglied seit
- Jul 25, 2018
- Beiträge
- 6.782
- Bewertungspunkte
- 2.244
- Punkte
- 113
Wie funktionieren dann Supercomputer, wo Berechnungen auf viele verscheidene CPUs und sogar GPUs aufgeteilt werden? Ich vermute mal, das Problem liegt irgendwo zwischen Windows und den Game Engines.
Es kommt auf den Task an und daran, wie der Schnitt der Komponenten ist.
Wenn man skalieren kann, kann man es oftmals gut, sofern man die Resourcen hat.
Sequenzielle, kontextgebundene Abläufe hingegen profitieren weit weniger von Threads.
Dass der Windows Scheduler schlecht ist, ist seit EPYC ein offenes Geheimnis
Ich würde sagen: Weder noch. Das Problem liegt daran, dass es aufwändige und nicht ganz einfache Programmierarbeit ist, bestimmte Aufgaben zu parallelisieren.
Und das kostet Geld.
Wenn man einen Prozess in mehrere aufteilt, dann geht es darum, dass auf unterschiedlichen Kernen Teilprozesse laufen, die doch immer wieder von Ergebnissen von anderen Prozessen abhängig sind. Also müssen sich diese Teilprozesse gegenseitig informieren und miteinander kommunizieren. Das dann so hinzubekommen, dass der Verwaltungsaufwand der Kommunikation nicht den ganzen Vorteil der Parallelisierung wieder auffrisst, ist keine einfache Aufgabe. Wieviel mehr Kunden würde ein Spiel haben, das besser parallelisiert ist? Ich vermute - keinen. Und dafür mehr Geld aussgeben?
Eher auch nicht.
Die Entwickler sind heutzutage doch einfach nur froh, wenn ein Spiel überhaupt läuft. Von Optimierungen ist man doch bei den meisten Spielen erstmal weit entfernt.
Insofern ist der einfachste Ansatz auf mehreren Kernen zu laufen: Es gibt einen Hauptthread, der die Spiellogik beinhaltet, und alle zusätzlichen davon unabhängigen Dinge laufen auf anderen Kernen: Sound, Physik, Grafik, automatisierte immer wiederkehrende Weltereignisse, die "Ambiente" schaffen (Wachen, die die immer gleiche Runde drehen, sich unterhaltende Passanten, zufällig vorbeifliegende Vögel und so Zeug)
Wenn man ein Spiel so anfängt und weiterentwickelt, wird es einfach irgendwann sehr aufwändig, den Hauptthread zu parallelisieren, wenn dieser immer aufwändiger wird. Teilt man den von Anfang an auf, dann gibt es nicht so schnell Fortschritte in der Entwicklung, das ist eben aufwändiger.
Ich glaube auch, dass oft einfach das Risiko gegangen wird, dass dem Kunde die Hardware nicht reicht, als das Spiel zu optmieren. Zähneknirschend kauft der Kunde eher bessere Hardware, die auch für andere Spiele hilft, als mehr Geld für ein optimierteres Spiel zu bezahlen.
Und das kostet Geld.
Wenn man einen Prozess in mehrere aufteilt, dann geht es darum, dass auf unterschiedlichen Kernen Teilprozesse laufen, die doch immer wieder von Ergebnissen von anderen Prozessen abhängig sind. Also müssen sich diese Teilprozesse gegenseitig informieren und miteinander kommunizieren. Das dann so hinzubekommen, dass der Verwaltungsaufwand der Kommunikation nicht den ganzen Vorteil der Parallelisierung wieder auffrisst, ist keine einfache Aufgabe. Wieviel mehr Kunden würde ein Spiel haben, das besser parallelisiert ist? Ich vermute - keinen. Und dafür mehr Geld aussgeben?
Eher auch nicht.
Die Entwickler sind heutzutage doch einfach nur froh, wenn ein Spiel überhaupt läuft. Von Optimierungen ist man doch bei den meisten Spielen erstmal weit entfernt.
Insofern ist der einfachste Ansatz auf mehreren Kernen zu laufen: Es gibt einen Hauptthread, der die Spiellogik beinhaltet, und alle zusätzlichen davon unabhängigen Dinge laufen auf anderen Kernen: Sound, Physik, Grafik, automatisierte immer wiederkehrende Weltereignisse, die "Ambiente" schaffen (Wachen, die die immer gleiche Runde drehen, sich unterhaltende Passanten, zufällig vorbeifliegende Vögel und so Zeug)
Wenn man ein Spiel so anfängt und weiterentwickelt, wird es einfach irgendwann sehr aufwändig, den Hauptthread zu parallelisieren, wenn dieser immer aufwändiger wird. Teilt man den von Anfang an auf, dann gibt es nicht so schnell Fortschritte in der Entwicklung, das ist eben aufwändiger.
Ich glaube auch, dass oft einfach das Risiko gegangen wird, dass dem Kunde die Hardware nicht reicht, als das Spiel zu optmieren. Zähneknirschend kauft der Kunde eher bessere Hardware, die auch für andere Spiele hilft, als mehr Geld für ein optimierteres Spiel zu bezahlen.
Dark_Knight
Urgestein
- Mitglied seit
- Aug 20, 2018
- Beiträge
- 1.008
- Bewertungspunkte
- 380
- Punkte
- 84
Faulheit der Programmierer. Gerade an so etwas sieht man doch, das viele Aufgaben einfach stupide auf dem "ersten" Kern abgeladen werden. Wenn man es wirklich vernünftig angehen würde, könnte man sicher die Last die der Hauptkern tragen muss weiter aufteilen. Aber das würde sicher von Beginn an eine andere Herangehensweise bedeuten, die offensichtlich noch immer nicht gewünscht wird von den Publishern (in dem Fall Ubisoft), da dies ja mehr Zeitaufwand bedeuten würde und sich nicht vermarkten lässt.
Aber man sieht trotzdem, dass sich der Spielemarkt so langsam aber trotzdem in Richtung Mehrkernunterstützung bewegt und das schneller als es manche vorhergesehen haben. Von daher ist es auch absolut passend, wenn AMD von Beginn an gleich 12 und 16 Kerner auf den Markt bringt. Denn spätestens in den nächsten 2 Jahren werden auch Spiele erscheinen, die eben auch mit 12 und 16 Kernen gut skalieren. Und da wäre jeder der dann halt schon eine CPU dieses Kalibers besitzt gut gerüstet.
Aber man sieht trotzdem, dass sich der Spielemarkt so langsam aber trotzdem in Richtung Mehrkernunterstützung bewegt und das schneller als es manche vorhergesehen haben. Von daher ist es auch absolut passend, wenn AMD von Beginn an gleich 12 und 16 Kerner auf den Markt bringt. Denn spätestens in den nächsten 2 Jahren werden auch Spiele erscheinen, die eben auch mit 12 und 16 Kernen gut skalieren. Und da wäre jeder der dann halt schon eine CPU dieses Kalibers besitzt gut gerüstet.
Ein wenig Theorie zum Thema parallele Programierung.
Es gibt Dinge die man sehr einfach auslagern kann auf Kern 2. Beispiele sind hierfür vollkommen eigenständige Funktionen, die mit der Hauptfunktion so gut wie nicht interagieren. Beispiel hierfür wäre eine Uhr die einfach Läuft und von der sich die Hauptfunktion nur hin und wieder die Zeit holt. Aber solche Funktionen sind sehr sehr selten.
Als 2 gibts Dinge die will man überhaupt nicht auf 2 Kerne aufteilen, das es keinen Sinn macht. Ich Zitiere mal ein Beispiel meines Profs in der Uni dazu vor einiger Zeit " Stellen sie sich vor, sie hätten ein Programm das von 0 bis x zählt. Als Schleife wäre das dann x++. Als 2 Operation in der Schleife sei eine if Bedingung die bei einer Zahl, sei es 5, etwas auslöst. Wenn sie dieses Programm auf 2 Kernen laufen lassen, wird im 1 Takt x auf 2 gesetzte (jeweils +1 pro Kern). Danach wird mit If gefragt ob x=5. Da dies falsch ist, passiert nichts. im 3 Takt wird x=4, if ist immer noch falsch. im 5 Takt wird nun x=6. Ist x=5 ist immer noch falsch, wird somit aber auch nie wahr werden. " Dieses Beispiel zeit sehr gut was für Probleme auftreten können.
Daher wird mit Flags, Semaphores oder ähnlichen gearbeitet, und kritische Teile eins Programm zu blocken (nur 1 Funktion darf darin gleichzeitig arbeiten).
Um somit ein Programm auf X Kerne zu bringen, ist immer mehr Arbeit dieser Art nötig. Und da Kritische Bereiche nur von 1 Funktion (= 1 Tread) benutzt werden dürfen, führen diese dann zu starker Last auf Kern x. Dies kann man verhindern, in dem man weniger Kritische Bereiche erzeugt. Aber diese Optimierung ist viel arbeit, und teuer. Und jepp, das geben viele nicht aus. Somit ist aber, bis zu einem gewissen Punkt, jedes Programm auf mehrer Kerne optimierbar. Nur macht das, bei z.B. Cad wo fast alles erst starten kann wenn der Teil davor zu ende ist, wenig sinn.
Es gibt Dinge die man sehr einfach auslagern kann auf Kern 2. Beispiele sind hierfür vollkommen eigenständige Funktionen, die mit der Hauptfunktion so gut wie nicht interagieren. Beispiel hierfür wäre eine Uhr die einfach Läuft und von der sich die Hauptfunktion nur hin und wieder die Zeit holt. Aber solche Funktionen sind sehr sehr selten.
Als 2 gibts Dinge die will man überhaupt nicht auf 2 Kerne aufteilen, das es keinen Sinn macht. Ich Zitiere mal ein Beispiel meines Profs in der Uni dazu vor einiger Zeit " Stellen sie sich vor, sie hätten ein Programm das von 0 bis x zählt. Als Schleife wäre das dann x++. Als 2 Operation in der Schleife sei eine if Bedingung die bei einer Zahl, sei es 5, etwas auslöst. Wenn sie dieses Programm auf 2 Kernen laufen lassen, wird im 1 Takt x auf 2 gesetzte (jeweils +1 pro Kern). Danach wird mit If gefragt ob x=5. Da dies falsch ist, passiert nichts. im 3 Takt wird x=4, if ist immer noch falsch. im 5 Takt wird nun x=6. Ist x=5 ist immer noch falsch, wird somit aber auch nie wahr werden. " Dieses Beispiel zeit sehr gut was für Probleme auftreten können.
Daher wird mit Flags, Semaphores oder ähnlichen gearbeitet, und kritische Teile eins Programm zu blocken (nur 1 Funktion darf darin gleichzeitig arbeiten).
Um somit ein Programm auf X Kerne zu bringen, ist immer mehr Arbeit dieser Art nötig. Und da Kritische Bereiche nur von 1 Funktion (= 1 Tread) benutzt werden dürfen, führen diese dann zu starker Last auf Kern x. Dies kann man verhindern, in dem man weniger Kritische Bereiche erzeugt. Aber diese Optimierung ist viel arbeit, und teuer. Und jepp, das geben viele nicht aus. Somit ist aber, bis zu einem gewissen Punkt, jedes Programm auf mehrer Kerne optimierbar. Nur macht das, bei z.B. Cad wo fast alles erst starten kann wenn der Teil davor zu ende ist, wenig sinn.
HerrRossi
Urgestein
- Mitglied seit
- Jul 25, 2018
- Beiträge
- 6.782
- Bewertungspunkte
- 2.244
- Punkte
- 113
Ja, das wird der Grund sein. Es lohnt sich nicht, weil die Spiele trotzdem gekauft werden und man zur Not Hardware drauf wirft, wenn es nicht anständig läuft. Wie es richtig geht, sieht man an den Konsolenspielen, was da aus der doch eher lahmen APU rausgeholt wird, ist schon beachtlich.
Dort haben die Entwickler aber auch das Wissen, wie das Environment aus sieht. Naemlich bei allen gleic, oder maximal 2 Environments (normal und Pro/X Konsole). Damit kann man halt genau darauf optimieren und muss nicht fuer verschiedene Leistungsklassen noch mit verschiedenen Settinglevels arbeiten.
Parallelisierung ist wirklich ein weites Feld. Am wichtigsten wird bei Spielen sein, ob die API, der die Daten am, Ende uebergeben werden, parallel aufgerufen werden kann und diese dann (z.B.) das Bild daraus im Zeitlimit zusammensetzen kann oder ob dabei die Daten alle aus einem Thread kommen muessen.
Oder kann das benutzte Modell fuer das Spiel (Raeume, Figuren, ...) sinnvoll parallel von verschiedenen Threads berechnet werden, damit Aufteilung und Zusammenfuehrung der Daten am Ende nicht die gleiche oder mehr Zeit benoetigen.
Und natuerlich noch, bleibt das Spiel dann bei den Mindestanforderungen, wenn z.B. nur ein DualCore genutzt wird, spielbar. Oder muesste der Entwickler verschiedene Implementierungen, abhaenig von der Anzahl der Cores bauen, was am Ende Fehleranfaelligkeit und Testaufwand erhoeht.
Bei wissenschaftlichen Sachen gibt es halt teilweise nicht ein Zeitlimit (z.B. 16ms pro Frame), um das Ergebniss zu erzeugen (stark vereinfacht). Da kann halt ein Rechner 1 Ergebnis pro Tag berechnen und 24 Rechner damit 24 Ergebnisse. Oder 24 Rechner erstellen ein Ergebnis nach ner Stunde und kommen am Ende auch auf 24 Ergebnisse am Tag.
Ich gehe einfach immer davon aus, dass die Entwickler entsprechend ihren Frameworks, Wissen und Vorgaben (techn. und finanziell) die beste Loesung abliefern. Als Kunde kann ich dann an der Kasse entscheiden, ob mir das gelieferte Ergebnis passt.
arcDaniel
Urgestein
Die Konsolen darf man gar nicht mit ran nehmen. Die habe halt den Vorteil, dass auf Low-Level optimiert wird und dann 90% der Spiele sich mit 30fps zufrieden geben.
Auch auf den Konsolen, brechen sogar diese 30fps gnadenlos ein, wenn es etwas CPU-Intensiver geht.
Also kann man gar nicht fragen: Warum geht es auf den Konsolen und auf dem PC nicht?
Auf den Konsolen würde es in den PC-Einstellungen auch nicht gehen. Die Jaguar CPU bekommt es nur halbwegs so gestemmt, weil die Settings so gerng sind.
Auch glaube ich mittlerweile nicht, dass Low-Level so viel ändert. Ich schätze mal ganz grob, dass mit gleichen Settings (und fps) auf dem PC vielleicht 10% Mehrleistung benötigt werden.
Was bei den Konsolen der grösste Vorteil ist, ist die meist grössere Distanz zum Fernseher und der Input-Lag, welcher eine Menge kaschiert.
Auch auf den Konsolen, brechen sogar diese 30fps gnadenlos ein, wenn es etwas CPU-Intensiver geht.
Also kann man gar nicht fragen: Warum geht es auf den Konsolen und auf dem PC nicht?
Auf den Konsolen würde es in den PC-Einstellungen auch nicht gehen. Die Jaguar CPU bekommt es nur halbwegs so gestemmt, weil die Settings so gerng sind.
Auch glaube ich mittlerweile nicht, dass Low-Level so viel ändert. Ich schätze mal ganz grob, dass mit gleichen Settings (und fps) auf dem PC vielleicht 10% Mehrleistung benötigt werden.
Was bei den Konsolen der grösste Vorteil ist, ist die meist grössere Distanz zum Fernseher und der Input-Lag, welcher eine Menge kaschiert.