Warum sinkt die relative Realleistung mit steigendem Takt?

[Leonidas]

Warum sinkt die relative Realleistung mit steigendem Takt? Oder auch: Wieso nimmt die Skalierung letztlich immer ab, ganz besonders wenn eine CPU nan ihrem Ende angekommen ist.

Ich brauch das für einen Artikel bei HT4U und hatte auf diese Frage auf Anhieb eigentlich auch keine wirklich überzeugende Antwort.

[pippo]

Eigentlich hab ich da auch keine Ahnung, aber ich könnte mir vorstellen, dass dadurch, dass der Speicher ja gleich getaktet bleibt, die CPU bei höherem Takt länger auf Daten aus dem Arbeitsspeicher warten muss und dieser nochdazu nichtmehr mit der nötigen Bandbreite aufwarten kann.

Jedoch alles nur Vermutung ;)

[Endorphine]

Original geschrieben von Leonidas
Warum sinkt die relative Realleistung mit steigendem Takt? Wirklich linear skalieren kann ein Prozessor nur dann, wenn die I/O-Leistung (Durchsatz und Latenz) immer mitskaliert und die restlichen Komponenten jede CPU-Leistungssteigerung in gleichem Maße mitmachen (allein schon durch die Präsenz von Festplatten und Kupferkabelnetzwerken unmöglich). Die letzte x86-CPU ohne intern höhere Taktfrequenz war der Pentium-66 (P5). Wenn der interne Takt steigt und die Schnittstelle zu den anderen Komponenten nicht mithält kann die Skalierung niemals linear sein, nur bis zu einem bestimmten Niveau annähernd linear. Früher oder später wird die I/O-Leistung zum Flaschenhals. Original geschrieben von Leonidas
Wieso nimmt die Skalierung letztlich immer ab, ganz besonders wenn eine CPU nan ihrem Ende angekommen ist. Weil die "Umgebung" die Leistungssteigerungsrate der Prozessorentwicklung nicht mitmacht und die CPU dann mit höherem Takt öfter oder länger auf die zuarbeitenden Komponenten wartet.

Die CPU-Konstrukteure müssen sich dann neue Ideen einfallen lassen, um die Flaschenhälse der Umgebung irgendwie zu umgehen oder um sie besser auszunutzen. Gleichzeitig werden natürlich auch die I/O-Controller (ISA -> PCI -> PCI-Express; Ethernet -> Fast Ethernet -> Gigabit Ethernet etc.) weiterentwickelt. Die Coprozessoren natürlich auch (z. B. VGA -> 2D-Beschleunigung -> +Videobeschleunigung -> +3D-Beschleunigung).

[Haarmann]

Einfachste Überlegung hilft hier viel

Nehmen wir geistig nen P4 mit 100 FSB und PC3200. Einer mit 16x Multiplikator und einen mit 24x Multiplikator. Lassen wir mal ne Hitrate von 90% bei der Anwendung gelten.
Die Verlusttakte bei nem Miss sind also beim 24x schlicht 50% höher, denn beim 16x, weil das RAM in beiden Fällen gleich schnell liefert. Dementsprechend skaliert die CPU nicht linear mit ihrer Geschwindigkeit. Je schlechter die Hitrate in einer Anwendung, desto weniger bringt ein höherer Multiplikator. Dementsprechend gibts immer Anwendungen, die besser und schlechter skalieren.

[Birdman]

Imho müsste man hier ganz klar abtrennen, zwischen CPU- und Systemleistung. Während erstere mit dem Takt zu 100% linear mitsteigt tut dies letztere beileibe nicht.

[CrazyIvan]

@ Birdman

Kann man so ohne weiteres auch nicht stehen lassen...

Auch die interne I/O Anbindung skaliert nicht wirklich linear mit.
AFAIK hat man doch beim Prescott auch das halbe Cache - Management umgebaut, damit dieser wieder besser mit dem Takt mitskalieren kann.
Wäre vielleicht auch ne ganz gute Aussage zu Deiner zweiten Antwort, Leo. ^^

c't 04/04 hatte da nen netten Architektur-Artikel über den Prescott, der AFAIR auch auf das Thema einging.

[Gast]

hmm, ich weiß jetzt nicht..ach schreib ich einfach *gg*

eine cpu-pipeline kann man sich wie eine fließband-fertigung vorstellen, je länger sie ist und je kleiner die arbeitssschritte desto höher der takt.

