RÉCUPÉRER LA FRÉQUENCE DU PROCESSEUR
cs_coq
Messages postés
6349
Date d'inscription
samedi 1 juin 2002
Statut
Membre
Dernière intervention
2 août 2014
-
10 juin 2004 à 09:42
Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005 - 10 déc. 2007 à 20:18
Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005 - 10 déc. 2007 à 20:18
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/23561-recuperer-la-frequence-du-processeur
https://codes-sources.commentcamarche.net/source/23561-recuperer-la-frequence-du-processeur
10 déc. 2007 à 20:18
Sinon désolé pour les mises à jour multiples, et j'ai également oublié de retirer un fichier qui n'a rien à voir (FileDecrypt.cs).
10 déc. 2007 à 20:03
eh bien sa marche parfaitement:)
10 déc. 2007 à 19:58
Merci!!!
10 déc. 2007 à 19:51
10 déc. 2007 à 19:46
Quelle version et édition de Windows utilises tu? (XP/Vista, 32/64 bit)
Si c'est Vista ou XP 64, l'erreur doit venir du fait que la mémoire allouée par AllocHGlobal ne possède pas le droit d'exécution.
Pour corriger cela, il fait ajouter un appel à VirtualProtect avant l'appel à CreateThread:
//ajoute le droit d'exécution à la page de mémoire allouée
int oldProtect;
VirtualProtect( hCode, new IntPtr( code.Length ), PAGE_EXECUTE_READWRITE, out oldProtect );
//crée un thread qui va exécuter la fonction ASM
hThread = CreateThread( IntPtr.Zero,
...
//constante et déclaration de VirtualProtect
private const int PAGE_EXECUTE_READWRITE = 0x40;
[DllImport("Kernel32.dll")]
private static extern void VirtualProtect( IntPtr adress, IntPtr size, int newProtect, out int oldProtect );
10 déc. 2007 à 15:10
lorsque je lance l'execution de ce code sous "Visual Studio 2008", l'application bug en tentant d'obtenir la frequence du CPU;
Si quelqu'un a une idée sa serait sympa, Merci!
7 août 2005 à 11:05
20 juin 2004 à 18:50
Sinon pour le stackframe l'ASM est en encore nouveau pour moi alors que le stackframe soit nécessaire ou pas je sais pas trop.
20 juin 2004 à 16:02
20 juin 2004 à 16:00
20 juin 2004 à 15:53
Je m'en retourne au code natif, vraiment trop le bord... a mon gout ces codes interpretes.
Bossez bien.
20 juin 2004 à 15:43
Sinon je pense que la stackframe est utile si tu regardes tout l'espace que le code alloue sur la stack:
//Pile locale:
//
//UINT64 endCycle (ebp-68 et ebp-64)
//UINT64 startCycle (ebp-60 et ebp-56)
//UINT64 tickCurrent (ebp-52 et ebp-48)
//UINT64 tickEnd (ebp-44 et ebp-40)
//UINT64 tickStart (ebp-36 et ebp-32)
//DWORD lpQPCounterAddress (ebp-28)
//UINT64 testSpan (ebp-20 et ebp-16)
//UINT64 nCycles (ebp-12 et ebp-8)
20 juin 2004 à 15:19
Au fait, pourquoi tu fais une stackframe:
push ebp
mov ebp, esp
c'est utile ici ?
20 juin 2004 à 15:11
private static byte[] GetCpuFrequencyCode()
{
byte[] code = new byte[147];
//push ebp
code[ 0] = 0x55;
//mov ebp, esp
code[ 1] = 0x8B; code[ 2] = 0xEC;
//;alloue la pile locale
//sub esp, 64
...
20 juin 2004 à 12:27
http://www.cppfrance.com/code.aspx?ID=23837
va bon pour tous processeurs, teste jusqu'au bixeon 3.06 impec.
10 juin 2004 à 16:28
on a toujours des 0.001 mais bon ça doit etre normal
faudrais que je me documente un peu pour savoir comment fonctionne ce fameux ht
10 juin 2004 à 14:49
Xya
10 juin 2004 à 09:42
Il semble juste qu'il y ai un petit probleme avec les procs HyperThreading (et potentiellement multiproc donc), dans mon cas il donne souvent la valeur 0,001 sur le test de 1s (l'utilisation du test 1ms semble resoudre le probleme)
Comme solution alternative on peut utiliser le WMI et sa classe Win32_Processor (espace root/cimv2)
propriétés CurrentClockSpeed/MaxClockSpeed (unité = Mhz)