Wer hat irgendetwas von Stromverbrauch gesagt? Jedenfalls gehört die Effizienz nicht zur Rohleistung, sondern beschreibt wieviel von der Rohleistung am Ende in effektive Leistung (Anwendungs-/Spiele-Leistung) umgesetzt wird.
Ich ging davon aus, du dachtest ich würde Effizienz den Stromverbrauch/die Energieeffizienz meinen -> wenn dem nicht so war, um so besser
Dennoch benötigt es einen Dritten Faktor in der Rechnung und wenn du dich noch so sehr dagegen stellst, es macht es nicht richtiger diesen wegzulassen. Auch bitte ich dich dir den genauen Themenbezug auf die Aussagen von oooverclocker (abermals) anzusehen. Ich habe nämlich keine Lust, Aussagen die in einem Bezug standen mit irgendwas zu erklären, was mit dem Ursprungsbezug nichts mehr am Hut haben.
Für dich zusammengefasst, es ging um die Behauptung: "Optimierung auf Rohleistung" und im späteren Verlauf auf die Frage, wie man das denn anstellen sollte "so viele wie möglich Einheiten auf so wenig wie möglich Fläche bei so hohem Takt wie möglich". So oder so ähnlich...
Es viel definitiv allerdings im Zusammenhang Rohleistung die Maßeinheit GFlop/sec. Schau bitte selbst oben nach, dass ich dir da keinen Mist erzähle!
-> wenn du dir nun die Formel zur Bildung der "Rohleistung" in GFlop/sec ansiehst wirst du sehr schnell merken, dass da exakt 3, in Worten DREI Faktoren vor dem Gleichheitszeichen stehen. Schimpf den dritten Faktor von mir aus wie du willst. Für mich ist das eine Art Einheiteneffizienzfaktor. Nämlich im Falle der aktuellen AMD Umsetzungen die 2, stellvertretend für ein "MADD". Es gab in der Vergangenheit, wie du vielleicht weist auch andere GPUs aus dem Hause AMD, wo dort eine 10 oder 8 stand. (VLIW5, VLIW4), bei NV stand dort sogar mal eine 3 (MADD + MUL) beim G80/G200.
Also erkläre mir bitte, wie du ohne einen dritten Faktor bei der Formel:
"ALU count" x "clockrate in
GHz" = "performance in
GFlop/sec kommen willst. Das geht schlicht und ergreifend nicht auf. FAKT!
Die Rechnung im konkreten Beispiel einer RX-480 lautet richtigerweise:
2304 x 1,266 x 2 = 5833,728 GFlop/sec
Der Spaß wird übrigens auch aus einem anderen Blickwinkel rund, nämlich unter dem, dass in den Faktor Rohleistung ebenso einfließen _kann_, wie schnell Einheit überhaupt ist. Wie du vielleicht ebenso weist, gibt es neben ALUs noch andere Einheiten auf der GPU. Und auch diese Besitzen eine Rohleistung. Das, was die ROPs durchschubsen oder das, was die TMUs durchschubsen kann von Generation zu Generation bspw. unterschiedlich sein. Auch hier benötigt es also einen Faktor, der das Ergebnis in die richtige Region lenkt.
Ein weiterer Umstand, der gegen eine ausschließlich "Takt x Anzahl" Rechnung spricht ist bspw. die Ermittlung der jeweiligen Rohleistung auf eine gewisse Prezision, denn es fehlt zusätzlich ein Faktor, der benennt, was überhaupt gleichzeitig geht.
Hawaii hat bekanntermaßen ein SP/DP Verhältnis von 2/1. GK110 hat 3/1.
Nur verwendet Hawaii 4x11x64=2818 ALUs bei SP und 4x11x64/2 = 2818/2 ALUs bei DP. Denn in DP rechnen jeweils zwei ALUs an einem FP64 Wert.
Beim GK110 ist das völlig anders. GK110 hat 5x3x192=2880 ALUs für FP32. UND dazu 5x1x192=960 ALUs für FP64!
Die Rechnung auf Rohleistung ist beim GK110 aber defakto NICHT! (2880+960) x 0,928 x 2 = 4661,76 GFlop/sec. Sondern man man trennt FP32 und FP64. Es arbeiten also NICHT alle Einheiten zur gleichen Zeit bzw. können dies wohl auch gar nicht. Schubst du FP64 durch, liegen die FP32er ALUs brach und andersrum. Eigentlich bedingt das sogar noch einem vierten Faktor -> nämlich dem, der angibt, was überhaupt alles gleichzeitig laufen _kann_... Auch der fehlt in deiner Rohleistungsformel!
Bitte tue mir den Gefallen und erkläre mir auf technisch sachlicher Ebene, wo und an welcher Stelle es richtig wäre, diesen dritten Faktor aus der Rechnung auszuklammern!? Und was das mit der Ursprungspauschalisierung, man würde auf Rohleistung optimieren zu tun hat!?
Anhand von bestimmten Design-Entscheidungen kann man abschätzen worauf die Entwickler besonders Wert gelegt haben. Wird auf Kosten optimiert, wählt man z.B. gerne kleine Einheiten und versucht diese hoch zu takten, denn je kleiner die Einheiten und je höher der Takt desto weniger Fläche braucht man um eine bestimmte Leistung zu erreichen.
Optimiert man auf Energieeffizienz versucht man die Auslastung zu maximieren und nimmt dafür auch größere Einheiten in Kauf (größere Buffer/Caches, aufwendigere Sprungvorhersage, ...). Tendenziell wählt man auch eher moderate Taktraten.
Eine Optimierung auf Rohleistung erkennt man an sehr vielen, aber relativ kleinen, Einheiten bei gleichzeitig möglichst hohen Taktraten. Dieses Schema erkennt man bis Kepler bzw. Fiji und teilweise Polaris. nVidia setzte dabei mehr auf Takt und AMD auf mehr Einheiten.
Das sind aber nur Indizien, keinesfalls Fakten... Die Behauptung, man (stellvertretend für AMD) optimiert auf Rohleistung und NV optimiert auf Takt ist und bleibt quatsch, vor allem da sich die Aussage insich widerspricht. Deswegen sagte ich eingans auch, dass Rohleistung eben nicht aus nur der Einheitenanzahl besteht. Denn wenn Rohleistung (laut deiner eigenen Aussage) aus Takt x Anzahl besteht, wie kann dann eine Ausrichtung auf Takt x Anzahl eine Rohleistungsoptimierung sein und eine Ausrichtung auf Takt eben nicht? Die Faktoren in der Formel sind gleichgewichtig. Eine Ausrichtung auf Takt _oder_ auf Anzahl _oder_ auf beides -> wäre IMMER eine Rohleistungsoptimierung. Denn bei jeder GPU wird man möglichst das optimale Verhältnis aus Takt und Anzahl anstreben. Unter gewissen Bedingungen, wie der Gesamtfläche, dem Energieverbrauch, der Kosten und vor allem im technisch möglichen Rahmen -> die GPU besteht halt nicht ausschließlich aus ALUs, mal eben da welche dran klatschen ist also nicht. Im Umkehrschluss bedeutet das aber auch, eine Optimierung durch Erhöhung des ALU Counts zieht gleichbedeutend eine Erhöung von Teilen anderer Einheiten nachsich. Damit skaliert man also nicht die Rohleistung der ALUs, sondern man skaliert die komplette GPU. So kann eben ein GP104 x Faktor 1,5 ein GP102 sein. Indem man stupide anstatt 4x vollwertigen GPCs einfach deren 6x verbaut. Man baut aber schlicht nicht 4x GPCs und erhöht dort einfach mal den ALU Count um 1,5 auf 3840 ohne den Rest zu skalieren. Weder bei NV noch bei AMD!
Wobei sich AMD dort in der Vergangenheit recht schwer getan hat, das korrekte Verhältnis aus CUs und Frontend zu finden. Im Moment sieht es so aus (bis einschließlich Polaris) dass 8-10 CUs pro Stück FrontEnd am besten skalieren und Modelle mit bis 16 CUs einfach nicht die Power auf die Straße bringen...
Schau dir dazu vllt einfach den Aufbau gängier Modelle an. AMD verwendet eine Skalierung (jeweils der Vollausbauten) von 8-16 CUs pro Teil am FrontEnd. Bei NV ist das starrer und weniger Flexibel. NV nutzt eine Anzahl von GPCs, je nach Generation (Kepler, Maxwell, Pascal) sind pro GPC eine Anzahl an Shaderblocken mit einem fixen Einheitencount vorhanden. Auch dort siehst du ein Verhältnis, was als Designentscheidung vorgegeben ist und eine Erhöhung ohne weiteres nicht möglich macht!
Muss man das verstehen? Deine Aussage ist weder eine allgemeingültige Erkenntnis noch eine reine Beobachtung und bedarf damit auf jeden Fall einer Begründung.
Die Aussage, dass eine Optimierung auf Rohleistung unwar ist bedarf doch keiner Begründung... Das ist eben der Vorteil in dieser Gesprächsposition, es ist äußerst einfach Aussagen zu widerlegen während die Belegung der Aussage in anderer Richtung schwer bis unmöglich ist. Ich sehe weiterhin keine Belege für eine Rohleistungsoptimierung, habe dir aber eine ganze Menge Aussagen gebraucht, warum das eben nicht der Fall ist.
Ganz einfach, die Shadereinheiten wurden deutlich verändert. Hätte man einfach leicht veränderte Einheiten von Polaris genommen, würde man bei der Fläche und dem kleineren SI problemlos auf >5000, evtl sogar auf >6000 Einheiten kommen. Für eine deutlich geänderte Architektur spricht auch, dass AMD der ISA eine neue Versionsnummer gegeben hat (nicht der Fall bei Polaris), die Notwendigkeit von umfangreichen Treiberanpassungen und die Gerüchte über deutlich höhere Taktraten. Warum sollte man also die Energieeffizienz der alten Architektur so einfach auf die neue übertragen können, denn nur dann würde deine Rechnung Sinn ergeben. Dass eine neue Architektur viele verändern kann hat man bei Kepler zu Maxwell gesehen.
Nunja, nenn es Intuition
Ich sprach ja auch nicht davon, dass es so ist. Sondern ich sprach, dass ich davon ausgehe, Polaris gibt die Reise vor... Schimpf es von mir aus auch Spekulation. Kann richtig sein oder kann auch falsch sein... Wir werden es sehen. Dennoch deckt sich meine Annahme dahingehend mit den Spekulationen, dass der große Vega im Moment mit bis 300W gehandelt wird. Die Rechnung Polaris x 2 im Verbrauch erzeugt das selbe Ergebnis, wie ich oben vorrechnete.
Mit Kepler/Maxwell hat das einfach wenig zu tun... Kepler krankt an anderer Baustelle bzw. Maxwell macht es bedeutend besser.
Ähm, Du hast da aber einen Denkfehler. Bei CPUs kann man auch FLOP/Zyklus berechnen, das heißt mit mehr IPC steigen die FLOPS logischerweise auch an. Mehr Befehle = mehr Operationen pro Sekunde. Du kannst aber eine 32 Bit FPU nicht 1,2 32 Bit- Zahlen gleichzeitig berechnen lassen - sie steckt aber im Produkt der FLOPS, somit sind FLOPS nicht unterschiedlich viel wert, sondern gleichwertig.
Du denkst wieder zu kurz... Schau dir bspw. die Prozessoren an, Sandy hat 3x ALUs, Haswell und jünger haben 4x ALUs. Die Rechnung auf die Rohleistung steigt... In dem Fall ist der Faktor zur Benennung (siehe oben die Erklärung, WARUM dieser Faktor da drin ist) der Einheitenleistung also gleich. Anders schaut das auf der FPU aus. 256Bit vs. 128Bit -> wie ermittelst du den Speed als reinen Rohwert, wenn es derartige Unterschied gibt? Auch siehe dazu oben die Aussage bzgl. Kepler FP32/FP64 vs. Hawaii FP32/FP64.
.
aber das ist eher unwahrscheinlich atm.