CPU-Stresstest selber programmieren

[Gast]

Hi Leute!

Ich erlerne gerade C++ (nach Java) und will einen kleinen Stresstest programmieren, dabei soll die CPU als auch der RAM getestet werden. Dazu definiere ich mehrere Konstanten und berechne aus ihnen unter Ausnutzung von Grundrechenarten und anderen Funktionen (Sinus, Wurzel, ...) in einer Schleife ein Ergebnis als float. Damit fülle ein sehr großen float-Array (also immer dasselbe Ergebnis). Um den Speicher zu füllen, kann man ja beliebig viele solcher Arrays anlegen. Nachdem alle Arrays mit den berechneten Werten gefüllt wurden, wird jeder Wert der Reihe nach ausgelesen und mit dem Soll-Wert verglichen. Dadurch lassen sich Fehler sowohl bei der Berechnung als auch bei Zugriffen auf den RAM feststellen. Der Nachteil ist, dass man im Falle eines Fehlers nicht feststellen kann, ob dieser durch die CPU oder den RAM verursacht wurde ... Dazu müsste man weitere Modi implementieren, die z.B. Berechnungen im Cache ausführen, wozu mir noch Fachwissen fehlt.

Was meint ihr dazu? Später lassen sich auch mehrere Threads implementieren ...

Zudem habe ich mir einen weiteren Test überlegt, der aber eher die Spannungsversorgung belastet, indem die CPU abwechselnd mit 100% und 0% Last betrieben wird. Dafür gibt es zwei Zeitperioden t1 und t2, die man selber vorgeben kann. t1 bestimmt, wie lange eine 100%-Phase dauert. Entsprechend steht t2 für die Dauer der 0%-Phase. Dadurch lassen sich sehr schnelle Lastwechsel erzielen, welche die Spannungsversorgung des Motherboards aber auch die Stabilität des Netzteils aus die Probe stellen sollen. Möglich wäre noch ein zusätzlicher Modus in welchem das Programm dann für jede Phase einen anderen, zufälligen Wert für t1 bzw. t2 zwischen t1_min, t1_max, t2_min und t2_max bestimmen würde ...

Habt ihr sonst noch irgendwelche Ideen, Vorschläge?

[huha]

Mach's in Assembler.
Zur vollen Auslastung brauchst du die Befehle, die möglichst viel CPU-Zeit verschwenden und eine möglichst hohe Auslastung aller beteiligter Einheiten verursachen. Leider ist so eine x86-CPU mit allem möglichen Scheiß ausgestattet...
Trigonometrie würde ich allerdings lassen, die könnte ggf. tabelliert sein. Besser wäre es, wenn du die entsprechenden Werte beispielsweise über entsprechende Reihenentwicklungen selber berechnest.

-huha

[Gast]

In Assembler habe ich Mikrocontroller programmiert, aber noch nie x86-CPUs. Aber Windows erlaubt doch eh keinen vollen Zugriff auf die CPU, oder? Der Scheduler funkt doch immer dazwischen. Hat man in x86-Assembler auch direkten Zugriff auf Timer-Interrupts?

[Pinoccio]

Trigonometrie würde ich allerdings lassen, die könnte ggf. tabelliert sein.Tabelliert und dann Polynominterpolation (sagt mir zumindest das Paper vom K5 - dürfte aber nach wie vor zutreffen, da einfach am effektivsten).

