IPC et fréquence d'horloge du processeur : comment comparer correctement les processeurs d'hébergement

IPC du processeur : instructions par cycle d'horloge

IPC du processeur signifie « Instructions par cycle », c'est-à-dire le nombre d'instructions par cycle d'horloge. Pour une plage de mesure définie, on divise généralement le nombre d'instructions machine exécutées par le nombre de cycles CPU comptés dans cette même plage. Un IPC de 2 signifie dans ce contexte une moyenne de deux instructions exécutées par cycle compté.

La valeur est un Caractéristique de la version, et non un indicateur fixe valable pour toutes les tâches d'un processeur. Un même système peut atteindre un IPC différent lors d'un calcul utilisant des données facilement accessibles et lors d'une requête de base de données, qui doit souvent attendre que les données soient chargées en mémoire principale. L'ensemble de données concerné et la partie du programme considérée influencent également le résultat.

Un cache conserve les données fréquemment utilisées à proximité du processeur. Si un cœur doit attendre des accès mémoire plus lents, les unités d'exécution peuvent rester inactives pendant un certain temps. De même, les dépendances entre les instructions et les sauts dans le déroulement du programme influencent la quantité de travail pouvant être exécutée simultanément. Un faible IPC justifie donc une analyse plus approfondie, mais ne constitue pas encore un diagnostic définitif.

De plus, une instruction machine ne correspond pas à une unité normalisée représentant une requête Web complète. Le compilateur, le jeu d'instructions et la vectorisation peuvent faire en sorte que des programmes différents nécessitent un nombre d'instructions variable pour effectuer la même tâche. Un IPC plus élevé ne garantit donc pas à lui seul un temps de réponse plus court ni un nombre plus élevé de requêtes par seconde.

Pour pouvoir comparer, il est essentiel de connaître l'application et la plage de mesure qui sous-tendent cette valeur. Un indice IPC fourni sans ces précisions ne permet pas de savoir si les systèmes effectuent réellement le même travail. Tu trouveras d'autres informations de base sur l'interaction entre la fréquence d'horloge, les cœurs et la hiérarchie de la mémoire dans l'article consacré à la Architecture CPU dans l'hébergement.

Comprendre la fréquence d'horloge du serveur et le mode « Boost »

La fréquence d'horloge indique le nombre de cycles effectués par un processeur par seconde. Un gigahertz, ou GHz, correspond à un milliard de cycles par seconde. Cette valeur ne précise pas en soi le nombre d'instructions qu'un programme exécute au cours de ces cycles, ni la quantité de travail utile qu'il accomplit ainsi.

Les fiches techniques mentionnent souvent une fréquence de base et une fréquence maximale. La fréquence de base sert de valeur de référence ; la fréquence maximale correspond à une fréquence plus élevée pouvant être atteinte dans des conditions appropriées. Ces deux indications ne remplacent en aucun cas l'observation de la fréquence réellement atteinte lors d'une utilisation concrète et avec la charge correspondante.

Prenons l'exemple de l'AMD EPYC 9655 : pour ce modèle, AMD indique 96 cœurs, 192 threads, une fréquence de base de 2,6 GHz et une fréquence boost maximale pouvant atteindre 4,5 GHz. Ces valeurs décrivent les caractéristiques techniques et les spécifications de fréquence du processeur. Elles ne correspondent ni à un IPC mesuré, ni à une preuve d'un débit d'hébergement spécifique.

Pour la série EPYC 9005, AMD définit le boost maximal c'est-à-dire la fréquence maximale qu'un seul cœur peut atteindre dans des conditions normales de fonctionnement du serveur. Les 4,5 GHz annoncés pour le 9655 ne garantissent donc pas que les 96 cœurs maintiendront tous cette fréquence en permanence. Les limites de puissance et de température influencent le comportement sous charge.

Pour une tâche ponctuelle de courte durée, une fréquence temporairement plus élevée peut être pertinente ; en revanche, en cas de charge parallèle prolongée, il est intéressant de connaître la puissance fournie par le système sur toute la durée d'exécution. Les autres modèles de la gamme présentent des fréquences et des nombres de cœurs différents. Une comparaison fondée uniquement sur la valeur la plus élevée en GHz ne tiendrait pas compte de ces différences ni de l'application concrète.

Cœurs, threads et processeurs virtuels

En termes simples, un processus est une instance de programme en cours d'exécution. Au sein de celui-ci, un ou plusieurs threads exécutent des instructions. Un cœur de processeur physique dispose du matériel nécessaire à l'exécution de ces tâches ; selon le processeur, les systèmes d'exploitation identifient un ou plusieurs threads logiques par cœur. Les threads logiques d'un même cœur partagent ainsi certaines parties de son matériel.

