chez mon entreprise, nous testons souvent la performance de nos appareils USB et Firewire sous la souche CPU.
Il y a un code de test que nous exécutons qui charge la CPU, et il est souvent utilisé dans des tests informels vraiment simples pour voir ce qui arrive à la performance de notre appareil.
J'ai examiné le code pour cela, et c'est une boucle simple qui incrémente un compteur et effectue un calcul basé sur la nouvelle valeur, stockant ce résultat dans une autre variable.
Exécution d'une seule instance utilisera 1 / X de la CPU, où X est le nombre de cœurs.
Ainsi, par exemple, si nous sommes sur un PC à 8 cœurs et que nous voulons voir comment notre appareil est exécuté sous 50% d'utilisation de la CPU, nous pouvons ouvrir quatre cas de cela à la fois, etc. / p>
Je me demande:
Qu'est-ce qui décide combien de la CPU est utilisé? Cela vient-il de courir tout aussi vite que possible sur un seul fil dans une seule application filetée?
existe-t-il un moyen de limiter volontairement l'utilisation maximale de la CPU que votre programme peut utiliser? Je peux penser à des façons "négligées" (ajoutez des commandes de sommeil ou quelque chose), mais existe-t-il un moyen de limiter à dire que certains pourcentages spécifiés de la CPU disponible ou de quelque chose?
4 Réponses :
Vous avez essentiellement répondu à vos propres questions!
Le trait clé du code qui brûle beaucoup de CPU est qu'il ne fait jamais rien qui bloque (par exemple, attente d'E / S de réseau ou de fichier), et ne produit jamais volontairement son tranche de temps (par exemple, sommeil (), etc.) .
L'autre astuce est que le code doit faire quelque chose que le compilateur ne peut pas optimiser. Donc, probablement votre code de brûlage de la CPU sortira quelque chose basé sur le calcul de la boucle à la fin, ou est simplement compilé sans optimisation, de sorte que l'optimiseur n'est pas tentée de supprimer la boucle inutile. Puisque vous essayez de charger la CPU, il n'a aucun sens pour optimiser de toute façon.
Comme vous l'hypothèse, le code unique fileté correspondant à cette description saturera un noyau de la CPU à moins que le système d'exploitation ait plus de ces processus qu'il n'y a de nœuds pour les exécuter - alors il va rond-robin les planifie et l'utilisation de chaque volonté être une fraction de 100%.
Le problème n'est pas combien de temps la CPU passe au ralenti, mais plutôt combien de temps il faut pour votre code pour commencer à exécuter. Qui se soucie s'il est inactif ou faire des tâches bien prioritaires, tant que la latence est faible?
Votre problème est fondamentalement une conséquence de l'utilisation d'une référence synthétique, probablement dans la tentative d'obtenir des résultats reproductibles. Mais les repères synthétiques ont tendance à produire des résultats sans signification. La reproductibilité est donc discutée.
Regardez votre base de données de bugs, trouvez les plaintes de clients réels et utilisez le logiciel actuel et le matériel de test pour reproduire une situation qui réellement a fait une insatisfait. Développez le test de performance en parallèle avec des exigences de performance rigoureuses et significatives.
quotas de processeur sur Windows 7 et sur Linux .
Également sur QNX (IE BlackBerry Tablet OS) et < Un href = "http://www.lynuxworks.com/products/whitepapers/partition.php" rel = "nofollow"> lynuxworks
En cas de liens brisés, les articles sont nommés:
1. Dans les pilotes Firewire ou USB, la hiérarchisation joue un rôle clé car ils préempteront tout processus d'utilisation. 2. Bien sûr, il y a une manière générique, vous pouvez mettre en œuvre une tentative de boucle de rétroaction pour garder le temps de processeur un certain multiple de temps d'horloge.
1. La CPU tente de lancer le code aussi rapidement que possible. 2. Vous ne pouvez pas imposer des limites sans la manière «bâclée».
@Ben aw c'est tout à fait nouveau n'est-ce pas.
@David: Nouveau sur Windows, peut-être, mais les systèmes d'exploitation en temps réel ont une longue partitionnement de la CPU.