Delphi-PRAXiS
Seite 5 von 16   « Erste     345 6715     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Software-Projekte der Mitglieder (https://www.delphipraxis.net/26-software-projekte-der-mitglieder/)
-   -   CPUiD 3.0 - Ein kleines System - Diagnoseprogramm (https://www.delphipraxis.net/49749-cpuid-3-0-ein-kleines-system-diagnoseprogramm.html)

himitsu 1. Jan 2006 16:02

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
@Luckie :
ich habe es mehrmals messen lassen und es ist definitiv keine der üblichen Schwankungen ... bei diesem Programm wird immer mehr angezeigt.

EVEREST: 1808.46 MHz - 1808.58 MHz
Hagen: 1808.79 MHz - 1808.81 MHz
dieses: 1812,9998 MHz

(wobei es mich hier wundert, daß es keine Differenz gibt, denn rein technisch geht es ja nicht ohne ein kleine Abweichung)

stefan2005 1. Jan 2006 16:23

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
hi,
mein CPU wird zwar korrekt als "Athlon 64 X2 DualCore" erkannt, aber unter den AMD-Flags ist kein Häckchen bei "Dual-Core CPU" :lol:

mfg,
stefan

MagicAndre1981 1. Jan 2006 17:32

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Zitat:

Zitat von stefan2005
mein CPU wird zwar korrekt als "Athlon 64 X2 DualCore" erkannt

Das ist der Brand-String, den die BIOS-Programmieren festgelegt haben (ab dem AthlonXP steht der String nicht mehr fest bei AMD-Prozzis)

Zitat:

Zitat von stefan2005
, aber unter den AMD-Flags ist kein Häckchen bei "Dual-Core CPU" :lol:

weil sein Programm den Prozzi nicht kennt ;-)

Daniel G 1. Jan 2006 20:24

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Zitat:

Zitat von stefan2005
hi,
mein CPU wird zwar korrekt als "Athlon 64 X2 DualCore" erkannt, aber unter den AMD-Flags ist kein Häckchen bei "Dual-Core CPU" :lol:

Dann liegt das daran, dass der Flag, der normalerweise gesetzt ist, in deinem Falle aus irgendeinem Grund nicht gesetzt ist. Entweder hat scp das falsch implementiert, AMD hat den Flag verändert oder aber man hat dich verarscht.


@himitsu: Ja, das ist mir auch aufgefallen. Ich kanns leider nicht mehr ändern.

Mal sehen, eine komplette Neuauflage wäre vielleicht eine gute Idee für das neue Jahr.

I'll keep you posted!

Ghostwalker 1. Jan 2006 22:13

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Liste der Anhänge anzeigen (Anzahl: 1)
Ok..im Anhang findest du die Daten, die Everest ausspuckt :)

Thebe 3. Jan 2006 10:35

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Liste der Anhänge anzeigen (Anzahl: 1)
Bei meinem Sockel 478 Northwood wird kein L2 Cache von deinem Programm erkannt, obwohl Everrest da 512 KB zu sehen vermag. Ich häng ma komplett die HTML Datei von CPUiD und die Infos die Everest bei CPU und CPUID ausschmeißt per Anhang an.

Schickes Programm btw :)

- Thebe

Daniel G 3. Jan 2006 11:56

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
@ Ghostwalker & Thebe: Danke für eure Dateien, ich arbeite jetzt tatsächlich an einer kompletten Neuauflage. Diesmal übrigens mit der VCL.

@All: Die Sache mit der Geschwindigkeit geht mir nicht mehr aus dem Kopf. Ich benutze folgenden Code, allerdings nicht selbst geschrieben:

Delphi-Quellcode:
//Helping Function for "GetCPUSpeed"
function ActivateTimer: Int64;
asm
   push   eax
   push    edx
   db      0fh
   db      31h
   mov      [esp], eax
   mov      [esp+4], edx
   pop      eax
   pop      edx
end;

// From "CPUID for Delphi" by Ural Gunaydin
function GetCpuSpeed(msTime: DWORD): Double;
var
   llStart, llStop: Int64;
   dwStart: DWORD;
   timecaps: TTimeCaps;
   bf1, bf2, minErr, tErr,
   ratio, bestRatio, bestBf: Double;
