Dans un monde où la loi de Moore ralentit et où le matériel doit être de plus en plus co-conçu avec la pile logicielle système et les applications qui s’exécutent au-dessus, la matrice des combinaisons possibles de matériel s’élargit et s’approfondit. Ceci, plus que toute autre chose, montre que l’ère du calcul CPU à usage général touche à sa fin. Mais cela rend également le travail de choisir le bon matériel pour vos charges de travail spécifiques beaucoup plus difficile qu’il y a deux décennies ou même une décennie, lorsqu’un serveur X86 à usage général était le pari le plus sûr et que presque tout le monde l’a pris, et ainsi nous avons vu l’augmentation d’Intel dans le datacenter.

Ici, dans la deuxième décennie du 21e siècle, une capacité à granularité fine dimensionnée spécifiquement pour les charges de travail et facturée à l’heure, ainsi que la spécialisation du calcul sur un large éventail de CPU, GPU, FPGA et ASIC personnalisés pour l’exécution de charges de travail d’IA en particulier, est de plus en plus la règle. Le cloud public permet aux entreprises de tester quelle combinaison de capacités et de capacités leur convient avant de prendre des engagements importants en capital, c’est pourquoi nous assistons à la prolifération du calcul parmi les hyperscalers et les constructeurs de cloud. Le besoin de cette corne d’abondance de calcul pour gérer leurs propres charges de travail, et ils nous laissent le louer pour le nôtre. Et cela signifie que nous pouvons décharger les remords de l’acheteur et la matrice de calcul sur les hyperscalers qui sont également des constructeurs de cloud.

Rien ne le prouve plus que l’annonce par Google de ses nouveaux types d’instances Tau sur le Google Cloud.

Tau, que la plupart d’entre vous connaissent, est le symbole grec désignant le Nombre d’or, et comme Urs Hölzle, vice-président senior pour l’infrastructure technique chez Google, explique à La prochaine plate-forme, ce nom est destiné à indiquer que l’entreprise essaie d’obtenir l’équilibre de calcul, de mémoire et d’E/S « juste » pour des charges de travail évolutives spécifiques qui sont généralement exécutées chez le géant des moteurs de recherche et des applications et un concurrent certain dans la course au cloud public. Et pour être précis, le type de charge de travail dont nous parlons lorsque les ventes de Google « s’adaptent » est le moteur de recherche, le service Web et d’autres charges de travail de ce type.

Le Tau t2d est la première instance de ce qui sera une famille d’instances qui comprendra très probablement d’autres processeurs également réglés pour offrir un meilleur rapport qualité-prix sur des charges de travail très spécifiques. L’instance t2d est basée sur une implémentation à socket unique du processeur « Milan » Epyc 7003 d’AMD, qui dans ce cas a un maximum de 60 cœurs activés et peut être découpé en bits plus petits à partir de là. La puce spéciale Milan a 64 cœurs au total, donc quatre de ces cœurs sont utilisés pour gérer l’hyperviseur KVM et d’autres fonctions de stockage et de réseau. Pour autant que nous le sachions, Google ne dispose pas d’un DPU complet et développé en interne pour gérer ce travail – libérant ainsi tous les cœurs de l’exécution de l’hyperviseur et de ses E/S, comme le fait Amazon Web Services avec son « Nitro » développé en interne. DPU et son hyperviseur KVM modifié. Mais nous soupçonnons fortement que Google dispose de SmartNIC d’une manière ou d’une autre, qui peuvent décharger certaines fonctions de stockage et de réseau sans aller jusqu’au DPU. C’est pourquoi l’instance Tau t2d dispose de 60 cœurs sur 64 disponibles pour exécuter un travail réel ; sinon, jusqu’à 30 % des cœurs du processeur seraient brûlés sur l’hyperviseur, le stockage et la surcharge d’E/S.

Ni Google ni AMD ne sont précis sur les flux et les vitesses de cette puce spéciale Milan Epyc 7003, ce qui est ennuyeux mais attendu. Finalement, le t2d sera visible lorsqu’il sera disponible sur Google Cloud, alors pourquoi Google ne nous dira-t-il pas simplement comment il obtient des performances 56 % plus élevées et un rapport prix/performances 42 % meilleur avec l’instance Tau par rapport aux instances Arm Graviton2 sur Amazon Web Services et même une marge plus large par rapport aux instances Xeon SP « Cascade Lake » chez Microsoft Azure exécutant le test de référence d’entier SPECrate2017_int_base.

Voici les différences de performances que Google constate avec ses propres tests SPEC :

Et voici les différences prix/performances :

Comme vous pouvez le voir, Google a normalisé ces données pour l’instance Graviton2 m6g.8xlarge, qui possède 32 vCPU et 128 Go de mémoire et un lien de 12 Gb/sec vers le réseau ; il en coûte 1,232 $ par heure sur demande pour louer. L’instance Tau avec 32 vCPU et 128 Go de mémoire coûtera 1,352 $ de l’heure à louer à la demande, elle est donc un peu plus chère mais se rattrape avec des performances beaucoup plus élevées. La question est de savoir ce que Google paie à AMD pour obtenir cette partie Milan 64 cœurs pour l’instance t2d, et Hölzle n’allait pas le dire, mais il a fortement laissé entendre quand il a dit que le moyen d’améliorer le rapport qualité/prix était d’avoir « plus de vitesse et moins cher. »