kleinere arbeitsschritte bringen immer mehr gesamtperformance mit sich, und erlauben hohe taktraten.
sollte man meinen, zumindest will intel das allen glauben machen ;)

amd fährt anders rum, je kleiner die pipeline desto weniger tragisch ist ein fehler in der sprungvorhersage (das letzte mal beim p3-tulation bei intel verbessert, soweit ich weiß).

d.h. tritt ein fehler am ende des fließbandes aka. pipeline auf, ist dieser extrem schlecht für die cpu leistung.


wenn intel also die pipeline wie beim presskotz verlängert (umd fast 1/3tel), erhöhen sie zwar den takt, aber gleichzeitig senken sie die pro mhz leistung.
also schaufelt man bei pipeline-verlängerungen von einer seite auf die andere, ohne wirklich die performance zu erhöhen -> wirklich höher wird sie durch neu fertiungsprozesse (90nm-> intel(bald auch amd), soi->ibm, amd(bald auch intel)) oder durch verbesserte sprungvorhersage, auch neue befehlssätze leisten ihren teil und verbesserte speicheranbindung (einerseits quad-pumped bein intel, oder dual-channel, oder auch neu steppings -> cg-stepping beim amd64).


jetzt zum presskotz:
intel hat bei der pipeline wieder auf die daus gesetzt (mhz=leistung :roll: ), also hat man mehr oder weniger sinnvoll/sinnlos die pipeline erhöht, im gegenzug hat intel dafür auch den 2nd-level-cache erhöht um die leistungseinbusen bei der pro mhz leistung abzufangen.
die 90nm technologie wird hier erst später positiv wirkung zeigen, aber im moment scheint intel diese noch kein bisschen in den griff bekommen zu haben (ab sommer solls besser werden)



das ganze spielt jetzt noch mit den von den anderen genannten punkten zusammen, man verzeihe mit den billigen vergleich von einer pipeline einer cpu mit einem fließband, vielleicht kann ja jemand die cpu-pipeline an sich erläutern?

grüße hoschi

[Birdman]

Original geschrieben von CrazyIvan
AFAIK hat man doch beim Prescott auch das halbe Cache - Management umgebaut, damit dieser wieder besser mit dem Takt mitskalieren kann.

Intel hat nur die Latenz verringert damit der Cache überhaupt noch taktsteigerungen mitmacht.
Das mit der "Effizient" bei diesem Thema kam von Vergleichen mit Northwood, wo aufgezeit wurde, dass beim Prescoot irgendwo über 4Ghz wieder die selbe absolute Latent (in ns) erreicht wird wie beim Northwood jetzt. (3.2Gz)

[mrdigital]

Original geschrieben von Birdman
Intel hat nur die Latenz verringert damit der Cache überhaupt noch taktsteigerungen mitmacht.
Das mit der "Effizient" bei diesem Thema kam von Vergleichen mit Northwood, wo aufgezeit wurde, dass beim Prescoot irgendwo über 4Ghz wieder die selbe absolute Latent (in ns) erreicht wird wie beim Northwood jetzt. (3.2Gz)
Intel hat die Latenz vergrössert ;)
Wenn sie kleiner geworden wäre, dann wäre der P4E Cache schneller als der P4C Cache.

[Piffan]

Ohne hier genau zu werden: Es kommt immer auf den jeweiligen Flaschenhals an.....Ist es die CPU, dann skaliert die Anwendung linear mit dem Takt. Bilden Bandbreiten den Flaschenhals, dann nähert sich der Gewinn pro Takterhöhung der Null an.....

Logischerweise gibts in jeder Anwendung beide Zustände von Zeit zu Zeit, interessant ist eben der Mittelwert. Wahrscheinlich ist es auch von Belang, wieviel vom Code in den Cache des Prozessors passt. Da könnte man annehmen, dass der Barton besser skaliert als der Tbred, und dieser wieder besser als der Duron....

Wenn ich das System über den FSB übertakte und alle Komponenten schneller werden und ich die Timings des Speicher nicht ändern muß, dann skaliert JEDE Anwendung linear mit dem Takt bis auf jene, die in anderer Beziehung hardwareabhängig sind, zb. 3d- Grafiken, wo die Graka der Flaschenhals werden kann....


