Hello tout le monde. Voila, je ne pose pas cette question comme qqun qui avancerait une chose alors qu'il est capable de rien faire. Il s'agit d'une véritable question que je pose à tout ceux qui programme à un haut nivo.
 
J'aimerais savoir si la montée en puissance des machines fait que les ( mauvais ? ) programmeurs optimisent moins leur programmes ? Quand je parle de programmeurs, ce sont les programmeurs dont les programmes se destinent à se retrouver sur la marché, que ce soit un jeux ou un logiciel de gestion.
 
En prenant l'exemple d'un développeur de jeux aujourd'hui. Est-ce qu'il cherche à exploiter au mieux la machine ou est-ce qu'il se rabat le plus souvent sur la puissance de la machine pour compenser la "faiblesse" de ce qu'il a mis au point ?
 
Voila, ne voyez aucune attaque dans mes propos , @+

On peut plus vraiment optimiser en fonction de la machine, mais par contre au niveau de la qualité de code oui.
 
Un jeu demande 1 a 2 ans de dev, et utilise a 99% des API pour le hard, donc tu ne sais pas sur quelle machine ca tourne, ni quelle sera la puissance de la machine.
 
Généralement 10% du code prend 90% du temps, les 90% restant prenant 90% supplémentaires (loi de Murphy sur l'optimisation).

Faut préciser que c'est plus trop la peine d'optimiser : y'a des trucs comme DirectX qui te permettent a partir de ton meme code d'avoir un programme optimisé pour chaque machine à condition que le gars ait DirectX a jour et les drivers aussi biensur ...
Enfin, en theorie.
Aujourd'hui on s'attend plus a ce que ce soit le constructeur qui donne des moyens simples pour utiliser efficacement son matos que le programmeur de se trouer le cul pour chaque carte chaque proc ...)

J'oubliais : je parlais d'optimisation hardware ...
Evidemmenent faut optimiser ses algos ...

en fait ca depend aussi du domaine concerné, pour les jeux, il y a une concurrence enorme et c'est pourquoi les algos et l'utilisation du materiel sont tres poussés. Pour avoir des jeux de plus en plus beau et de plus en plus rapide. Meme si il est vrai la puissance des processeurs et surtout des carte graphique aident beaucoup.
 
Le probleme avec les langages de haut voir tres heut niveau, c'est qu'ils sont de plus en plus faciles à utiliser donc n'importe qui peut faire une application (windev par exemple) mais comme beaucoup n'ont paseu de formation (algo) ben ils font ca n'imp. J'ai un exemple simple avec une base de données :
 
Un jour j'ai rencontré un gars qui devait m'expliquer comment fonctionait WinDev. Il avait du faire un formulaire avec une base de données derriere. Il n'avait mis qu'une table dans sa base. Au point de vue optimisation, c'est pas génial. Le nom du client est repeté a chaque fois dans la base au lieu d'etre codé est remplacé par une clé. Mais bon le gars n'avait jamais suivi de formation, c'est pas vraiement de sa faute. Mais bon ca fait peur.

Il faut voir aussi que, pour les langages généralistes (comme C, C++, Ada, ... et même Java), les compilateurs sont aujourd'hui beaucoup plus intelligents qu'avant (pour Java, c'est surtout la machine virtuelle pour être exact). Ils sont souvent capables d'optimiser le code généré de façon absolument incroyable.
 
Sauf que... les techniques d'optimisation les plus puissantes fonctionnent généralement par "motifs" (ce qu'on appelle les optimisations à lucarne), et les fabricants de compilateurs n'implémentent que les motifs les plus courants (pour un tas de raisons : parce que c'est du code en plus dans le compilo à écrire, à maintenir, ..., donc ça coûte plus cher, et puis ce n'est pas la peine d'implémenter une optimisation qui ne va servir qu'une fois tous les 5 ans).
 
