- Pour décider s’il fallait remplacer les ordinateurs portables des développeurs par des M3, incident.io s’est appuyé non pas sur le ressenti, mais sur les temps de build Go, et a collecté des données réelles sur les boucles de feedback du développement local
- Comme les hot reloaders Go existants ne permettaient pas d’obtenir les valeurs nécessaires, l’entreprise a créé son propre outil et a chargé dans son data warehouse des événements de build tels que la plateforme, la mémoire, l’état d’alimentation, les étapes du build, le fichier déclencheur et la durée totale
- Sur environ 25 000 builds, après avoir écarté les builds échoués, annulés et ceux effectués sur batterie, 12 525 builds réussis ont été analysés ; une différence statistique a confirmé que les builds sur secteur étaient plus rapides que ceux sur batterie
- Au final, les utilisateurs de M1 attendaient souvent près de 2 minutes la fin d’un build, tandis que le M2 apportait une nette amélioration par rapport au M1, et le M3 une amélioration incrémentale par rapport au M2
- Sur le temps de build total, l’écart lié à la mémoire n’était pas évident, mais sur le temps du linker, les machines de 32 à 36 Go étaient avantagées ; incident.io a donc décidé de remplacer les machines M1 par des M3 Pro de base avec 36 Go
Le critère de décision de l’upgrade : la boucle de feedback des développeurs
- Tous les développeurs d’incident.io utilisent un MacBook pour leur travail de développement
- Après la présentation par Apple des MacBook Pro M3 en octobre 2023, le CTO Pete a indiqué qu’ils seraient remplacés si la valeur de l’upgrade était démontrée par les données
- Pour décider s’il fallait passer au M3, l’équipe a préparé trois éléments
- Un hot reloader Go personnalisé
- La collecte de télémétrie de build sur les ordinateurs portables des développeurs
- Une analyse des données utilisant les derniers modèles d’OpenAI et l’interpréteur de code
- Il est difficile de quantifier directement la productivité des développeurs, mais incident.io considère qu’une boucle de feedback rapide est importante pour leur efficacité
- En développement local, les boucles de feedback fréquemment répétées sont les suivantes
- Compilation du monolithe Go
- Génération de code, notamment pour les clients API et les interfaces
- Hot reload du frontend et de l’app mobile
- Les développeurs d’incident.io exécutent localement tout l’environnement incident.io sur leur ordinateur portable, et conservent une boucle de feedback de moins de 30 secondes entre une modification du code et son exécution
- L’application Go approchant les 1 million de lignes de code, la compilation Go, fréquente et coûteuse, a été choisie comme indicateur de comparaison des performances des MacBook
Méthode de collecte de la télémétrie de build
- Depuis la création initiale du dépôt GitHub, incident.io utilisait codegangsta/gin comme hot reloader Go
- D’autres hot reloaders ont été évalués, mais aucun outil ne fournissait la télémétrie nécessaire à l’analyse des temps de build
- Les données que l’équipe voulait collecter pour chaque build étaient les suivantes
- Au niveau système : plateforme M1/M2/M3, mémoire totale, etc.
- Indicateurs runtime : OS, utilisation mémoire, source d’alimentation, niveau de batterie, etc.
- Télémétrie de build : durée totale, étapes du build Go, fichier ayant déclenché le build, etc.
- Faute d’alternative prête à l’emploi, l’équipe a créé son propre outil à partir de
main.go, en exécutant et en parsant la sortie de plusieurs binaires du Mac pour extraire les valeurs nécessairesmemory_pressuredockersysctlpmset
- Le code correspondant est publié sous forme de Gist
- Après avoir créé les collecteurs système et runtime, l’équipe a encapsulé la commande de build Go afin de collecter les durées par étape, comme le linking et la compilation, ainsi que le fichier déclencheur du build
- Le hot reloader final s’exécute dans la cible
make runexistante, et ce changement était invisible pour l’équipe d’ingénierie - À la fin de chaque build, un événement de télémétrie est envoyé à un endpoint HTTP, puis chargé dans le data warehouse via un récepteur de webhooks Fivetran
Flux d’analyse avec OpenAI Assistant
- Après avoir accumulé un jeu de données suffisant pendant quelques semaines, l’équipe a exporté au format CSV le résultat de
select * except(payload) from developer__build_eventsdepuis BigQuery - Elle a fourni aux OpenAI Assistants un prompt expliquant l’objectif, ainsi que le fichier CSV
- Le modèle expérimental
gpt-4-1106-previewet l’interpréteur de code ont été activés pour l’analyse des données - Les temps de build varient fortement même sur un même système, et l’influence du cache du compilateur Go est importante, si bien qu’une comparaison des seules moyennes par plateforme ne serait pas équitable
- Un M3 Max sans cache peut être plus lent qu’un vieux MacBook Intel avec cache
- L’analyse ne s’est pas limitée à comparer des moyennes simples : elle a consisté à clarifier les conditions de build et à séparer les données par plateforme, mémoire et état d’alimentation
Nettoyage des données et conditions de comparaison équitables
- Le jeu de données complet contenait environ 25 000 builds, collectés à différentes heures de la journée, sur divers ordinateurs portables et dans différentes conditions
- Pour comparer les plateformes de manière équitable, les builds suivants ont été exclus
- Builds échoués ou annulés : comme le travail n’a pas été terminé, ils ne conviennent pas à une comparaison des vitesses de build
- Builds sur batterie : OS X peut limiter les performances pour préserver l’autonomie
- Après exclusion des builds échoués, le nombre de builds réussis s’élevait à 12 525
- La différence de performances de build entre l’alimentation secteur et la batterie a été comparée principalement sur les M1 Pro et M2 Max
- Les tests statistiques ont montré que le temps moyen des builds sur secteur était plus faible, avec une p-value d’environ 0,0014
- La suite de l’analyse n’a donc utilisé que les builds réussis sur secteur
Pourquoi les temps de build Go fluctuent
- Le monolithe Go d’incident.io fait l’objet d’un suivi continu des performances de build, et la suppression ou l’optimisation du processus de build lui-même est aussi importante que l’achat de matériel
- Un projet Go est composé de plusieurs packages, et le compilateur Go utilise le cache pour ne recompiler que les packages qu’il considère comme modifiés
- L’application incident.io est conçue avec un large graphe de dépendances et peu de modules fondamentaux, afin que la plupart des changements n’entraînent pas une recompilation de tout le graphe
- Les types de build se divisent grossièrement en quatre catégories
- Terminé immédiatement, moins de 3 secondes : changement sans rapport avec le compilateur Go, pour lequel le binaire en cache peut être utilisé
- Build rapide, moins de 30 secondes : modification d’un seul package avec peu de dépendances, réutilisant la majeure partie du cache, le temps étant surtout passé au linking
- Build intermédiaire, 30 secondes à 1 minute : modification d’un package fonctionnel ayant quelques dépendances vers des packages de niveau inférieur, mais dont la majorité reste réutilisable
- Build lent, plus de 1 minute : ajout d’un type au package fondamental
domain, ce qui oblige à recompiler tous les packages de l’application
- La comparaison des plateformes doit tenir compte de ces différences de nature des builds ; mélanger tous les builds revient à comparer des pommes et des oranges
Résultats de comparaison entre M1, M2 et M3
- En ne considérant que les builds réussis sur secteur, l’équipe a d’abord comparé le M1 Pro et le M2 Max
- Le M2 Max devançait nettement le M1 Pro en vitesse de build, mais les deux machines différaient non seulement par le chipset, mais aussi par la configuration mémoire
- La répartition des événements de builds réussis par plateforme et mémoire était la suivante
- Apple M1 Pro 16 Go : 5 235 builds
- Apple M2 Pro 16 Go : 1 927 builds
- Apple M2 Max 32 Go : 3 842 builds
- Apple M3 Pro 18 Go : 321 builds
- Apple M3 Pro 36 Go : 899 builds
- Apple M3 Max 36 Go : 301 builds
- La comparaison entre M1 Pro 16 Go et M2 Max 32 Go n’était pas totalement équitable en raison de la différence de mémoire
- En comparant le M2 Pro 16 Go et le M2 Max 32 Go, l’effet des 32 Go de mémoire sur le temps de build total semblait faible
- Le M2 Pro et le M2 Max sont globalement la même puce, le Max ajoutant 2 cœurs à haute efficacité énergétique
- Ces cœurs atteignant environ 1/5 des performances des cœurs de performance, leur contribution à la compilation de programmes Go a été jugée limitée
- Pour évaluer le M3, trois machines ont été achetées
- M3 Pro 12 cœurs, 6 cœurs de performance + 6 cœurs à haute efficacité énergétique, 18 Go
- M3 Pro 12 cœurs, 6 cœurs de performance + 6 cœurs à haute efficacité énergétique, 36 Go
- M3 Max 14 cœurs, 10 cœurs de performance + 4 cœurs à haute efficacité énergétique, 36 Go
- Les graphiques de temps de build des M3 Pro 18 Go et 36 Go étaient similaires, mais les données M3 étaient moins nombreuses que pour les autres plateformes
- En excluant les builds très rapides de moins de 3 secondes et en comparant les M3 Pro et M3 Max, le M3 Max ne montrait pas d’amélioration suffisamment nette pour justifier un prix supérieur de 60 % par rapport au M3 Pro de base
- La conclusion générale est la suivante
- Les utilisateurs de portables M1 attendent souvent près de 2 minutes la fin d’un build
- Le M2 est une grosse mise à niveau par rapport au M1
- Le M3 est une amélioration incrémentale par rapport au M2
- Les utilisateurs de M1 passent au M3 Pro de base
- Les utilisateurs de M2 n’ont pas besoin d’upgrade
La mémoire se voit plus clairement dans le temps du linker
- Dans la comparaison du temps de build total, le passage de 16–18 Go à 32–36 Go ne montrait pas d’amélioration fortement significative
- L’effet de la mémoire apparaissant moins nettement que prévu dans les graphiques, l’équipe a analysé séparément le temps du linker parmi les étapes de build
- Les événements de télémétrie incluaient les durées des étapes de linking et de compilation, et une colonne
linker_timea été créée à partir debuild_stages.link.duration_secondspour l’analyse - En comparant
linker_timepar configuration plateforme/mémoire, un autre motif est apparu- Les machines M1, M2 et M3 dotées de 32 à 36 Go de mémoire terminaient presque toujours le linking en moins de 20 secondes
- Sur les machines dotées de 18 Go de mémoire ou moins, le linking dépassait fréquemment 20 secondes
- Même si l’ajout de mémoire est moins évident sur le temps de build total, il s’avère utile lors de l’étape du linker
- La possibilité de retirer Docker des machines de développement est également à l’étude, ce qui conduit à l’interprétation suivante : sur les machines à faible mémoire, libérer de la mémoire système disponible sans Docker pourrait améliorer le temps de linking
- En développement d’apps mobiles, les simulateurs utilisent beaucoup de mémoire système ; l’augmentation de la mémoire est donc aussi considérée comme un coût raisonnable pour préparer l’avenir
Décision finale et effets secondaires
- incident.io a décidé de faire passer ses machines M1 à des M3 Pro de base avec 36 Go de mémoire
- Les machines M2 semblant déjà offrir des performances suffisantes, elles ne seront pas mises à niveau pour le moment
- Au-delà de la décision d’achat des ordinateurs portables, l’équipe a également mieux compris son environnement et ses outils de développement
- Les résultats obtenus par l’équipe sont les suivants
- Identification du temps de build Go comme bon benchmark pour mesurer les performances des machines de développeurs
- Création d’un hot reloader Go maison qui suit les métriques nécessaires, avec d’autres améliorations d’utilisabilité à la clé
- Meilleure compréhension des facteurs qui accélèrent ou ralentissent les builds Go
- Confirmation qu’OpenAI Assistants peut traiter des problèmes similaires d’analyse de données
- Quantification des améliorations des gammes de puces Apple du point de vue des développeurs Go
- La mémoire est importante, mais elle se manifeste plus clairement dans le temps du linker que dans le temps de build total
1 commentaires
Avis sur Hacker News
Excellent article, et j’aime la variété des méthodes utilisées pour collecter et analyser les données, mais il aurait probablement été beaucoup plus simple et plus précis de placer les ordinateurs portables côte à côte et de lancer des builds chronométrés dans le même scénario.
On aurait pu comparer quelques cas — build complet, build incrémental des changements récents, build incrémental nécessitant de rebuilder un module précis — ou encore écrire en une journée un script qui applique dans l’ordre les 100 derniers commits Git et mesure le temps des builds incrémentaux.
Agréger des statistiques à l’échelle de toute l’entreprise peut introduire beaucoup de biais. Par exemple, les nouveaux employés sont plus susceptibles d’avoir un M3 et les employés plus anciens un M1 ; les nouveaux font peut-être davantage de petits changements, tandis que les plus expérimentés touchent des zones plus profondes ou plus complexes du code, ce qui peut allonger les temps de build.
L’analyse en elle-même est donc intéressante, mais compte tenu des biais inhérents à l’échantillon, je pense qu’il aurait fallu commencer par une approche simple consistant à benchmarker les commits récents sur chaque ordinateur, avant de construire une architecture de collecte de données à l’échelle de l’entreprise.
Si j’ai collecté ces données, c’était en partie pour comparer les machines entre elles, mais aussi pour accumuler un historique des temps de build des développeurs et mesurer en continu les performances de build afin de détecter les régressions.
Quand on constate que les temps de build augmentent, on ajuste régulièrement la structure de la base de code pour rendre les builds plus rapides.
Un M3 peut rendre les builds 30 % plus rapides qu’un M1, mais les builds réseau sont 15 fois plus rapides. On peut donc se demander s’il n’aurait pas mieux valu investir dans les builds réseau plutôt que de fournir des M3 aux développeurs.
Un test t a été appliqué à des données qui n’avaient pas été échantillonnées indépendamment : plusieurs points de données provenaient de personnes différentes, et les tâches variaient selon les personnes, ce qui peut changer les besoins en calcul et introduire des facteurs de confusion. Cela viole les hypothèses de base du test t, mais l’interpréteur de code ne l’a pas signalé.
À la place, on aurait pu utiliser un modèle linéaire à effets mixtes en intégrant des facteurs comme le propriétaire de l’ordinateur portable ou l’ancienneté comme effets aléatoires.
Cela dit, les données elles-mêmes sont intéressantes, en particulier la partie sur la RAM. Le cache est puissant, et disposer de beaucoup de RAM apporte plus de bénéfices que les gens ne l’imaginent. Sur un MacBook avec plus de RAM que nécessaire, la majeure partie de la RAM restante est généralement remplie par du cache.
En collectant cela pendant environ une semaine, on obtiendrait une tranche représentative de la charge de travail réelle, on pourrait rejouer ces builds sur chaque gamme de matériel, puis les réutiliser plus tard avec de nouvelles machines.
En tant que scientifique, je trouve intéressante la manière dont les programmeurs informatiques manipulent les données.
Ils ont produit de jolis graphiques, automatisé très rapidement l’analyse avec ChatGPT, et ChatGPT a sorti un test t assez plausible.
Mais il y avait des variations selon la mémoire et le type de puce, sans qu’ils pensent à une régression linéaire, et ils ont produit des histogrammes difficiles à comparer. Ils auraient pu compléter avec de simples moyennes et barres d’erreur, ou utiliser des fonctions de répartition cumulée (CDF) pour voir plus facilement les chevauchements ou les décalages.
En pratique, on manipule les données de la manière dont les outils les présentent, ce qui rejoint assez bien les produits d’analyse, de profiling de performances et d’observabilité.
S’attendre à ce qu’un ingénieur logiciel moyen connaisse les CDF, c’est un peu comme s’attendre à ce qu’il connaisse les quaternions en 3D ou les bases de l’écriture de shaders.
Sinon, une régression quantile aurait aussi été possible. Si l’hypothèse est M3 > M2 > M1, le célèbre test de Jonckheere–Terpstra pour des médianes ordonnées aurait peut-être été parfaitement adapté à ce type d’analyse exploratoire.
Pour un exemple, voir le dernier graphique de cette page : https://ggplot2.tidyverse.org/reference/stat_ecdf.html
Analyse solide, mais je voudrais donner un avertissement tiré de mon expérience personnelle
Dans une entreprise logicielle de taille moyenne d’environ 2 000 employés, nous avons essayé d’améliorer la productivité des développeurs et avons exploré l’idée de déplacer la stack de développement vers des instances AWS plutôt que d’acheter de nouveaux ordinateurs portables
Au final, c’est devenu un projet de plusieurs années mobilisant environ 4 développeurs à temps plein, et avec le recul le rapport coût/bénéfice n’y était pas. Reproduire dans le cloud une expérience de développement entièrement locale reste encore beaucoup trop difficile
Donc, à mon avis, il vaut mieux mettre à niveau les portables
Le code est sur le portable, mais il est synchronisé en temps réel avec les services distants sans build Docker ni déploiement K8s, ce qui donne vraiment l’impression d’être en local
En particulier, on peut lancer immédiatement des tests d’intégration et au-delà pendant qu’on code, ce qui évite la boucle commit-push-pray
Pour cela, nous utilisons Garden (https://docs.garden.io). Que l’on utilise Garden ou non, avec les bons outils, exploiter la puissance du cloud dans la boucle de développement interne peut être assez excellent
Un article où j’ai davantage détaillé l’expérience : https://thenewstack.io/one-year-of-remote-kubernetes-develop...
Cela a aussi rendu possibles plusieurs choses qui ne l’étaient pas dans la version uniquement locale. Par exemple, quand on passe d’une branche à l’autre, changer de machine plutôt que modifier les fichiers locaux réduit nettement le délai de changement de contexte
Quand il faut lancer plus de 200 composants pour faire quelque chose, il devient difficile de travailler même sur une seule partie qui n’interagit qu’avec quelques-uns d’entre eux
À une époque où l’on dispose de serveurs à 128 cœurs et plus, 256 threads et plus, je penche de nouveau vers l’idée que, pour la plupart des logiciels, le monolithe est préférable
C’est une pure perte d’argent et de temps. On se rend compte que hooker tous les appels système avec du bloatware vendeur est mauvais pour les chaînes d’outils Unix qui lancent quantité de sous-processus
Dans les grandes entreprises tech comme Google ou Meta, l’environnement de développement de la majorité des ingénieurs logiciel est dans le cloud
L’expérience développeur y est bien meilleure qu’en local
Pour le développement iOS, en tenant aussi compte du coût, voici la conclusion de mon enquête personnelle
Le M2 Pro est bon, mais l’amélioration par rapport au M1 Pro 10 cœurs n’est pas énorme. Selon XcodeBenchmark, c’est 136 s contre 120 s : https://github.com/devMEremenko/XcodeBenchmark
Le M3 Pro donne l’impression d’avoir été affaibli pour le différencier du M3 Max, et avec seulement 6 cœurs de performance, il est en pratique proche du M2 Pro
Au final, j’ai acheté un M1 Pro 10 cœurs légèrement utilisé et j’en suis très satisfait. Pour moins de la moitié du prix d’un M3 Pro de base, j’ai obtenu 85 % des performances, en tenant aussi compte du fait qu’en général il faut que le CPU soit au moins 33 à 50 % plus rapide pour vraiment sentir la différence
Il est bien plus efficace que le M2 Pro tout en étant légèrement plus performant. C’est ce que je recherche dans un portable, et la bande passante mémoire ne me sert pas vraiment
Je n’ai pas constaté un écart aussi important que celui montré dans cet article. Cela peut dépendre du langage ou du projet, mais en benchmarkant côte à côte les mêmes commandes de compilation, je n’ai pas vu une différence aussi grande
Comme la chaîne d’outils de compilation est différente, ce n’est pas surprenant ; on peut aussi voir dans la toolchain Go que certaines caractéristiques jouent différemment selon les étapes du build, par exemple lorsque la mémoire supplémentaire aide les performances du linker
J’ai aussi vu plusieurs réactions disant que les performances du M3 semblaient étrangement bridées ; j’espère que cela ne se poursuivra pas sur les modèles après le M4
Le 120 Hz serait aussi appréciable, mais je ne pense pas qu’il arrive sur les portables Air
Ancien contributeur clé de Chromium et Node.js, et aujourd’hui contributeur clé de gRPC Core/C++, je n’ai jamais été vraiment préoccupé par les temps de build
Il y a les « builds interactifs », qui sont des builds incrémentaux pour relancer les tests unitaires concernés pendant qu’on travaille, et les builds non interactifs, qu’on lance avant d’aller prendre un café ou lire ses e-mails. Je n’ai jamais vu un changement de matériel transformer un build non interactif en build interactif
Ma machine personnelle a plus de 5 ans, avec un Intel i7 et 16 Go de mémoire, et j’ai ajouté 16 Go en comprenant qu’il me fallait plus de mémoire pour linker Node.js sous WSL
Mon portable professionnel est un Intel MacBook Pro avec Touch Bar, et je ne pense pas que cela ait un grand impact sur la productivité. Ce qui compte, c’est la taille et la qualité de l’écran, ainsi que la vitesse du stockage. L’impact du système de build, comme la vitesse des builds incrémentaux et la prise en charge des builds distribués, est plus important que les progrès du CPU. Pour mes projets personnels, j’utilise Bazel
La compilation et le linkage devraient en fait se terminer quasiment instantanément, assez vite pour qu’on ne sente même pas qu’il y a une étape de compilation
Les builds de release avec des techniques comme l’optimisation du programme entier peuvent prendre du temps, mais la boucle classique compiler/déboguer/tester pourrait être immédiate. La compilation des langages système est incroyablement lente pour des raisons historiques, mais ce n’est pas une fatalité
À force de passer beaucoup de temps à toucher aux fichiers BUILD, je me suis demandé si cela apportait vraiment plus de valeur qu’un Makefile ordinaire. C’était il y a trois ans, donc l’écosystème public s’est peut-être amélioré depuis
Pour la vitesse du stockage, je ne sais pas trop, et tous nos builds tournent sur de puissantes machines de développement distantes
Pour les personnes qui, comme dans l’article, veulent faire de l’analyse de données avec l’IA, je pense qu’il est bien plus simple de mettre les données dans R, Stata ou autre et de les interroger directement
Les commandes sont plus courtes et plus précises, et surtout la reproductibilité est meilleure
Le plus difficile dans l’analyse de données, c’est de comprendre les données et le mécanisme qui les a produites. Pour cela, il faut un modèle causal du domaine concerné
Si l’IA n’a pas été entraînée au préalable sur d’autres données de ce domaine, je ne sais pas si elle peut produire un modèle causal utile. Sans ce modèle, il est impossible d’interpréter raisonnablement les données, et je me demande aussi si les modèles d’IA actuels peuvent détecter les facteurs de confusion, l’influence excessive des valeurs aberrantes et les variables modératrices d’effet intéressantes
Dans mon cas, c’était avec Python et pandas, et on peut lui demander de montrer le code utilisé pour l’analyse
La différence, c’est entre mettre les données dans R/Python et chercher « comment faire xyzzzy » pour écrire soi-même le code, ou utiliser ChatGPT
Le plus grand accomplissement me semble être la partie disant que « tous les développeurs exécutent localement un environnement incident.io complet sur leur portable, avec une boucle de feedback de moins de 30 secondes entre une modification de code et son exécution »
À part quand j’ai aidé brièvement une startup, je n’ai jamais travaillé dans une entreprise où l’on pouvait exécuter sur une seule machine toute l’instance de développement/locale de la société
Il y avait toujours quelque chose d’inaccessible, toujours un piège
Je ne comprends pas pourquoi les gens ne se fâchent pas davantage contre une expérience développeur aussi atroce. Les jeunes qui sortent de l’université aujourd’hui ne semblent pas savoir ce qu’ils ratent
Ceux qui n’ont pas vécu dans ce monde ne comprennent pas à quel point c’est mieux, et rationalisent la situation de toutes les façons possibles
Cela dit, nous avons ajouté Snowflake l’an dernier ; cela résout de vrais problèmes, mais itérer sur cette partie est pénible
Il est linéaire par rapport au nombre de services à prendre en charge, et linéaire aussi par rapport au nombre d’ingénieurs à accompagner. De plus, divers cas d’usage qui s’emboîtent mal apparaissent, et l’équipe infra devient peu à peu le goulot d’étranglement des livraisons de fonctionnalités, tandis que chacun commence à utiliser sa propre méthode
Une fois cette boîte de Pandore ouverte, revenir en arrière est pratiquement impossible. Cela dit, réduire les cycles de développement de plusieurs heures ou jours à quelques minutes est bien plus important que de réduire ces quelques minutes de 25 %
Pour l’instant, ça se passe bien
En tant qu’auteur, merci de l’avoir partagé
L’article couvre plusieurs sujets, comme le profilage de la compilation Go, la création d’un hot reloader et l’analyse d’un jeu de données de build avec l’IA
En conclusion, passer d’un M1 à un M3 Pro valait le coup, et dans nos tests, le Max n’a pas fait une grande différence. Le M2 est assez proche du M3, donc pour nous, la mise à niveau ne valait pas le coup
Si vous avez des questions, je peux y répondre
Je me demande aussi comment ce coût influence la période d’amortissement
Ou bien il se peut aussi que les tâches se terminaient trop vite pour que la différence se voie en usage réel
L’idée est intéressante, mais la qualité de l’analyse des données semble assez faible, et je ne suis pas sûr qu’on en tire vraiment les enseignements que l’on pense en tirer
En particulier, il est difficile de comprendre pourquoi le passage du M1 Pro au M2 Pro fait augmenter aussi spectaculairement les builds de moins de 20 secondes. Sur des tâches de compilation de code, l’écart de performances réel entre les deux est d’environ 20 à 25 %
Le fait que les machines M3 aient moins de builds de moins de 20 secondes que les machines M2, ou que le M3 Pro, avec deux fois moins de cœurs, ait plus de builds de moins de 20 secondes que le M3 Max, n’a pas vraiment de sens non plus
Il est très probable que ces écarts viennent de différences de comportement des développeurs, par exemple parce que les personnes ayant différents types d’ordinateurs portables font généralement des tâches différentes
Quelques observations après une lecture rapide : le compilateur Go ne semble pas vraiment tirer parti des cœurs supplémentaires, la façon d’agréger les données est fondamentalement peu pratique, et la méthode de comparaison manque aussi de cohérence, en mélangeant histogrammes et graphes de densité par intervalles, avec des plages d’axe Y différentes
Les Mac ne brident pas les performances CPU parce qu’ils sont sur batterie. Si les builds sont vraiment plus lents sur batterie, il est difficile d’en être certain avec les seuls graphiques, mais ce serait probablement dû à l’activation du réglage « faible consommation »
C’est un peu hors sujet, mais je me demande comment les autres entreprises équilibrent la gestion des endpoints et les logiciels de sécurité avec la productivité des développeurs
Dans notre entreprise, nous faisons tourner plus de cinq services en arrière-plan sur les ordinateurs portables des développeurs, aussi bien sur Mac que sur Windows. Cela inclut la gestion des endpoints, l’interception de l’élévation de privilèges, l’interception et l’inspection TLS, l’anti-malware et un client VPN
Cet ensemble a un impact important sur les performances. Quoi que l’on fasse sur la machine, ces services consomment du CPU et des performances d’E/S, et les développeurs se plaignent de blocages et de saccades aléatoires
Vu l’augmentation des ransomwares et du vol de propriété intellectuelle, je comprends que la sécurité soit nécessaire, mais je me demande si certaines entreprises ont trouvé de meilleures façons d’assurer cette sécurité tout en affectant moins la productivité des développeurs