La bête doit compiler vite (que ce soit occasionnel ou non, intensif ou non …). Je virtualise aussi beaucoup.
La virtualisation chez moi consomme pas mal de RAM (je suis sous Linux et je virtualise avec qemu/KVM en utilisant VT-x) et de CPU (les vCPU alloués à la VM). Si tu fais tourner plusieurs VM en même temps, alors là un nombre minimum de cores physiques me semble adéquat. L’expérience empirique semble aussi mettre en avant les avantages d’avoir beaucoup de cache CPU (L1/L2/L3) pour ce genre de workload. Par ailleurs, les CPU entreprise-grade (gamme Epyc chez AMD) qui sont vendus avec la promesse de soutenir des environnements virtualisés intenses sont dotés de beaucoup de core et de beaucoup de cache CPU.
Avoir un CPU avec pas mal de cores (physiques) peut s’avérer intéressant si les compilations de tes projets sont aisément parallélisables (avec make -j par exemple). Là encore, la RAM est intéressante car les compilateurs modernes savent utiliser des caches pour améliorer les temps de compilation, ce qui nécessite de la mémoire vive.
En parlant de RAM, c’est bien d’en avoir vraiment beaucoup pour les VM et les activités relatives au développement.
Linux semble très bien se débrouiller pour utiliser la RAM à profit quand il y en a « de trop » ; il peut mettre en cache pas mal de choses, dont des fichiers entiers. Cela est très pratique dans les recherches de texte dans le code à travers tout un projet, ce qui est une tâche assez courante dans le développement. (je pense aux cas où l’on fait un petit coup de grep -Hr par exemple). Dans ce cas précis, un disque rapide t’aide aussi pour améliorer tes conditions de développement : je pense à un SSD NVMe au format M.2 dont le support s’est généralisé sur les CM d’aujourd’hui. Dans ce cas précis, la faible latence de NVMe est l’atout principal, par rapport à un SSD en SATA.
Cependant, si tu fais beaucoup de développement en impliquant des bases de données relationnelles, attentions aux écritures car la durée de vie des SSD est fortement affectée par ces dernières ! (les propriétés ACID des DB impliquent des opérations assez lourdes en écriture pour le disque). Perso, je fais pas mal de dév intensif utilisant des DB relationnelles, j’ai donc opté pour un SSD avec des garanties de durabilité face aux écritures particulièrement hautes, mais évidemment le prix au GB augmente très vite.
Selon ta façon de ta façon de bosser, tu voudras donc privilégier un aspect pour rentrer dans le budget que tu t’es fixé. (quel est-il, d’ailleurs ?)