Une tâche comportant une partie fortement sérielle ne peut pas répartir cette partie à volonté sur un grand nombre de cœurs. Dans ce cas, ce qui importe, c'est la vitesse à laquelle le thread d'exécution effectue le travail proprement dit. En revanche, les requêtes Web indépendantes peuvent souvent être traitées en parallèle : les cœurs supplémentaires disponibles peuvent alors contribuer au débit global, à condition qu'aucune autre ressource ne constitue un goulot d'étranglement.

Le nombre de threads logiques ne doit pas être confondu avec le nombre de cœurs physiques indépendants. L'EPYC 9655, par exemple, dispose de 96 cœurs physiques et de 192 threads selon le fabricant. Ces 192 threads n'impliquent ni un doublement des performances par rapport à 96 threads, ni un débit spécifique pour un serveur web.

Dans le cas d'un serveur virtuel, le fournisseur met à la disposition du système d'exploitation invité vCPU Prêt. Un vCPU n'est pas automatiquement un cœur physique à usage exclusif : son affectation au matériel hôte peut varier selon l'offre, et le temps de calcul peut être partagé avec d'autres invités ou limité par des restrictions.

Question à poser avant de choisir, concernant l'engagement concret en matière de ressources : le temps CPU est-il garanti ou est-il partagé ? Existe-t-il des limites de performance permanentes et comment les vCPU sont-elles attribuées ? Un nombre élevé de vCPU n'est utile à une application parallèle que dans la mesure où il y a effectivement suffisamment de temps de calcul disponible ; pour une section sérielle, cela ne remplace pas une exécution rapide sur un thread.

Calculer conjointement l'IPC et la fréquence d'horloge

L'IPC et la fréquence d'horloge décrivent différents aspects des performances du processeur. Pour une plage de mesure correctement délimitée, leurs effets peuvent être approximativement combinés : instructions par seconde correspondent à l'IPC multiplié par le nombre effectif de cycles CPU par seconde. L'IPC se réfère ici aux instructions exécutées et aux cycles comptés dans le même intervalle.

Exemple de calcul à titre indicatif, pas de mesure : en supposant une valeur constante de 2,0 instructions par cycle et une fréquence de 3,0 GHz, on obtient, d'un point de vue théorique, 6,0 milliards d'instructions par seconde. Même un IPC de 1,5 à 4,0 GHz donne 6,0 milliards. Dans cet exemple, la fréquence d'horloge plus élevée compense donc l'IPC plus faible dans le calcul.

Cependant, le fait que les taux d'instructions soient identiques ne signifie pas que les deux systèmes traitent le même nombre de requêtes Web. Pour une même tâche, les programmes peuvent nécessiter un nombre d'instructions variable en fonction du compilateur, du jeu d'instructions et des instructions utilisées. Une instruction ne correspond donc pas à une quantité uniforme de travail effectué par l'application.

Le temps de réponse d'un site web ne peut pas non plus être directement déduit de ce produit. Un thread peut attendre des données provenant du support de stockage ou une réponse du réseau ; pendant ce temps, son taux d'instructions n'explique pas la totalité du temps écoulé. Dans le cas d'une machine virtuelle, il faut ajouter à cela le fait qu'elle ne dispose pas nécessairement de temps CPU à tout moment.

Pour pouvoir établir une comparaison, il faut donc pouvoir identifier le code et la période concernés. La formule permet de situer l'exécution active ; pour prendre une décision en matière d'hébergement, il faut en outre disposer des tâches terminées et de leurs temps de réponse pour un profil de requêtes comparable.

Classement de la fiche technique et des indicateurs clés

Une fiche technique fournit des indications utiles pour choisir un processeur d'hébergement. Cependant, ces informations répondent à des questions différentes : l'IPC décrit un comportement dans la plage de mesure concernée, tandis que les données de fréquence et le nombre de cœurs précisent les caractéristiques d'un modèle de processeur. Ce n'est qu'en les mettant en relation avec l'application qu'elles deviennent des critères de comparaison exploitables.

L'EPYC 9655 illustre bien comment ces informations s'articulent entre elles : selon AMD, ce modèle dispose de 96 cœurs et 192 threads, d'une fréquence de base de 2,6 GHz et d'une fréquence boost maximale pouvant atteindre 4,5 GHz. Ces 4,5 GHz ne correspondent ni à une fréquence garantie pour tous les cœurs en charge continue, ni à un débit d'hébergement mesuré.