Übrigens ist die Frage nicht eindeutig: Ist die höchste Taktung einer Baureihe gemeint oder ein einzelnes Exemplar, dass ich per OC quäle? Ich bezog mich auf ein einzelnes Exemplar, dass ich taktmäßig komplett ausquetsche....

[mrdigital]

Original geschrieben von Piffan
Ohne hier genau zu werden: Es kommt immer auf den jeweiligen Flaschenhals an.....Ist es die CPU, dann skaliert die Anwendung linear mit dem Takt. Bilden Bandbreiten den Flaschenhals, dann nähert sich der Gewinn pro Takterhöhung der Null an.....

Logischerweise gibts in jeder Anwendung beide Zustände von Zeit zu Zeit, interessant ist eben der Mittelwert. Wahrscheinlich ist es auch von Belang, wieviel vom Code in den Cache des Prozessors passt. Da könnte man annehmen, dass der Barton besser skaliert als der Tbred, und dieser wieder besser als der Duron....

Wenn ich das System über den FSB übertakte und alle Komponenten schneller werden und ich die Timings des Speicher nicht ändern muß, dann skaliert JEDE Anwendung linear mit dem Takt bis auf jene, die in anderer Beziehung hardwareabhängig sind, zb. 3d- Grafiken, wo der Flaschenhals die Graka werden kann....


Übrigens ist die Frage nicht eindeutig: Ist die höchste Taktung einer Baureihe gemeint oder ein einzelnes Exemplar, dass ich per OC quäle? Ich bezog mich auf ein einzelnes Exemplar, dass ich taktmäßig komplett ausquetsche....
das heisst, dass du die Arbeitsgeschwindigkeit mit einer Funktion in der Art 1-e^-x , wobei x die Freuqenz ist modellierst. Da bin ich mir nicht so sicher, es könnte auch eine Funktion in der Art ln(x) sein, die wächst zwar sehr langsam für grosse X, aber sie geht auch gegen Unendlich für x gegen Unendlich. Ich tendiere eher zu ln(x), denn bislang war jeder Rechner, wenn er denn höher getaktet war (innerhalb einer Modellserie) immer schneller als das Vorgängermodell, wenn auch teilweise nur wenig. Zum anderen hiesse es ja, wenn man die Geschwindigkeit mit 1-e^-x modeliert, dass es ein absoluts Maxiumum an Geschwindigkeit gäbe und das glaube ich auch nicht.

[Avalox]

Es wird immer von der CPU gesprochen.

Letztendlich sind Verzögerungsstufen und Performanzvernichter wie z.B. ein Prozessorcache heute Bestandteil einer CPU.
Wenn die reine Lehre betrachtet wird, gehören entsprechende Einheiten nicht zur CPU.
Es sind Krücken um die unterschiedlichen technischen Gegebenheiten miteinander verbinden zu können.
Kurz IO. Diese folgen ja nicht so sehr physikalischen Grenzen, als vielmehr wirtschaftlichen.
Eine CPU muss sich auch verkaufen lassen. Ein Beispiel. Eine moderne CPU wird z.B. für langsamsten Speicher konzipiert. Eine dieser Konzeptkrücken ist der Level 3 Cache. Die Krücke dieser Krücke ist der Level 2 Cache, dessen Kompromiss wieder im 1. Level Cache zu finden ist.

CPU skalieren also schlecht(er als nötig) mit zunehmenden Takt, weil es der Kunde so will bzw. diese CPUs mit dieser Eigenschaft kauft.

[-error-]

Original geschrieben von Piffan
Bilden Bandbreiten den Flaschenhals, dann nähert sich der Gewinn pro Takterhöhung der Null an.....

Das heisst also wenn ich meine CPU um 200mhz höher takte, den Ram aber nicht mehr höher übertakten kann, war das für die Katz?

[MechWOLLIer]

Original geschrieben von Powerd by ATI
Das heisst also wenn ich meine CPU um 200mhz höher takte, den Ram aber nicht mehr höher übertakten kann, war das für die Katz?

Nicht für die Katz, allerdings du erhälst prozentual weniger Geschwindigkeitszuwachs, als durch den höheren Takt möglich

[Piffan]

Wenn die Bandbreite völlig am Anschlag ist, also ein Maximum an Daten zwischen Speicher und Prozessor ausgetauscht wird, dann ist in der Tat JEDE Takterhöhung des Prozessors für die Katz. Knallhart gesprochen. Natürlich sind solche Extremsituationen bei der CPU nicht immer vorhanden, hängt ja vom Code/Programm ab und wie weit der Cache da puffert......

