Skalierung der Rechenleistung bei OC, ist das Ende schon fast erreicht?

[Angiesan]

Hi,

da ich zur Zeit Krank auf der faulen Haut liege, kommen einem so der ein oder
andere Gedanke was mach ich so den ganzen Tag:D außer gesund werden;)

Also mal wieder mit dem Thema Übertakten meines C2D 6400 beschäftigt und ein wenig rumgetaktet.

So beim Nachmessen der neu gewonnenen Rechenleistung hat mich dann aber doch mal interessier, was ist das eigentlich in %, was man durch das OC
dem Rechner da neu entlockt.

Als Benchmark kam nur Super PI in der Version 1,50 zum Einsatz und die Ergebnisse
dürften für die Meisten nicht ganz neu sein, da sich schon die ein oder andere Internetseite aber auch die meisten Printmedien mit dem Thema erschöpfend befast haben.

Was aber bei allen Test fehlt ist die Pro Mhz Leistung die ich durch das OC gewinne oder eben nicht .

Als Testsystem diente ein Gigabyte GA 965 P DS4 bestückt mit einem C2D 6400, Speicher sind 2GB MDT 800MHz. Der Speicher lief bei den Taktraten 2133 MHz und 3200 MHZ mit 800MHz und bei 2645 mit 660 MHz

Da ich eine Vergleichsgröße für die genannte pro MHz Leistung benötige habe ich einfach kurzerhand eine "Pi Sekunde als Teiler verwendet und die Ergebnisse haben zumindest mich doch sehr überracht.
Takt....................2133...........2645...........3200
0%......................100,00%......124%..........150%
pi/sec..................26,00..........21,75 ..........18,75
Leistung %...........100%..........116,35.........127,88%
Takt per pi sec......82,04..........121,61.........170,66
0%......................100,00%......148,23%......208,02%


Jetzt bin ich mir nicht ganz sicher, ob man dies auf die Architektur des C2D schieben sollte, oder ob dies mit einer mathematischen Besonderheit verbunden ist.

Fakt ist, dass der Takt pro berechneter "Pi Sekunde" abnormal steigt. Wenn mann sich das so anschaut, und man daraus einen Rückschluß auf die mögliche Leistungsfähigkeit der Core Architektur versucht abzuleiten, sind hier im 3d-center schon Einige an das theoretisch Limit gekommen, mehr wie 4 GHz dürften keinen nennenswerte Verbesserung mehr mit sich bringen.

Liege ich hier komplett falsch? Oder ist da was dran.

Grüße

[Botcruscher]

Super Pi bei 3.9 GHz rund 13 sec. Ist also doch einiges.

[Gast]

Höhere Taktraten bedingen höhere Speicherbandbreiten, sonst wird die CPU gebremst.

Setz den FSB mal auf 2133/266, 2666/333 und 3200/400. Dann sollte das Ergebnisse anders aussehen.

[Gast]

Liege ich hier komplett falsch? Oder ist da was dran.

Ja.

1. SuperPi ist auch Speicherhungrig.
2. teste mal andere Anwendungen/Spiele (Dirt mit seiner mehr als 1:1 CPU-Taktskalierung)

[DerRob]

pi/sec..................26,00..........21,75 ..........18,75
Leistung %...........100%..........116,35.........127,88%
hm, irgendwie verstehe ich diese leistungssteigerung nicht so recht, ich komme da eher auf 19,5% bzw. 38,7%. oder rechne ich da irgendwas falsch rum?

[Wurschtler]

hm, irgendwie verstehe ich diese leistungssteigerung nicht so recht, ich komme da eher auf 19,5% bzw. 38,7%. oder rechne ich da irgendwas falsch rum?


Nein, du liegst richtig. Da hat sich Angiesan verhaun.

[Gast]

so lange nicht durch FSB oder speicherbandbreite gebremst, sehe ich keine grund dass Takt nicht zu ~100% skalieren sollte.

[Spasstiger]

Da hat wohl jemand in Mathe nicht richtig aufgepasst. Die Leistungssteigerung bei einer Verkürzung der Zeit von 26 Sekunden auf 18,75 Sekunden beträgt rund 39%.
Den höheren Takt durch eine niedrigere Zeit zu teilen ist total bescheuert, natürlich kommen da auf einmal so unterschiedlich große Zahlen raus (selbst bei einer 1:1-Skalierung würden stark unterschiedliche Zahlen rauskommen).
Wenn, dann müsstest du das Performancelevel (z.B. 100%, 139%) durch das Taktlevel (100%, 150%) teilen, um eine Aussage über die Leistung pro Megahertz treffen zu können.

