Es gibt ja nicht nur den Boxedkühler, sondern auch CPU Blöcke für Wasserkühlungen, AiO, diverse Luftkühler, bei denen man immer davon ausgegangen ist, dass die Wärme in der Mitte erzeugt wird. Bisher machte es z.B. kaum einen Unterschied, ob man die Heatpipes horizontal oder vertikal über die CPU geführt hat, jetzt schon. Das ganze kann die Situation natürlich verbessern, da, wenn man es richtig macht, alle Heatpies mit Wärme versorgt werden, wenn man es falsch macht, dann sind einige quasi nutzlos.
Das schreit nach einem PCGH Spezial.
Es gibt keine vergleichbaren Sensoren in den einzelnen Chips, mit denen man diese Temperaturunterschiede zuverlässig ermitteln könnte. Umgekehrt haben wir mit Coffee Lake und Haswell schon mehrfach extrem langgestreckte Dies in Mainstream-CPUs gehabt, ohne dass es zu einer nenneswert ungleichmäßigen Wärmeverteilung am Heatspreader gekommen wäre. Letzterer trägt seinen Namen einfach zu recht und gleicht Unterschiede aus.
@PCGH_Torsten
Habt ihr die Möglichkeit ein 2080 Ti oder Titan RTX SLI mit dem 9900k und 3900X in 4k zu testen? Vorzugsweise Rise of the Tomb Raider wegen der 99% SLI Skalierung und auf Mittel, Hoch und Ultra?
Da müsstest du mal viel Druck auf Raff ausüben. SLI genießt mittlerweile unterste Priorität und er hat noch keinen Grafikkartenhersteller überredet, uns eine NV-Link-Bridge zu schicken.
Meine Mainboard-Kontakte können so etwas leider auch nicht bereit stellen.
Ja, ist durchaus möglich. Meine letzte CPU, ein 2500K, hatte während seines 5,5 jährigen Einsatzes eine HD5870, GTX 680, GTX 970 und eine GTX 980Ti an seiner Seite. Warum? Weil er genug Power hatte!
Müssen wir jetzt über Grundlagen diskutieren? Scheinbar hast du keine Ahnung und stellst aber gleichzeitig die Testmethoden der Fachredakteure in Zweifel. Marc Sauter bei golem hat die CPUs auch in 720p getestet. Weil er ein Idiot ist? Nein, er weiß, dass Anzahl der zu berechnenden Pixel einzig und allein der Grafikkarte zur Last fallen. Die CPU hat keinen Anteil daran.
Sauti hat bei uns gelernt
Also kaufst du dir immer Reifen die bis 350kmh geeignet sind auch wenn dein Auto nur 180 schafft? Oder kaufst du nicht eher die Reifen die zu deinem Auto passen? Genau andersherum wird auch ein Schuh draus, hast einen Lamborghini Aventador und kaufst dir Reifen die für 180 zugelassen sind? Irgendwie ist das im täglichen Leben Bullshit und hier soll es normal sein?
Gegenfrage: Sollen wir den Aventador mit S-Reifen im innerstädtischen Berufsverkehr testen, weil so eine praxisnahe Fahrsituation aussieht? Bedenke bei der Antwort auch, dass in CPU-Zulassungspapieren keine Höchstgeschwindigkeit steht, man also vor dem Test selbst festlegen muss, welcher Bereich sinnvoll ist.
Bei Spielen wirst du immer mehr Abhängigkeiten zwischen einzelnen Threads haben, als bei manchen Anwendungen. Daher sind die Rechenaufgaben bei Spielen nur begrenzt parallelisierbar und verursachen zusätzlich eine sehr unterschiedliche Last, die auch noch situationsabhängig ist. Die Aufgabenverteilung wird dadurch grundsätzlich immer aufwändig sein und ab einem gewissen Punkt nicht sinnvoll sein. Du kannst an einem Klavier natürlich jede Taste einem Spieler zuweisen. Das wäre aber nur dann gut, wenn diese unabhängig voneinander "spielen" könnten. Wenn diese aber voneinander abhängig Spielen müssten, hätte ein Dirigent soviel zu tun, dass er alle Spieler gar nicht zu 100% auslasten könnte. Auch werden manche Tasten so selten genutzt, dass es gar nicht notwendig wäre, dafür extra einen Spieler bereitzustellen.
Mir ist bewusst, der Vergleich trifft es nicht ganz, zeigt aber dennoch das Problem ganz anschaulich auf.
Wenn die/der Klavierspieler versuchen, in kürzester Zeit alle Noten des Stücks zu spielen, dann passt der Vergleich. Mit nur einem Spieler, der maximal 10 faches Multithreading beherrscht, dauert das eine ganze Zeit lang. Wenn auf jede Taste ein extra Spieler einhämmert, hat man die Partitur ganz schnell bewältigt!
Das gleiche Problem hast du bei Anwendungen aber im Grundsatz auch. Zum Schluss muss ein Ergebnis herauskommen. Es gibt ja nicht um sonst den Spruch, viele Hände, schnelles Ende und das trifft auch auf CPUs im Grundsatz zu, wenn man Aufgaben verteilt, nur müssen dann die Engines entsprechend angepasst werden und an der Stelle hinkt es gewaltig, weil es halt für Entwickler einfacher ist Performance über die reine Geschwindigkeit zu skalieren und die Notwändigkeit nicht besteht da etwas anzupassen, da diese Geschwindigkeit aktuell noch ausreichend ist aber auch das ändert sich und bei den Ghz ist nun einmal irgendwann Schluss und dann geht es nur noch mit Parallelisierung. Dieses Irgendwann ist auch gar nicht mehr so lannge hin, siehe aktuelle Spiele wie von Torsten genannt.
Ich meine nur, dass die Zukunftsfähigkeit von CPUs und das ist bei 300 €+ schon interessant, sich nicht ausschließlich auf schlecht optimierten 720p Engine-Ergebnissen ableiten sollte, siehe mein Vorschlag weiter oben. Grundsätzlich haben die Tests ja noch ihre Daseinsberechtigung.
MfG
Nein, dieses Problem trifft nicht auf Anwendungen zu. Diese müssen eben erst zum Schluss zu einem Ergebniss kommen. Spiele dagegen müssen zwischendurch regelmäßig vollständige Zwischenergebenisse abliefern und das steigert den Synchronisierungsaufwand ins unermessliche. Ehe Cinebench respektive Cinema ein Bild rendert, designt ein Modellierer in stunden- bis wochenlanger Handarbeit dessen Inhalt. Wenn du mehrere Designer hinsetzt, geht der Prozess geringfügig schneller vonstatten, aber die Skalierbarkeit ist begrenzt. Zerlegst du beispielsweise das Modell eines Autos in vier Komponenten, können vier Designer parallel arbeiten und am Ende entsteht etwas zusätzliche Zeit für das Zusammenfügen. Zerlegst du es aber in 400, sind deine 400 Designer nur noch damit beschäftigt untereinander abzusprechen wo eigentlich die genauen Kontaktpunkte aussehen. Unterm Strich kannst du durch Parallelismus vielleicht 60 Motive pro Monat in die Cinema-Pipeline schleusen – und das Auto-Beispiel ist schon ein sehr einfaches, denn hier berührt jedes Teil nur seine unmittelbaren Nachbarn. Möchtest du dagegen einen Steinschlag in einem Spiel simulieren, könnte jeder Felsen jeden anderen in seiner Bahn beeinflussen und das für jeden Millimeter jeder ihrer Bewegungen geprüft werden. Aber nicht parallel, sondern nacheinander – denn erst nach Berechnung des ersten Meters weiß man, welche Berührungen auf den nächsten möglich sind. So gesehen sind 60 Frames pro Sekunde schon eine enorme Herausforderung für Spieleengines, denn jeder einzelne davon kann hunderte Synchronisierungsvorgänge erfordern.