Genauso war DDR- RAM für den Pentium 3 auch völlig für die Katz, dessen Interface konnte mit der Bandbreite nix anfangen. Der Athlon dagegen skalierte prächtig mit der Taktzahl, er fing mal bei 600 Mhz an und rennt heute mit der vierfachen Taktzahl....Sein Interface profitierte von der Bandbreite des DDR- Speichers.

Hat Leo nicht auf diesen Seiten mal einen Artikel zu diesem Thema geschrieben?

Wenn eine die Performance linear mit der Taktzahl des Prozessors skalieren soll, dann müssen alle Flaschenhälse ebenfalls im selben Verhältnis geweitet werden....Daher ist OC per FSB immer noch die effektivste Methode...

[Snoopy69]

Hab leider nicht alle Postings gelesen - weiß also nicht ob´s schon da steht...

OC per FSB ist wirklich effektiv... Bedeutet das aber auch, daß es nur effektiv ist, wenn AGP und PCI nicht gefixt sind - ja, oder?
Ich mein, bei meinem Shuttle AN50R ist das ja gefixt, komme aber dadurch höher mit FSB, als beim Vorgänger MSI K8T NEO-FIS2R...

Und noch ´ne Frage... Beim AN50R kann ich im BIOS den AGP-Takt separat einstellen. Bleibt der PCI-Takt dadurch unberührt? Ich bin mir da net sicher. Wenn ich zb mit "ClockGen" den VCore einstellen will, zeigt mir das Programm zwar den eingestellten Wert an - ist aber real NICHT gesetzt!
Multiplikator und FSB geht sicher, aber bei AGP/PCI-Takt weiß ich das net genau... Hat Jmd einen Plan?

[Piffan]

Original geschrieben von Snoopy69
Hab leider nicht alle Postings gelesen - weiß also nicht ob´s schon da steht...

OC per FSB ist wirklich effektiv... Bedeutet das aber auch, daß es nur effektiv ist, wenn AGP und PCI nicht gefixt sind - ja, oder?
Ich mein, bei meinem Shuttle AN50R ist das ja gefixt, komme aber dadurch höher mit FSB, als beim Vorgänger MSI K8T NEO-FIS2R...

Und noch ´ne Frage... Beim AN50R kann ich im BIOS den AGP-Takt separat einstellen. Bleibt der PCI-Takt dadurch unberührt? Ich bin mir da net sicher. Wenn ich zb mit "ClockGen" den VCore einstellen will, zeigt mir das Programm zwar den eingestellten Wert an - ist aber real NICHT gesetzt!
Multiplikator und FSB geht sicher, aber bei AGP/PCI-Takt weiß ich das net genau... Hat Jmd einen Plan?

Ob sich der gefixte AGP auswirkt, ist wie gesagt eine Frage des jeweiligen Flaschenhalses. Bis dato ist der AGP nicht der Flaschenhals, es gibt kein Spiel, dass von AGP 8x profitieren würde. Also ist es latte, ob der AGP ins OC einbezogen wird oder fix ist.

[Gast]

Prima, genau das Richtige ist hier gefallen: die Wirtschaftlichkeit.

Theoretisch steigt die Leistung eines Mikroprozessors mit n Pipelinestufen um den Faktor n an.
Jedoch nur, wenn Sprungvorhersagefehler gegen Null tendieren und die gesamte Umgebung (Verarbeitungsbreite, Register, Caches, Schaltzeiten der Gatter, verrichtete Arbeit je Pipeline-Step) der Steigerung um n Stufen angeglichen wird.


Und das ist wirtschaftlich nicht tragbar.
Also findet man den Kompromiß, daß die Technologie nicht ausgereizt aber bezahlbar wird.
Als Ergebnis kaufen wir also Prozessoren, die nur in einem bestimmten Bereich lineare Zuwächse erzielen.
Ein einfaches Prinzip, was bei jedem Widerstand angewendet wird. :)