L’instance Microsoft Azure illustrée ci-dessus, qui est identifié spécifiquement dans ce document, était l’instance D32s_v4, qui possède 32 processeurs virtuels et 128 Go de mémoire et 16 Gb/s de mise en réseau ; cela coûte 1,536 $ de l’heure.

L’instance Microsoft Azure D32s_v4 n’utilise pas le plus récent Xeon SP « Ice Lake », ce qui comblerait l’écart de performances quelque peu contre Milan et Graviton2 et éventuellement l’écart prix/performances mais peut-être pas en fonction de ce que Microsoft facture pour eux. Les instances Azure DS_v5 basées sur les SP Ice Lake Xeon sont en préversion publique depuis fin avril, et une instance D32s_v5 ​​avec 32 vCPU et 128 Go de mémoire ne coûte que 0,768 $ par heure et offrirait environ 20 % de performances entières brutes en plus par cœur et environ la moitié du prix. Lorsque nous faisons ce calcul, voici à quoi cela ressemble :

Il semble que Microsoft ait pu obtenir une remise d’enfer sur les SP d’Ice Lake Xeon, car nous soupçonnons fortement que Microsoft ne perd pas d’argent dans les instances. Et il semble qu’Ice Lake soit le gagnant prix/performances ici si les performances entières évoluent comme nous l’attendons de Cascade Lake à Ice Lake. Oui, c’est surprenant, et non, il n’est pas surprenant que Google n’ait pas effectué ses tests sur les instances Azure Ice Lake, qui ne sont pas encore généralement disponibles. Mais Google a sans aucun doute fait les mêmes calculs que nous. Toutes les victoires de référence sont éphémères. Tout ce que nous savons, c’est que la concurrence est bonne et que tous les fournisseurs de cloud se font concurrence pour le dollar.

Les instances AWS et Azure évoluent jusqu’à 48 et 64 vCPU, et la merveille est pourquoi Google n’a pas poussé les performances au maximum pour se montrer encore plus. Peut-être qu’un DPU pourrait être utile ici?

Incidemment, cette augmentation des performances de 56 % est due à le compilateur AMD Optimizing C/C++ (AOCC), qui est très adapté à l’architecture Epyc, tout comme les compilateurs d’Intel sont très adaptés à ses puces Xeon SP, et Google a été tout à fait honnête lorsqu’il a souligné qu’il n’avait obtenu qu’une augmentation des performances de 25% par rapport au Graviton2 lors de l’utilisation de l’open source GCC 11 compilateurs. Ainsi, la moitié du gain de performances provenait du compilateur et l’autre moitié de la puce, et le prix a baissé car l’instance Tau n’a pas de mémoire maximale et probablement d’autres fonctionnalités quelque peu diminuées. (Et donc Google peut payer moins pour la puce et en avoir pour son argent.)

Voici comment les trois VM différentes s’empilent sur le test de référence CoreMark, qui est un moyen populaire d’évaluer les performances du processeur, et pour une raison quelconque, Google ne parle ici que de prix/performances :

L’instance Tau t2d sera disponible au troisième trimestre en tant qu’instance sur Google Compute Engine (l’équivalent d’AWS EC2 et de Microsoft Azure VM) ainsi qu’un type de calcul sous-jacent sur Google Kubernetes Engine, le service de plate-forme de conteneur également disponible sur Google Cloud Cloud public.

Soit dit en passant, nous pouvons nous attendre à ce que Google ait des instances Tau basées sur d’autres processeurs.

« Pour nous, c’est la première instance de la famille Tau », explique Hölzle La prochaine plate-forme. « Nous allons continuer cette famille avec d’autres chipsets au fil du temps, espérons-le d’AMD, peut-être d’autres, et c’est vraiment pour créer une configuration qui fonctionne très bien pour ce type d’utilisateur. Je pense que c’est vraiment génial que nous soyons capables de produire cette lacune dans le monde X86 sans compromis et sans obliger les clients à recompiler et peut-être à re-licencier leur logiciel sur une architecture différente. Mais, vous savez, nous considérons Arm comme un concurrent sur la route également, et nous sommes ouverts à toute solution qui fonctionne pour le client. Cependant, je tiens à dire qu’AMD est clairement, comme le montrent nos chiffres, une longueur d’avance dans cette catégorie de charge de travail, même avec Arm Graviton2 là-dedans.

Toutes les cibles du centre de données se déplacent en permanence. C’est incroyable que n’importe qui frappe n’importe quoi. Vous n’avez qu’à chauffer la cible qui vient à votre tête, supposons-nous, et continuer à tirer.