Lösung : Prozessorspeed in MHZ

kann hier jemand mal paar fragen beantworten?

Nobuo T

Theoretischer Ansatz (ungetestet) :
Mit RTC oder PIT die Zeit messen, die zum Durchlaufen eines bestimmten Codes gebraucht wird.
Da waere dann weder RDTSC noch sleep drin.

Einen Code zu schreiben, der angesichts der zahlreichen Optimierungen in modernen CPU noch verlaessliche Ergebnisse erzeugt, stelle ich mir so jedoch gar nicht mal so trivial vor...

Momentan habe ich aber weder die Zeit, noch ueberhaupt ein Interesse daran, so einen Code fuer irgendein System zu schreiben.
Falls ihr also darauf wartet, hier etwas Code zu sehen zu bekommen, muss ich euch wohl leider erstmal entteuschen.

neverbeenhere

devil667 schrieb:

hi, ahhh ja. wie würde denn selbiges mit der prozessortemperatur funzen??

gruss und dank

is völlig abhängig vom prozessor, von daher bleibt dir als einzige möglichkeit ACPI

burnner

DEV_c++ will das auch...

hi,

ich wollte das grade auf nem centrino laptop unter bc++b 4 compilieren, aber er meint zu rdtsc: "Illegal instruction for currently selected processor(s)."

Nobuo T

Dann musst du wohl in deinen Compiler-Optionen mal rumsuchen und den Prozessortyp auf mindestens 586/Pentium stellen.

Hallo!

Ich weiß, das Topic ist uralt, aber hab da noch mal was zu sagen:
Ich habe einen AMD Athlon64 3800+. Wenn ich den per Cool'n'Quiet auf 1000 MHz oder 1800 MHz laufen lasse, wird die Geschwindigkeit korrekt angezeigt. Stelle ich ihn aber auf den Normaltakt (2400 MHz) bekomme ich -2147.48 MHz.
Ist der Code nicht für hohe Geschwindigkeiten geeignet?

MfG
Egor

YASC

Bei mir funktioniert das sogar noch bei 3 GHz

und ich bekomms mit dem borland-assembler einfach nicht gebacken:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-963208.html#963208

robak

[ERASED]

camper

das ignorieren von edx ist eine schlechte idee - spätestens wenn wir über 4GHz kommen (Pentium D 805 OC'ed irgendwer? ) haben wir hier ein überlaufproblem, dass sich durch differenzbildung nicht in den griff kriegen lässt. zweitens besteht bei multi-core/multi-prozessor systemen das problem, dass der scheduler gerade nach einem sleep, den prozess ohne weiteres an eine andere cpu binden könnte. womit die ganze messung sinnlos wird, denn deren time stamp counter sind nicht identisch (nicht mal synchron, wenn eine cpu z.b. runtertaktet zwecks sleep a la cool'n quiet etc.). für gcc muss nat. die syntax angepasst werden:

inline unsigned long long rdtsc()
{
    unsigned long long result;
    asm ( "rdtsc" : "=A" ( result ) );
    return result;
}
int GetMHZ()
{
    unsigned long long dwValue = rdtsc();
    Sleep(1000); // wirkt als barrier - andernfalls müssten wir hier ein bisschen tricksen, um optimierungen um sleep herum zu verhindern
    return (rdtsc() - dwValue)/1000000;
}