begin
   result:= 0.0;
   if (timeGetDevCaps(@timecaps, sizeof(TTimeCaps)) <> TIMERR_NOERROR) then
   Exit;

   timeBeginPeriod(timecaps.wPeriodMax);
   dwStart:= timeGetTime;
   llStart:= ActivateTimer;
   while ((timeGetTime() - dwStart) < msTime) do
   begin
      //
   end;
   llStop:= ActivateTimer;
   timeEndPeriod(timecaps.wPeriodMax);
   result:= (llStop - llStart) / msTime;

   bf1:= 1000*50.00000;
   bf2:= 1000*66.66666;
   minErr:= result;

   ratio:= Round(result / bf1);
   bestRatio:= ratio;
   bestBf:= bf1;
   tErr:= (ratio * bf1) - result;
   if (tErr < minErr) then
   begin
      minErr:= tErr;
      bestRatio:= ratio;
      bestBf:= bf1;
   end;
   ratio:= ratio-1;
   tErr:= result - (ratio * bf1);
   if (tErr < minErr) then
   begin
      minErr:= tErr;
      bestRatio:= ratio;
      bestBf:= bf1;
   end;
   ratio:= Round(result / bf2);
   tErr:= (ratio * bf2) - result;
   if (tErr < minErr) then
   begin
      minErr:= tErr;
      bestRatio:= ratio;
      bestBf:= bf2;
   end;
   ratio:= ratio-1;
   tErr:= result - (ratio * bf2);
   if (tErr < minErr) then
   begin
      bestRatio:= ratio;
      bestBf:= bf2;
   end;
   result:= bestRatio * bestBf;
   //CpuInfo.CPUFreq:= result;
end;
Aufgerufen wird er mit:

Delphi-Quellcode:
something := Format('%.2f MHz', [GetCpuSpeed(1000) / 1000]);
Erkennt ihr irgendeinen Stolperstein?

himitsu 3. Jan 2006 14:17

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Was ich aber mal denken würde, ist daß in folgendem Code die Reinfolge der Timer nicht stimmt ... denn um die unterschiedlichen Start-/Endzeiten der einzelnen Timer zu vernachlässigen, müssen diese in der selben Reinfolge beendet werden, wie sie auch gestartet wurden.
(timeXXXPeriod und ActivateTimer direkt aufeinander folgend ... und timeGetTime innerhalb der Schleife)
Delphi-Quellcode:
timeBeginPeriod(timecaps.wPeriodMax); <<<
llStart:= ActivateTimer;                      <<<
dwStart:= timeGetTime;
while ((timeGetTime() - dwStart) < msTime) do
begin
   // 
end;
timeEndPeriod(timecaps.wPeriodMax); <<<
llStop:= ActivateTimer;             <<<
result:= (llStop - llStart) / msTime;


Dann ist dein ActivateTimer etwas umständlich geschrieben.
(was aber zu keiner Messverfälschung führen wird ... jedenfalls, wenn die Timer in der richtigen Reinfolge gestartet/beendet werden)
Denn du holst dir den TSC-Wert, lädst diesen in den Stack und holst ihn zurück.
Aber wenn du genau hinsiehst, dann wirst du merken, daß sich nach dem Aufruf von RDTSC (DW $310F) die Werte in EAX und EDX nicht verändern.

Du lädst also z.B. EAX per mov [esp], eax in den Stack und holst ihn dann vom Stack wieder per pop eax in EAX zurück ... also "sinnloses" Hinundhergeschiebe.

Es würde also Folgendes vollkommen ausreichen:
Delphi-Quellcode:
function ActivateTimer: Int64;
asm
   db     0fh
   db     31h
end;

Und dann kannte ich deine MultimediaTimerFunktionen (timeBeginPeriod, timeEndPeriod) noch nicht ... weiß einer, wie genau die sind?
Und ob die Intern auch gleichschnell arbeiten und an der selben Stelle die Zeit messen, denn dieses könnte auch noch Fehler in die Gesamtmessung bringen.
Eventuell solltest du es mal mit einem Timer versuchen, bei welchem man die selbe Funktion für den Begin und das Ende der Messung verwenden kann ... z.B. QueryPerformanceCounter.


Und natürlich kann auch ein Fehler in der anschließenden Berechnung sein ... wozu soll daß denn eigentlich diehnen ... ich vermute ja dahinter mal die Tatsache, daß sich der Wert bei mehreren Messungen nicht ändert, denn es wird ja immer ein paar kleine Unterschiede geben, schon alleine dadurch, daß es sich um kein RealTimeSystem beim PC handelt und wie Luckie nachfolgend schon sagt, sich auch leicht andere Prozesse einschleichen und den Wert etwas verändern können.

Luckie 3. Jan 2006 14:20

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Vor der Messung sollte die Priorität des Prozess auf TIME_CRITICAL gesetzt werden und danach natürlich wieder zurück. Ich habe festgesttelt, dass dies bei CPUID wohl nicht passiert, zumindest zeigt der Taskmanager nichts an in dieser Richtung.

himitsu 3. Jan 2006 14:25

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
CPUID? ... du meinst wohl RDTSC (RealTimeCPUCounter)?

Und nein, da wird sowas nicht gemacht, der Befehl kopiert einfach nur den aktuellen Wert des RealTimeCPUCounter in EAX/EDX.


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:54 Uhr.
Seite 5 von 16   « Erste     345 6715     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz