Le test lui-même, le rapport et le reste du site sont en anglais pour le moment.
Pour les développeurs
Le build est lent. Est-ce le code ou le refroidissement ?
Les compilations et les suites de tests chargent chaque cœur pendant des minutes et punissent la latence mémoire. SystemCheck mesure les deux, de façon répétable, pour qu'un build lent soit imputé à la bonne cause.
Ce que le rapport vous dit
Trois chiffres, chacun avec sa lecture.
Tous cœurs soutenu
ops/s
Un worker par cœur logique pendant toute la durée du run. C'est le chiffre que voit un build parallèle, pas le boost monocœur affiché sur la boîte.
Latence mémoire
ns
L'aller-retour vers la mémoire et vers le cache. Les éditeurs de liens, les gestionnaires de paquets et tout ce qui manipule beaucoup de pointeurs tournent à cette vitesse.
Répétabilité
%
Lancez l'étape CPU deux fois et le rapport indique la dispersion. Un changement à l'intérieur de la dispersion n'est pas un changement, quoi qu'en dise le chronomètre du build.
Le diagnostic
La forme de la courbe, lue pour votre cas.
01Tenu
La machine n'est pas le problème. Regardez le graphe de build, le cache, et ce qui tourne d'autre.
02Une seule marche vers le bas
Une limite de puissance, le plus souvent la puissance soutenue d'un portable. Les longs builds tournent au niveau d'après la marche, pas d'avant.
03Erratique
Autre chose occupe les cœurs. Un indexeur, un client de synchronisation, un conteneur qui ne se met jamais au repos. Le chiffre de partage des cœurs du rapport nomme la famine quand il peut la voir.
Chaque classe est donnée avec un niveau de confiance explicite et le plancher de bruit propre à la mesure. Comment la forme est lue
Là où un navigateur s'arrête
Ce qu'il ne peut pas vous dire.
- Pas de fréquence par cœur : le navigateur voit le débit, pas la fréquence. La courbe montre l'effet d'un changement de fréquence sans nommer les mégahertz.
- Pas de détection de contention à l'intérieur d'un run : un programme qui partage discrètement les cœurs est indiscernable d'une machine plus lente. La comparaison avant/après est l'instrument pour cela.
- Nombre de cœurs tel que transmis : Firefox le plafonne, Safari le plafonne à huit, et le rapport dit quel nombre il a utilisé.
Quel run
Standard, 3 minutes.
Pour une base de référence répétable, le run standard, répété, donne une dispersion rapidement. Utilisez le run approfondi une fois pour trouver le niveau stabilisé sur un portable.
Les deux types sont gratuits. Le choix se fait sur l'écran de configuration.
Questions
Posées dans ces mots.
- Pourquoi mon build est-il plus lent que ce que le benchmark suggère ?
- Les temps de build reflètent le débit tous cœurs soutenu et la latence mémoire, pas le boost monocœur que la plupart des benchmarks mettent en avant. Le test rapporte les deux, et la courbe montre si la machine tient son niveau tous cœurs pendant la durée d'un build ou descend d'une marche après la fenêtre de boost.
- Puis-je l'utiliser pour comparer deux machines ?
- Oui, sur les chiffres mesurés : débit soutenu, déclin, bande passante et latence mémoire, temps par image. Lancez chaque machine deux fois pour que le rapport puisse indiquer la dispersion ; une différence à l'intérieur de la dispersion est du bruit.
- Docker ou une VM affectent-ils le résultat ?
- Tout ce qui utilise les cœurs pendant le run baisse le débit et augmente le bruit, et le rapport signale les workers affamés quand il peut les voir. Quittez ce que vous pouvez avant une base de référence, puis relancez avec la charge habituelle pour en mesurer le coût.