Résultat : pour que le compilateur génère le maximum de motifs connus avant optimisation, il vaut mieux écrire son code le  plus proprement possible, c'est-à-dire sans optimisation ou astuce au niveau code source, ou, si tu préfères, le plus proche possible d'un langage algorithmique. Et puis plus le langage est de haut niveau, plus les potentialités d'optimisation sont étendues. Par contre, le goto et les pointeurs (pour ne citer qu'eux) sont des outils de bas niveau, qui sont difficiles à optimiser lorsqu'ils sont directement utilisés dans le code source.
 
De plus, ce qui coûte le plus cher aujourd'hui (de très loin), ce n'est pas l'heure de CPU, mais l'heure de développement. Donc cela coûte beaucoup moins cher de moins optimiser au niveau source, car le développement du code d'une part, son débogage et sa maintenance d'autre part coûteront aussi moins cher.
 
Enfin, je dirais que c'est aussi une bonne chose que les gens globalement essaient moins d'optimiser leurs sources, car peu d'entre eux mesuraient vraiment le résultat de leurs optimisations. Crois-moi, la plupart des astuces pour optimiser le code à vue de nez, en réalité ne changent rien, voire ralentissent le code.
 
Une optimisation véritable doit se baser sur les résultats que fournissent les logiciel appelés profilers. Ainsi on peut voir les vrais goulets d'étranglement d'un programme -- et non pas les goulets supposés -- et passer du temps à résoudre des vrais problèmes. Mais hélas, ce sont des outils encore bien méconnus de nos jours.

une chose est sure, windev c'est ULtraaaaaa lent !

Assez d'accord avec tout le monde...
 
Exemple là où je bosse (service info/compta d'une banque), on fait du client-serveur avec PowerBuilder, du C et du KSH sur une base Sybase, un logiciel utilisé quotidiennement par 120 personnes.
 
Bon, l'optimisation, qui concerne quasi-uniquement les procs stockées TransactSQL, n'est pas systématique : si les temps d'exécution sont acceptables, on passe à autre chose. On n'optimise jamais pour le plaisir : souvent, cela revient (pour nous en tout cas...) à bidouiller le code (par exemple, forcer un index pour influer sur le plan d'exécution de la procédure, le truc à éviter en général) et donc le rendre plus difficilement maintenable : il est plus facile de faire évoluer un code plus simple.
 
Wouala... Un p'tit bonjour à tout le monde, Internet m'a été interdit au bureau suite à une couille d'un collègue, donc j'ai nettement moins l'occasion de venir.

Il faut distinguer les différentes optimisations qui sont abordées dans le processus de développement.
 
- les optimisations architecturales sont les moins évidentes car elles interviennent au début du processus de développement.
Elles concernent l'architecture du projet, son découpage en modules, et la définition des classes (ou des structures) dans ces modules. Le meilleur mauvais exemple c'est la classe gigantesque trimbalée un peu partout et dont 90% des champs servent occasionnellement. Une fois le projet bien avancé, tout changement revient à peu de chose près à tout refaire ...
 
- les optimisations algorithmiques. En gros, moins le programme en fait plus il va vite. Ca paraît trivial à première vue, mais en pratique c'est parfois difficile à réaliser. Ces optimisations concernent le code mais aussi les données traitées par le code. Par exemple, diminuer la complexité d'un modèle 3D est une optimisation algorithmique, car elle s'inscrit dans la lignée de "moins on en fait plus ça va vite".
 
- les optimisations de bas niveau. Elles dépendent essentiellement du matériel embarqué. Par exemple diminuer le nombre d'opérations coûteuses en cycles processeurs, dérouler les boucles ... cette phase tend à disparaître pour plusieurs raisons : elles sont très longues à faire et nuisent beaucoup à la lisibilié du code (et donc à sa maintenance ou à sa réutilisation).

z51> Très bonne synthèse.
 
Mais à mon avis, ce qu'on appelle communément "l'optimisation d'un programme", c'est ce que tu as appelé "les optimisations de bas niveau". Par ailleurs, ce que tu appelles "les optimisations architecturales", même si dans les faits, ça rend souvent le code plus efficace, j'appelerai cela plutôt du "ré-architecturage". Quand on le fait, on regarde rarement le gain point de vue efficacité du code, seulement du point de vue coût de mainteance du code (et c'est déjà beaucoup !)