Un classement basé sur la fréquence maximale en GHz ne tiendrait pas compte de la charge de travail traitée par les différents processeurs par cycle et par tâche. À l'inverse, un classement basé sur le nombre de cœurs ne tient pas compte du fait que toutes les applications ne sont pas capables de répartir leur charge de travail de manière aussi efficace en parallèle. Ces deux indicateurs constituent des points de départ, et non des évaluations définitives des performances.

Fais donc attention aux Variante de modèle et sur les ressources réellement exploitables. Pour obtenir une comparaison fiable, tu as également besoin d'un profil de charge adapté et de résultats obtenus avec un logiciel et une configuration comparables. Il ne faut pas confondre les spécifications des différents modèles avec une valeur maximale supposée pour l'ensemble de la gamme de produits.

Choisir le processeur d'hébergement en fonction du profil de charge

Le choix d'un processeur adapté à l'hébergement dépend des tâches que le serveur doit effectuer. Une tâche unique de longue durée impose des exigences différentes de celles liées à de nombreuses requêtes Web indépendantes. Le tableau ci-dessous traduit les profils de charge typiques en un indicateur clé et en une question à clarifier avant de faire son choix.

Dans le cas d'une tâche unique, les performances du thread qui l'exécute sont particulièrement importantes lorsqu'une grande partie du travail s'effectue en série. Un nombre plus élevé de cœurs ne réduit pas automatiquement la durée de cette partie. De même, un bref pic de performance ne suffit pas à prouver l'efficacité d'une tâche de longue durée : ce qui est déterminant, c'est sa durée d'exécution mesurée dans les conditions prévues.

En revanche, de nombreuses requêtes indépendantes peuvent être traitées en parallèle. Dans ce cas, outre les performances par thread, ce qui compte, c'est le nombre de ressources disponibles simultanément et l'évolution des temps de réponse lorsque la charge augmente. La somme des GHz nominaux ne remplace pas une comparaison des Débit total à parallélisme égal.

Dans le cas d'une base de données contenant un volume important de données de travail, les accès à la mémoire peuvent ralentir l'exécution si les données requises ne sont pas fournies efficacement à partir des caches. Un faible IPC peut justifier des analyses plus approfondies, mais ne prouve pas à lui seul l'existence d'un goulot d'étranglement au niveau de la mémoire. Vérifie donc également les requêtes, le volume de données et la configuration de la mémoire avant de remplacer le processeur.

Avec le VPS, il y a en plus la engagement de ressources Point essentiel : un vCPU n'est pas automatiquement un cœur physique exclusif. Il faut se renseigner sur l'affectation, les limites éventuelles du processeur et le partage avec d'autres invités. Ce n'est qu'avec ces informations qu'il est possible de comparer de manière pertinente les résultats d'un test d'application avec une offre sur un serveur dédié.

Planifier des tests d'application comparables

Une comparaison pertinente commence par votre application, et non par une simple valeur de CPU prise isolément. Définissez la même version logicielle, le même ensemble de données et la même configuration pour les deux offres d'hébergement. SPEC considère que votre propre application, exécutée sur votre propre infrastructure, constitue la référence idéale pour le choix d'un produit.

Définis ensuite un Profil de la demande, qui reflète au mieux l'utilisation future : par exemple, quelles pages ou quels points de terminaison API sont appelés et combien de requêtes arrivent simultanément. Veille à ce que le parallélisme et les limites de ressources restent comparables d'un passage à l'autre. Si une offre impose d'autres limites, documente-les explicitement, au lieu d'attribuer la différence uniquement au processeur.

Prévoyez une phase de préchauffage afin, par exemple, que l'application soit lancée et que les caches puissent se remplir. Ensuite, plusieurs cycles suffisamment longs permettront de distinguer les fluctuations à court terme d'une différence récurrente. Notez également si d'autres tâches s'exécutaient sur les systèmes pendant la mesure.

En plus du débit, enregistrez la Répartition des temps de réponse et les erreurs. Une moyenne plus élevée de requêtes traitées par seconde n'est guère utile en soi si certaines requêtes restent en attente très longtemps ou échouent fréquemment. Comparez donc également les centiles élevés du temps de réponse à un niveau de parallélisme identique.

Les résultats SPEC-CPU2017 publiés peuvent également servir de référence. SPECspeed mesure le temps nécessaire à l'exécution des tâches, tandis que SPECrate mesure le débit ; ces deux indicateurs ne sont pas directement interchangeables. Comparez les résultats d'un même indicateur et tenez compte de la configuration du système et des logiciels. La suite CPU ne reflète pas le réseau et les E/S d'un service d'hébergement complet.

Vérifier l'IPC et la fréquence pendant le fonctionnement