Alternativ kann man auch berechnen, wieviel Taktzyklen für die Berechnung benötigt wurden, das ist wenigstens ein greifbarer Wert, unter dem man sich konkret etwas vorstellen kann.
Und dazu muss man die Zeit in Sekunden mit dem Takt in Hz multiplizieren.
Dann ergibt sich:
2133 MHz - 55,46 Milliarden Takte
2645 MHz - 57,53 Milliarden Takte
3200 MHz - 60,00 Milliarden Takte

P.S.: In Super Pi wurden auch schon weniger als 9 Sekunden erreicht und dazu musste der Takt gegenüber 3200 MHz nicht verdoppelt werden. Übetakteter DDR3-Speicher und ein extrem hoher FSB helfen nämlich, die Recheneffizienz des Core 2 Duo in SuperPI zu verbessern.

[=Floi=]

hat eigentlich AMD mit ihrem integrierten memorycontroller hier vorteile?
bzw spielt es eine rolle?
imho hat doch der core 2 hier mehr vorteile weil er nicht so extrem am ram hängt, sehe ich das richtig?

[Angiesan]

Nein, du liegst richtig. Da hat sich Angiesan verhaun.
s.u.
Da hat wohl jemand in Mathe nicht richtig aufgepasst. Die Leistungssteigerung bei einer Verkürzung der Zeit von 26 Sekunden auf 18,75 Sekunden beträgt rund 39%.
Den höheren Takt durch eine niedrigere Zeit zu teilen ist total bescheuert, natürlich kommen da auf einmal so unterschiedlich große Zahlen raus (selbst bei einer 1:1-Skalierung würden stark unterschiedliche Zahlen rauskommen).
Wenn, dann müsstest du das Performancelevel (z.B. 100%, 139%) durch das Taktlevel (100%, 150%) teilen, um eine Aussage über die Leistung pro Megahertz treffen zu können.

Alternativ kann man auch berechnen, wieviel Taktzyklen für die Berechnung benötigt wurden, das ist wenigstens ein greifbarer Wert, unter dem man sich konkret etwas vorstellen kann.
Und dazu muss man die Zeit in Sekunden mit dem Takt in Hz multiplizieren.
Dann ergibt sich:
2133 MHz - 55,46 Milliarden Takte
2645 MHz - 57,53 Milliarden Takte
3200 MHz - 60,00 Milliarden Takte

P.S.: In Super Pi wurden auch schon weniger als 9 Sekunden erreicht und dazu musste der Takt gegenüber 3200 MHz nicht verdoppelt werden. Übetakteter DDR3-Speicher und ein extrem hoher FSB helfen nämlich, die Recheneffizienz des Core 2 Duo in SuperPI zu verbessern.
so lange nicht durch FSB oder speicherbandbreite gebremst, sehe ich keine grund dass Takt nicht zu ~100% skalieren sollte.

Nein tut er nicht, und ich gebe das Kompliment zurück;)

Bei einer Verkürzung der Zeit muss man von einem erhöhtem Grundwert ausgehen um die Einsparung in Prozentpunkten zu ermitteln.
Die o.a. Werte stimmen also.
Wenn ich ermitteln möchte wieviel länger die Zeit ist die ich benötige ist dein Berechnung richtig.
Ich hätte aber eher Ersparte Zeit anstelle von Leistung schreiben sollen.
Ansonsten kann ich deinen Argumenten nicht ganz folgen, Fakt ist, dass eine 1:1 Skalierung nicht erfolgt selbst bei erhöhtem FSB zu erhöhtem Takt nicht.
Und wenn Du es schaffst eine Anwendung ob Spiel oder Sonstiges aufzuzeigen wo eine 1:1 Steigerung des Taktes eine 1:1 Steigerung der FPS oder der Verkürzung der Zeit mit sich bringt stelle ich mich in die Ecke.
Wenn ich die Taktzyklen als Berechnungsgrundlage nehme, wird doch nichts anderes aufgezeigt wie das was ich auch getan habe, denn die Anzahl an Berechnungen bleibt ja gleich, wenn ich das Programm richtig verstanden habe, oder? Was passiert mit den rund 4,5 Mrd Zyklen wenn die zu berechnende Menge nicht steigt, sondern nur die Zeit verkürzt wird?

Grüße

[Gast]

Fakt ist, dass eine 1:1 Skalierung nicht erfolgt selbst bei erhöhtem FSB zu erhöhtem Takt nicht.

Warum sollte es nicht möglich sein? Ich hab schon Benches gesehen, die sehr nahe an diesen Wert herankamen. Ganz herankommen ist nur bei gewissen Spezialanwendungen möglich, denn man muss sicherstellen, das weder RAM noch Festplatte ein Flaschenhals darstellen.

Wenn du wie in deinem Beispiel den Takt um 50% erhöhst, dann solltest du auch so clever sein und Speicherbandbreite ebenfalls um 50% zu erhöhen, denn sonst testest du weder die CPU noch die Architektur, sondern hauptsächlich deinen RAM...

[=Floi=]

cinema 4d
bei thg gib es da passende charts