Re: Who's that guy ?

Ces optimisations dans les CPU sont ce qui permet d'avoir du matériel moderne qui continue d'exécuter le code existant avec de meilleures performances.

de toute façon — me concernant — j'ai croisé plus d'applications I/O bound (le CPU passe son temps à attendre des données à traiter) que CPU bound...

• déjà pour celles CPU bound savoir gérer le mulithreading (avec la démultiplication des cœurs) ou au minumum le multi-process ce serait bien^TM : cas réel, une appli calculatoire qui fonctionnait mieux sur un CPU à 3,6 GHz que sur un CPU plus récent multicœur (6 ou 8) mais à 1,6 GHz : 3h de traitement contre 4 à 5h, 8 mois après et 4 changements de CPU, le projet a enfin eu son budget pour passer en multithread :/ (ce qui était ma recommandation initiale...)
• pour celles I/O bound :
  • relire un répertoire de 10000 fichiers à chaque fois qu'on traite un fichier, autant en mettre 9000 de côté et les fournir par paquets de 1000 pour accélérer les traitements de rattrapage...
  • savoir optimiser des requêtes SQL : ça me prenait parfois jusqu'à 3 semaines pour disposer d'un DBA compétent, mais passer de 10 sec à 100 ms pour des requêtes conséquentes réutilisées, ça peut valoir le coup (tant que les requêtes sont fonctionnellement équivalentes) et j'ai maudit pas mal d'ORM pour leurs requêtes imbriquées aux plans d'exécution douteux)
  • lenteur d'affichage de page : connaître le problème des écrivains / lecteurs et les optimisations de moteur SQL, ça peut aider... en plus de la gestion basique des locks (pas forcément qu'au niveau ligne, parfois niveau bloc :/)

bref, la gestion des perfs : un bon profiler de code pour savoir où tu passes le plus de temps et savoir organiser des tests/benchmarks avec des volumétries représentatives.... (mais c'est un autre métier que développeur en tant que tel)