@Gast: Deinen Test mit wechselnder Belastung gibt es schon: 3DCenter CPU Ticker (http://www.3dcenter.org/3dtools/cpu-ticker).

mfg

[Berserker55]

Tabelliert und dann Polynominterpolation (sagt mir zumindest das Paper vom K5 - dürfte aber nach wie vor zutreffen, da einfach am effektivsten).

@Gast: Deinen Test mit wechselnder Belastung gibt es schon: 3DCenter CPU Ticker (http://www.3dcenter.org/3dtools/cpu-ticker).

mfg

In gewisser Weise sogar beide Tests.
Nämlich seit 1.3 habe ich ein "Memoryleak" gestopft, welches eben entstanden ist, weil ich die Ergebnisse in ein array speicherte, aber vergessen hatte dieses auszuleeren.

Mit anderen Worten in 1.2 ist der beschriebene Ram Test enthalten, wer das Programm lange laufen lässt, sollte feststellen das die Ram-Auslastung immer mehr ansteigt.

CPU-Ticker ist in Python geschrieben und Source Code mitgeliefert, wenn du das immernoch bauen willst, solltest du vielleicht mal einen Blick in den Code wagen. (Python ist eigentlich recht leicht verständlich)

Für die, die Assembler empfehlen:
Ticker schafft nun schon über 500 Hz mit normalen Python Rechenarten, also sehr weit weg von Assembler.
Ich glaube nicht das man so sehr tief in das low-level gehen muss.
Hier die Stressfunktion vom Ticker als Beispiel:


def stresser(stress, stresss):
z = 0
for s in range(stress):
for h in range(stresss):
z *= h
return z

Einfach sinnlose Multiplikationen

Wobei sicherlich Assembler die Intervalle präziser treffen könnte.

[Pinoccio]

In gewisser Weise sogar beide Tests.
Nämlich seit 1.3 habe ich ein "Memoryleak" gestopft, welches eben entstanden ist, weil ich die Ergebnisse in ein array speicherte, aber vergessen hatte dieses auszuleeren.

Mit anderen Worten in 1.2 ist der beschriebene Ram Test enthalten, wer das Programm lange laufen lässt, sollte feststellen das die Ram-Auslastung immer mehr ansteigt.Naja, ein richtiger RAM-Test sollte schon auch lesen, ob der RAM sich das richtige merkt. ;D
Hier die Stressfunktion vom Ticker als Beispiel:
def stresser(stress, stresss):
z = 0
for s in range(stress):
for h in range(stresss):
z *= h
return z
Einfach sinnlose MultiplikationenIch weiß nicht, was Phyton macht, aber ein guter Compiler könnte das rausoptimieren oder die FPU testet auf Null und rechnet nicht wirklich.
Multiplikation mit einer von 0 verschiedenen Zahl ginge in letzterem Fall so einfach allerdings auch nicht, weil du dann recht fix bei INF landest und die FPU wieder abbiegt.

Zur Auslastung deiens Programms habe ich mal mit Perfwatch (http://www.withopf.com/tools/perfwatch/) angeworfen:
http://www.abload.de/img/bild1x0vf.png (http://www.abload.de/image.php?img=bild1x0vf.png)
BURNK7 burnt auf meinem K8 (also Single-core) ziemlich gut, Withopfs K8-taugliches Core2MaxPerf (http://www.withopf.com/tools/cputempwatch/) kommt da z. B. nicht ran.
BURNK7 ist in Assembler und XORt und shiftet lustig hin und her, vielleicht kannst du sowas mal testweise einbauen.

(Auch wenn natürlich die Auslastung der Recheneinheiten nicht alles über den Stromverbrauch verrät. BURNK7 heizt jedenfalls auch ordentlich.)

mfg

[huha]

Mit Python erreichst du nie die CPU-Auslastung, die du mit einem entsprechend dafür ausgelegten Assembler-Programm hinkriegst. Mußt du aber auch nicht. Python ist eine tolle Sprache, aber da das Zeug nur interpretiert wird, gibt es eben relativ wenig Raum für Optimierungen. Bei Assembler sieht's etwas anders aus, da mußt du händisch entsprechend optimieren (wobei Assembler für Windows keinen so rechten Spaß macht).

-huha

[Coda]

wobei Assembler für Windows keinen so rechten Spaß macht
Hä?

[anddill]

Bei CPU-Ticker geht es primär um die maximale Stromaufnahme. Wir haben einige verschiedene Rechenoperationen getestet, und das war halt das Optimum.

[huha]

Hä?

Assembler für Windows fühlt sich grottig an, wie low-level-C. Ich mach doch keinen Assembler, nur um dann nachher nicht die ganzen üblen Assembler-Tricks benutzen zu können.
Zugegeben, ich habe nicht allzu viele Erfahrungen damit, aber das, was ich bisher in MASM gemacht habe, ist einfach Grütze. Viel zuviele Makros, die Speicherverwaltung erinnert auch an C, generell erinnert das alles zu sehr an C. Ich will aber Assembler und kein C, dann kann ich nämlich gleich C nehmen.

-huha

[Coda]

Du kannst in MASM stinknormalen Intel-Assembler schreiben.

Die Makros sind nur dazu da um einem das Leben zu erleichtern, wenn man will. Zudem hat das sehr wenig mit Windows zu tun. Es gibt auch andere Assembler. Ich verwende auch NASM lieber.

[Berserker55]

Zur Auslastung deiens Programms habe ich mal mit Perfwatch (http://www.withopf.com/tools/perfwatch/) angeworfen:
http://www.abload.de/img/bild1x0vf.png (http://www.abload.de/image.php?img=bild1x0vf.png)
BURNK7 burnt auf meinem K8 (also Single-core) ziemlich gut, Withopfs K8-taugliches Core2MaxPerf (http://www.withopf.com/tools/cputempwatch/) kommt da z. B. nicht ran.
BURNK7 ist in Assembler und XORt und shiftet lustig hin und her, vielleicht kannst du sowas mal testweise einbauen.

(Auch wenn natürlich die Auslastung der Recheneinheiten nicht alles über den Stromverbrauch verrät. BURNK7 heizt jedenfalls auch ordentlich.)

mfg

Burnk7 scheint nicht wider auf null zurückzugehen bzw. zu warten, was für CPU Ticker wichtig ist, da es ja dort eher um einen Netzteil/Stromversorgungstest als einen CPU Test geht, auch wenn der Name etwas irreführend ist.

Einen Auslastungsbogen wie bei deinem Diagramm hatte ich glaube auch schonmal erreicht, aber war eben für meine Zwecke untauglich. ( Der Burn teil)
Aber zugegeben, ich bin mit meiner cpu last funktion noch nicht sehr zufrieden, aber komplexere Sachen lassen sich wider schlechter Zeitsteuern oder haben unterschiedliche Lasten zu unterschiedlichen Zeiten wegen ramabhängigkeit etc.
Außerdem bin ich zurzeit eher am knobeln wie ich die GPU belaste ohne die CPU zu "behindern" um noch mehr Lastschwankungen zu erzeugen.