Pourquoi une CPU de serveur effectue-t-elle des tâches plus rapides qu'un CPU MacBook Pro avec le même score de référence?
Compte tenu des scores de CPUS et de Geekbench suivants:
Amazon EC2 Z1D.Large Instance: Intel Xeon Platinum 8151 4061 MHz (1 cœurs) Score à base unique: 1094, Note multicœur: 1300
MacBook Pro Ordinateur portable: Intel Core I5-8259U 2300 MHz (4 cœurs) Score à base unique: 1002, Note multicœur: 4104
Le Xeon est de 9,1% plus rapide dans le score de référence unique.
Cependant, lorsque je compile le code d'application JavaScript (unifamilial) sur les deux périphériques, le Xeon complète la tâche 60% plus rapide. Pourquoi? Le score de référence indique que le Xeon n'est que de 9% plus rapide.
Ils ont tous deux des lecteurs NVME, de sorte que cela ne devrait pas être le goulot d'étranglement. Je ne pense pas non plus avoir une question de Mac vs Linux OS, car Mac est basé sur Linux.
Est-ce parce que le Xeon est un processeur serveur/bureau? et courir à 100% de vitesse et de puissance, alors que le MacBook Pro CPU ne fonctionne pas à pleine puissance et doit attendre que l'Intel Turbo Boost augmente?
Compte tenu de la tâche que vous décrivez, la compilation d'un projet Bible et les CPU impliqués, je pense que je connais la source de la différence de performance. Je voulais répondre plus tôt, mais j'ai dû faire un peu de recherche pour confirmer mon hunch.
Tout d'abord, caractérisez la charge que vous mettez sur votre système.
Babel.js est écrit sous forme d'un compilateur unique à processeur unique, qui exploite principalement des E/S asynchrones pour le parallélisme (au moins rien que j'ai googlé indique qu'il utilise des threads de travailleurs). Comme il s'agit d'un compilateur qui compilait des fichiers de disque, une grande partie de son exécution implique d'attendre des données à partir de disque. Cela nous donne la charge de travail suivante:
Un seul fileté, de sorte que plusieurs cœurs ou hyperthreading n'ont aucun effet significatif sur la compilation avec une mise en garde:
Nœud.js utilise des threads de travailleurs pour gérer les E/S du disque, mais au-delà d'une ou quatre threads matériels, il n'y a pas d'avantages supplémentaires à plusieurs cœurs (voir: https://nodejs.org/en/docs/guides/dont -block-the-événement-boucle / )
La majeure partie du parallélisme a lieu au niveau des E/S. Babel essaiera de lire autant de fichiers parallèles que possible.
Les I5 et le Xeon sont tous deux équitablement comparables aux points 1 et 2. Regardons donc la manière dont la CPU peut gérer le point 3: Servir de la demande de lecture parallèle de Babel.
Voici la première grande différence entre les deux systèmes:
Le noyau I5 8259 a 16 voies PCI
Le Xeon 8151 a 48 voies PCI
Donc, clairement, le Xeon peut gérer des opérations d'E/S plus parallèles que la I5. Lorsqu'il y a plus d'E/S que le nombre de voies de transfert de mémoire disponibles, le système d'exploitation le gère de la même manière que lorsqu'il y a plus de tâches que le nombre de threads matériels disponibles: il les fait filmer et les obliger à tourner à tour de rôle.
Ensuite, je voulais savoir si NVME peut réellement utiliser plusieurs voies. C'est là que j'ai frappé un autre fait intéressant. La norme NVME permet à une carte d'utiliser jusqu'à 4 voies PCI (il existe physiquement de nombreuses connexions allouées), mais certaines cartes n'utilisent que 2 tandis que d'autres utilisent 4. Donc, toutes les cartes NVME sont donc créées égales. Cela seul vous donnera le double du nombre de fichiers Babel peut copier sur RAM en parallèle à presque doubler la bande passante.
Cela dépend également de la manière dont la fente NVME est connectée à la CPU. Le noyau i5 ayant seulement 16 voies PCI ne fera aucun doute de réserver au moins 8 d'entre eux pour le GPU. Vous laissez seulement 8 à partager parmi d'autres appareils. Cela signifie que parfois votre carte NVME devra partager la bande passante avec votre wifi ou votre autre matériel. Cela ralentit un peu plus.
Et votre NVME ne peut même pas être connectée directement aux voies PCI de votre CPU. Le MacBook peut réellement réserver toutes les 16 voies pour le GPU et se connecter à votre NVME via son pont Sud (qui peut avoir des voies pci supplémentaires). Je ne sais pas si le MacBook le fait, mais cela peut encore réduire les performances un peu plus.
En revanche, le grand nombre de voies que le Xeon a permis au concepteur de la carte mère beaucoup plus de liberté de créer une plate-forme d'E/S très rapide. De plus, le serveur AWS n'a normalement pas de GPU installé, de sorte qu'il n'a pas besoin de réserver des voies pour une utilisation GPU. Encore une fois, je ne connais personnellement l'architecture effective des serveurs AWS, mais il est possible de créer un qui surperformez un MacBook lors de la compilation de projets Babel.
Ainsi, à la fin des principaux facteurs permettant à l'instance EC2 de surperformer le MacBook sont les suivants:
Nombre de voies PCI directement soutenues par la CPU
Nombre de voies PCI soutenues par le lecteur NVME
Comment les voies NVME sont connectées à la CPU
Des facteurs supplémentaires pouvant contribuer incluent:
La vitesse du bus d'E/S (PCI2 vs PCI3, etc.)
La vitesse de la bélier
Nombre de DMA Chaînes disponibles (ceci nécessite uniquement une réponse longue, donc je l'ai sortit, mais le raisonnement est similaire aux voies PCI)
Ajout à l'excellente réponse de Mokubai:
Extensions d'instructions. Certaines extensions, telles que AVX-512, sont disponibles dans les processeurs de serveur (tels que le processeur SKX mentionné dans la question) mais non (ou seulement plus tard) dans les transformateurs de consommateurs. Le CPU Consumer Consumer Consumer de la question, par exemple, ne prend pas en charge AVX-512. Je ne pense pas que les compilateurs soient trop touchés par cela, mais si vous deviez exécuter certaines tâches numériques, y compris le calcul scientifique ou l'apprentissage automatique, cela pourrait causer une différence.
Interconnexions de base. Pas pertinent pour les tâches à une seule-filetage, mais lorsque plusieurs cœurs sont utilisés, le type d'interconnexion a une influence sur la "vitesse" avec laquelle les noyaux peuvent se parler. Bien que le processeur de consommateur utilise une interconnexion annulaire, le processeur de serveur est le premier à utiliser A Mesh Interconnect .
Intel Xeon Platinum 8151 Spécifications de Intel Corporation
Intel I5-8259U spécifiques de Intel Corporation
- Il semble que le Xeon ait 38,5 MB L3 cache
- Il apparaît que le Core Intel I5-8259U n'a que 6 Mo Intel® Smart Cache
Un cache de processeur est l'endroit où un processeur stocke des valeurs récemment écrites ou lues au lieu de s'appuyer sur la mémoire principale du système.
- Les caches sont conçues dans toutes sortes de formes et de tailles, mais ont plusieurs caractéristiques classiques qui les rendent faciles à exploiter. Les caches ont généralement une associativité complète et utilisent des sélecteurs bancaires. Caches associatives
- À l'intérieur d'un cache de processeur typique, une adresse physique (ou logique logique en fonction de la conception) doit être adaptée à un emplacement dans le cache. Ils fonctionnent généralement avec des unités de mémoire appelées lignes de cache, qui vont de la taille de petites lignes de 16 octets à des lignes plus typiques de 64 et même de 128 octets.
- Si deux sources de source (ou des lignes de cache) Carte sur la même adresse de cache, l'un d'entre eux doit être expulsé du cache.
- L'expulsion signifie que l'adresse de la source perdue doit être récupérée de la mémoire la prochaine fois qu'elle est utilisée. Dans un cache entièrement associé (également appelé mémoire ou cam) complètement associé), une adresse source peut planer n'importe où dans le cache. Cela donne un taux de frappe de cache élevé à mesure que des expulsions se produisent moins fréquemment.
- Ce type de cache est coûteux (en termes d'espace déminé) et de mettre en œuvre plus lentement. L'élevage de la latence d'un coup de cache ne vaut généralement pas les économies mineures de la cache Miss Pénalités que vous auriez autrement ... vous pouvez lire plus ici ==
DDR4 à un taux de bus plus élevé contribue également à augmenter la vitesse. Non trop mentionné que le Xeon a extensions de synchronisation transactionnelle alors que le I5 ne le fait pas.
Ils ne sont pas dans la même classe de processeur, mais espérons que les informations ci-dessus vous aide et que les liens d'Intel Corporation contribuent à la validité de mes réponses.
Vous venez d'inventer une plus grande référence - "Construire ce projet particulier". Et l'environnement de construction en Amazon est bien meilleur que votre Mac AT cette référence particulière.
Les CPU (et les périphériques de stockage et les ordinateurs dans son ensemble et les systèmes d'exploitation et les environnements de construction) ne sont pas égaux égaux. Les processeurs sont conçus pour s'adapter à différentes contraintes concernant la puissance, le refroidissement, l'espace, les coûts et les technologies disponibles. Tous sont tous les autres composants de votre configuration.
Je ne m'attendrais pas à beaucoup de différence en raison des différents OS (Linux, Mac OS ou même Windows) ou le système de stockage sous-jacent, car la construction de tâches est intensive de CPU et de mémoire et ne chargez pas une grande partie du système de fichiers ou le planificateur de processus. Là encore, je me trompe peut-être car la construction d'un projet JS peut être différente par rapport à C et Java projets que je connais.
Les outils de construction sous Linux et Mac OS peuvent différer considérablement dans la performance. Ils peuvent être eux-mêmes construits avec différents compilateurs, bibliothèques, options d'optimisation, etc. et celles-ci peuvent apporter toute la différence que vous voyez.
En plus des autres réponses, j'ajouterais que les instructions utilisées dans une référence donnée ne correspondent pas aux instructions utilisées dans votre compilateur. Fondamentalement, chaque processeur peut être plus rapide à certains types d'instructions, ou on peut être mieux performant que l'autre dans certains scénarios, par exemple, une défaillance de la prédiction des succursales.
Le code d'un n'est pas garanti d'être un prédicteur de la performance de l'autre code. C'est parce qu'ils font des choses différentes, de différentes manières.
Vous pouvez, par exemple, avoir un processeur de Core2 de modèle tardif tel que A Q9550, overclocké de 33% (assez faisable), et il peut correspondre ou dépasser un processeur 2nd Gen-Gen I5 inférieur pour de nombreuses tâches, malgré ces dernières étant plus récentes. .
Mais si vous avez une séquence de code qui implique beaucoup d'instructions de branchement avec un degré élevé de hasard, probablement le I5 surperformerait le noyau2 à plusieurs reprises en raison des mauvaises performances du processeur Core2 en cas de défaillance de la prévision de la succursale.
Ce type de chose se produit à toutes sortes de micro-niveaux, pour toutes sortes d'instructions et de types de traitement. C'est pourquoi un processeur pourrait être meilleur dans une référence en Cinebench (codage vidéo), mais s'aggrave dans une référence SunSpider (JavaScript).