Wobei sich in meinen Augen die Intel-Ingenieure reichlich Leerschritte in der Pipeline geleistet haben.
Würden sie die theoretischen Aspekte des Pipelining bzw. ihrer eigenen EPIC-Archtektur beim P4 mehr berücksichtigen, würde das Ding jeden Athlon in den Boden stampfen. Aber man gab der strategischen Wärmeentwicklung den Vorzug. :[

MfG

[Lokadamus]

Original geschrieben von pippo
Eigentlich hab ich da auch keine Ahnung, aber ich könnte mir vorstellen, dass dadurch, dass der Speicher ja gleich getaktet bleibt, die CPU bei höherem Takt länger auf Daten aus dem Arbeitsspeicher warten muss und dieser nochdazu nichtmehr mit der nötigen Bandbreite aufwarten kann.

Jedoch alles nur Vermutung ;) mmm...

Wenn ich es richtig verstanden habe, setzt HT an diesem Punkt an: Wenn eine Anwendung Daten aus dem Speicher anfordert und wartet, dauert es je nach MHz der CPU 50 - 150 Takte, welche die CPU im Leerlauf verbringt. Je höher die Geschwindigkeit der CPU, desto mehr Takte werden es, welche die CPU im Leerlauf verbringt. Damit die CPU trotzdem was zu tun hat, wird einfach die nächste Anwendung abgearbeitet, in der Hoffnung, dass deren Daten schon im 1. oder 2. Level Cache sind und diese Anwendung fertig ist, wenn die Daten aus dem Ram endlich eintrudeln. Da die Daten aus dem Ram aber auch erwartet werden müssen, muss eine 2. CPU vorhanden sein, schliesslich benötigt jede Anwendung nur ihre eigenen Daten und nicht die Daten irgendeiner anderen Anwendung.
Durch diese Art der Abarbeitung kann eine Anwendung nicht mehr die vollen 100% an CPU-Zeit bekommen, aber die abgearbeitete Datenmenge steigert sich insgesamt, wodurch die Gesamtperformence besser wird.

Hier (http://www.lokadamus.de.vu/Prime95.PNG) noch ein kleiner Screenshot von meiner Kiste und Prime95, während bei der 1. CPU ein Einbruch passiert, steigt bei der 2. CPU die Aktivität auf das Niveau der 1. CPU. Wenn ich jetzt nur noch wüsste, ob ich da den Taskmanager in den Prime-Test geschoben habe oder den Screenshot angefertigt habe ...

So hab ich das Prinzip verstanden, wenn nicht, klär mich einer auf.

Bei den 1. Test, die ich zu HT gesehen habe, wurde als Beispiel Halo? (im Fenstermodus aber nur) und ein Brennprogramm gezeigt. Ohne HT scheiterte der Brennvorgang und Halo brach dauernd ein, mit HT hatte Halo ca. 80 % der max. Frameraten und der Brennvorgang wurde mit voller Geschwindigkeit erfolgreich abgeschlossen.

Wegen CPU und OC (overclocking), es wird mit der CPU auch gleich der 1. und 2. Level-Cache übertaktet, wodurch Daten, die schon drinne sind, schneller abgearbeitet werden.

[CrazyIvan]

Original geschrieben von Gast Theoretisch steigt die Leistung eines Mikroprozessors mit n Pipelinestufen um den Faktor n an.
Jedoch nur, wenn Sprungvorhersagefehler gegen Null tendieren und die gesamte Umgebung (Verarbeitungsbreite, Register, Caches, Schaltzeiten der Gatter, verrichtete Arbeit je Pipeline-Step) der Steigerung um n Stufen angeglichen wird.


Naja, so kann man das IMHO auch nicht pauschalisieren.
Pipelining erreicht seine höchste Effizienz dann, wenn die Länge mit der Anzahl der verschiedenen Operationen auf ein Datenpaket bzw. einen Wert übereinstimmt. Wenn also quasi nur jeweils eine Stufe für Fetch und eine für Execute da sind, dann ist die optimale Pipelinelänge 2. Und das auch nur, wenn keine Daten-/Steuerflussabhängigkeiten bestehen.

In der Praxis unterteilt man halt diese Phasen in mehrere kurze Schritte - die Pipelinestufen. Somit ist jeder Schritt in kürzerer Zeit machbar und die Taktbarkeit der CPU steigt. Insofern ist eine längere Pipeline nur dadurch effizienter, als dass sie höher taktbar ist. Aber theoretisch sollte erstgenanntes am effizientesten sein. Gleiches gilt für Länge = n * 1.)

[Gast]

Und ob man das "pauschalisieren" kann, denn das sind die theoretischen Grundlagen, die dahinter stehen.

Es sei denn, man behauptet frech, daß in einem Mikroelektronik-Studium Müll erzählt wird, lol.

:P
:)