Angeblich soll ja der Aufwand nur unwesentlich sein. Selbst das Portieren von 11 auf 12 soll ja nach Meldungen angeblich nur gering ausfallen.
Die Frage ist halt, welche Vorarbeit ist da notwendig.
Multithreading hat an der Stelle halt den entscheidenden Nachteil, das man als Programmierer die Laufzeiten der Threads beachten muss. Es bringt nix, allein dutzende Threads mit Last zu belegen, wenn diese ungünstig verteilt ihre Arbeit verrichten. Da können schon simple Startzeitverschiebungen schon ne ganze Menge Performance bringen - oder auch kosten.
Mit DX12 scheint man aber analog zu Mantle sich der "draw call" Performance anzunehmen. Wo es heute mit DX11 zu Limits kommen kann...
Am Ende lässt sich da so oder so schwer von Außen drüber diskutieren. Multithreading ungleich Multithreading. Das aufbereiten des Codes so, das ein Workload durch mehr Threads schneller läuft ist die eine Herrausforderung. Das ich nenn es mal Zusammenfassen mehrerer Workloads um mehr Threads gleichzeitig zu belasten und somit unterm Strich weniger Zeit zu benötigen ist die andere Geschichte.
Bildlich ist das wie, wenn man sich ein Auto in die Garage stellt. Damit können fünf Personen bewegt werden. Mit nem zweiten Auto kommt man aber auch nicht schneller an sein Ziel. Aber man kann eben 10 Personen in der gleichen Zeit befördern. Was unterm Strich auch doppelten Speed bedeutet. Nur eben daran gebunden ist, das man auch 10 Personen befördern will. Will man nur fünf befördern, weil mehr nicht notwendig sind, nutzt das zweite Auto am Ende absolut gar nix.
Analog dieser bildlichen Darstellung verhällt sich MT.
Schaut man mal etwas in die Vergangenheit, so gibt es seit irgendwo 2005 CPUs mit vier Threads im Customer Markt. Das sind nunmehr knapp 10 Jahre. Und was ist?
Für den Alltag reicht ein kleiner Dualcore selbst ohne SMT im Grunde vollkommen aus. Nur selten liegt wirklich permanente Last größer zwei Threads an.
10 Jahre sind ne ganze Menge Holz in der PC Geschichte...
Und das, was heute die Threads belasten kann, das gab es damals schon. Maschinen, die statischen Kontent möglichst schnell berechnen waren auch damals (und sogar vor 2005) schon Multi CPU tauglich. Wenn auch eher selten im Customermarkt anzutreffen. Aber sei es drum. Dual/Multi CPU Maschinen gibts seit ewig und drei Tagen. Die Software hingegen kann und will da nicht so 100% ran. Die Frage ist, warum? -> nach all den Jahren liegt also die Vermutung nahe, das es doch irgendwelche Limits gibt, die selbst mit Aufwand nicht zu stemmen sind. Wie gesagt, A + B und das Ergebnis geteilt durch C wird auch in 100 Jahren noch zwei Schritte notwendig machen. Das ganze Mathematisch in einem einzigen Ritt zu bewältigen ist einfach unmöglich. Egal wie man es dreht. Derartige Konstellationen sind bei dynamischem Kontent halt immer vorhanden. Was eben auch eine Skalierungsbremse darstellt.
Nicht zwingend. Die GPU Hersteller haben sich aktuell auf die Fahne geschrieben, die Skalierung über vorhandene Ressourcen zu verbessern. Was bei NV und auch AMD mehr oder weniger gut fruchtet.
Ähnliches machen halt die Programmierer von Games. Kontent hinzupacken, der quasi on top kommt, neben der eigentlichen Spielebasis ist immer möglich. Das kostet den Anwender Ressourcen, die er haben muss. Sonst bricht die FPS Rate zusammen.
Ob man allerdings heute über 1000€ für so nen Oktacore ausgeben muss, ist aus meiner Sicht fraglich. Mit nem anständigen Quadcore, ggf. Quadcore + SMT oder alternativ AMD Gegenstück mit 4-8 Threads ist man stand heute auf absehbare Zeit erstmal gut bedient. Der Mehrwert, den die Hexacores oder Oktacores durch 50-100% mehr Roh-Ressourcen erzeugen, liegt bei Spielen im Schnitt allerdings im unteren Prozentbereich.
Es ist und bleibt aber auch immer eine Frage des Anwenderverhaltens. Wenn du im Hintergrund noch diverse Tasks laufen hast, die Last erzeugen, kommst du mit ner breiteren CPU tendenziell besser weg als mit ner schmaleren. Ob dich das ganze allerdings den Aufpreis wert ist, musst allein du entscheiden
Zuletzt bearbeitet:
)