Pour créer ton propre environnement de test sous Linux, tu peux utiliser perf pour enregistrer les instructions et les cycles terminés d'un programme existant et testé. Dans l'exemple suivant, testprogramm Un espace réservé : remplace-le par ton programme de test et, le cas échéant, par ses arguments. Cette commande est une suggestion de mesure, et non un test déjà exécuté.

perf stat -e '{instructions,cycles}' -- testprogramm

Les accolades regroupent les événements en une seule Groupe de compteurs ensemble. Elles doivent être comptabilisées simultanément, ce qui permet de réduire les erreurs liées au multiplexage différé. Divisez le nombre d'instructions comptées par le nombre de cycles comptés pour obtenir l'IPC pour cette plage de mesure ; perf peut également afficher directement cette valeur.

La disponibilité et l'accessibilité des événements dépendent du matériel, du noyau, des autorisations et, le cas échéant, de l'environnement de virtualisation. Un groupe d'événements indisponible ou ne pouvant pas être comptabilisé ne permet pas d'établir une comparaison fiable. Ne modifiez pas les paramètres de sécurité uniquement pour les besoins de cet exemple.

Même l'affichage d'une fréquence doit être replacé dans son contexte : scaling_cur_freq selon la documentation du noyau, correspond dans de nombreux cas à la dernière valeur demandée par le pilote et pas nécessairement à la fréquence matérielle effectivement atteinte. Cette valeur, qui n'est pas disponible partout, cpuinfo_cur_freq doit en revanche afficher la fréquence actuelle détectée par le matériel. Pour en savoir plus sur Régulateur de CPU sur les serveurs d'hébergement explique le fonctionnement du réglage de la fréquence.

Un IPC faible constitue un indice justifiant des analyses plus approfondies, mais ne constitue pas un diagnostic définitif. Les accès à la mémoire peuvent ralentir l'exécution ; il convient également de vérifier quelle partie du programme a été mesurée et s'il existe d'autres facteurs influents. Comparez donc la valeur du compteur avec le comportement de l'application et ses accès aux données.

Identifier les goulots d'étranglement et décider d'une mise à niveau

Commencez par un symptôme concret : les requêtes deviennent-elles lentes en cas de charge élevée, le taux d'erreurs augmente-t-il ou une tâche spécifique prend-elle trop de temps ? Notez à quel moment le problème survient et quelles tâches sont en cours d'exécution au même moment. Ce n'est qu'alors qu'il sera possible de vérifier si une puissance de calcul plus importante peut réellement réduire ce temps de latence.

Vérifie d'abord l'espace disponible et utilisé temps CPU. Une tâche nécessitant en permanence une forte puissance de calcul peut bénéficier d'une exécution plus rapide ou d'un parallélisme plus exploitable. Cependant, une charge élevée ne suffit pas à elle seule à expliquer quel code est à l'origine de ce phénomène, ni si le temps de réponse provient principalement de là. Comparez donc ce constat avec le débit et les temps de réponse observés lors de la même phase de charge.

Examinez ensuite les besoins en mémoire et les accès aux données. Si une base de données doit fréquemment accéder à des données situées en dehors du cache du processeur, elle peut être en attente de mémoire ; un faible IPC peut être un indice, mais ne prouve pas la cause. Une mémoire vive insuffisante, des accès aux périphériques de stockage ou des services externes lents peuvent également contribuer au retard observé.

Avec un VPS, la engagement de ressources Concernant le diagnostic : renseignez-vous sur l'affectation des vCPU, les limites éventuelles du processeur et le partage avec d'autres machines virtuelles. Un serveur dédié offre une autre répartition des ressources physiques, mais là encore, ce sont l'application, la configuration et le profil de charge qui déterminent le résultat. Comparez si possible les deux offres à l'aide du même test d'application.

Envisagez une mise à niveau du processeur si les mesures indiquent un goulot d'étranglement au niveau du processeur et si le nouveau forfait offre effectivement le temps de calcul nécessaire. Si le retard provient principalement de la mémoire, du support de données ou d'un service externe, il est plus judicieux de concentrer l'analyse sur ces éléments. Consigne l'état initial afin de pouvoir évaluer ultérieurement les changements de manière comparable.

Ne considérez pas les valeurs maximales de boost comme une fréquence de fonctionnement continue garantie pour tous les cœurs, ni une valeur d'IPC comme une caractéristique universelle du processeur. De même, un seul chiffre de charge de travail ne suffit pas pour établir un diagnostic complet des goulots d'étranglement. La décision doit être prise en fonction de la tâche concrète et des ressources réellement disponibles, et non sur la base d’un seul indicateur de pointe.