Ça dépend ce que tu entends par "technologie d'aujourd'hui". Sur un PC, effectivement, rien à fiche. En systèmes embarqués où les ressources sont limitées, c'est crucial. On y évite déjà fortement l'utilisation des variables locales par limitation de stack, et cela nuit bien plus à la compréhension du code.

Je te parle d'un monde où t'as 4Kb de mémoire programme pour faire tenir un firmware de satellite, où l'allocation dynamique n'existe pas et où la stack fait 1.5Kb dans les grands jours. Et je ne te parle pas de matos des années 80, je te cite là des chiffres d'un microcontrôleur pas encore sorti qui est encore au stade de développement/prototype :P

Dans ce genre de circonstances, le moindre byte (surtout de programme) compte, et l'assembleur est régulièrement inspecté à la main pour trouver des pistes de réduction.

oui encore une fois il s'agit de limitations techniques ^^

et dans ce cas je comprends parfaitement
moi je parle surtout de programmes inutilement complexes d'un point de vue conception :p , alors qu'aucune contrainte technique ne semble justifier la complexité mais seulement le fait que le développeur ait foncé tête baissée

J'avoue que la mémoire ne coute plus grand chose aujourd'hui

Ah, je n'avais pas vu le message de MrTrolloIo auquel tu répondais, je pensais que tu me répondais à moi. D'ailleurs justement vis-à-vis de cette remarque je ne suis pas vraiment d'accord. On vit dans un monde où le code n'est pas figé et évolue en permanence. L'utilisateur appréciera avant tout un logiciel sans bug, et aux fonctionnalités s'améliorant avec les différentes versions. Un code mal pensé ou mal formaté sera plus facilement erroné et difficile à améliorer, surtout lorsque de nouveaux développeurs devront reprendre la base de code. Exemple moderne: gcc est puissant, mais est en train de se diriger vers la sortie car il n'est tout simplement plus maintenable.

Ensuite deux arguments : Déjà le fameux argument des point chauds; ce ne sera souvent que des points très spécifique qui feront du mal au performances. Mieux vaut faire un code correct dans un premier temps et optimiser par après les zones qui, après profiling, montrent qu'elles en ont besoin, c'est maintes fois prouvé par l'expérience. Et les gains sont souvent illusoires sur du code qui sera ensuite compilé et passé dans un pipeline de CPU bien complexe (sans parler de l'OS dans le tas), ce qui change la donne par rapport à ce que le programmeur perçoit dans sa tête.

De plus, dans le monde où on fait tourner des OS ou des jeux-vidéo, le matériel est souvent bien moins cher que le programmeur. Pire encore, ses performances montent tout seul avec le temps (même si c'est moins vrai qu'avant). Perdre des ressources en développement sur un code spaghetti est au final contre-productif.

" Déjà le fameux argument des point chauds; ce ne sera souvent que des points très spécifique qui feront du mal au performances. "

Évidemment, c'est bien connu ça, mais justement dans ma phrase j'ai dit "SI il faut produire du code illisible", or si ce n'est pas un "point chaud" comme tu dis, il ne faut pas.

Et j'ai aussi dit que "ultimement" la performance devait prendre le dessus, en sous entendant donc de le faire après avoir vu où c'était nécessaire de le faire.

Harpiste -> Ça dépend du domaine d'application.

Déjà t'as le cas du très petit embarqué, où il s'agit de rajouter de l'électronique digital dans un composant produit en masse qui doit être le moins cher possible. Jouet surprise de restaurant, ampoules connectées en réseau, ... Des cas où la très grosse échelle de production rend ça intéressant.

Dans mon cas, modules de satellites, ce genre de contraintes provient du fait que le hardware doit être particulier, essentiellement pour des raisons de fiabilité : Résistance à très haute et très basse température, aux vibrations et autres contraintes mécaniques. Redondance importante et omniprésente. Qualité de l'équipement qui devra être minutieusement inspecté. Contraintes de poids et surtout d'espace dans le satellite (plus l'ASIC est complexe, plus il est grand).

En particulier, la résistance aux radiations et particules est une horreur. Imaginez devoir partir du principe que n'importe quelle partie de votre circuit analogique peut tout d'un coup subir une sur-tension localisée, ou au niveau logique que n'importe quel bit peut tout d'un coup être inversé. Cela implique un hardware qui prend cela en compte. Au niveau de la mémoire, la mémoire programme va être dupliquée afin d'avoir un espace de backup, et un "scrubber" parcourt en permanence l'intégralité de la mémoire pour vérifier que chaque espace mémoire est toujours correct via un code correcteur. En pratique, pour chaque byte de mémoire, on utilise 5 bits de vérification (4 redondants et un de parité). Le système est capable de corriger une erreur et d'en détecter deux (dans ce cas reboot sur l'espace de backup).

Et puis aussi, la mémoire va pouvoir être accédée par différents systèmes (microcontrôleurs partageant une même zone de mémoire physique, le scrubber que je viens de mentionner, périphériques, etc.), demandant un système capable de rendre le tout cohérent.

Associée à l'échelle minuscule de production du matériel (relativement aux microcontrôleurs classiques), il n'est pas étonnant que toute cette complexité rende le coût de la mémoire prohibitif. Et il y a encore certainement bien d'autres raisons techniques dont je ne suis pas au courant.

Tout ça c'est contraignant, mais avouez que ça a un coté terriblement cool ? En tout cas moi, je ne m'en lasse pas :P

De toute façon c'est très souvent une question de prix, si tout le monde était milliardaire il est clair qu'on pourrait avoir des machines avec beaucoup plus de ressources mais ce n'est pas le cas, le problème du coût est une des limitations principale à laquelle doivent faire face les gens qui sont chargés de concevoir les circuits électriques. C'est notamment pour ça qu'on trouve certains concepts comme la fameuse hiérarchie de la mémoire:

http://upload.wikimedia.org/wikipedia/commons/0/0c/ComputerMemoryHierarchy.svg

Les mémoires les plus rapides (comme celle des registres ou des caches du CPU, souvent de la SRAM) sont aussi les plus coûteuses et on ne peut pas se permettre d'en avoir une grande quantité, en revanche la mémoire principale du PC (souvent de la DRAM) est moins coûteuse et du-coup il y en a en plus grande quantité. L'idée est d'essayer de faire en sorte que le PC accède aux mémoires les plus lentes aussi peu souvent que possible même s'il faut forcément y accéder de temps en temps vu qu'on ne peut pas tout stocker dans les caches.

Je n'apporte pas grande eau au moulin, mais merci pour la discussion et les messages. C'est rafraîchissant de lire et voir ce genre de chose.

Seule chose que je peux apporter, par rapport à ceci : "Mieux vaut faire un code correct dans un premier temps et optimiser par après les zones qui, après profiling, montrent qu'elles en ont besoin, c'est maintes fois prouvé par l'expérience"

=> first make it work, then make it right, and, finally, make it fast

Salut ! Vous connaissez un site pour télécharger les sources d'UNIX ? Je parle bien des versions du systèmes du laboratoire Bell.

J'ai trouvé ça :

http://minnie.tuhs.org/cgi-bin/utree.pl

Ca m'a l'air très complet, mais ça ne m'a pas l'air officiel. Si vous connaissez des liens officiels je suis preneuse, merci

"Seule chose que je peux apporter, par rapport à ceci : "Mieux vaut faire un code correct dans un premier temps et optimiser par après les zones qui, après profiling, montrent qu'elles en ont besoin, c'est maintes fois prouvé par l'expérience" "
L'idéal est de ne mettre le code en prod/committer le code que après être passé par ces deux étapes de "piser rapidement du code qui marche" et "revoir tout le code dégueulasse pour le refaire proprement"

pour ma part je vise souvent le "écrire un peu moins rapidement du code propre" + "revoir encore ce qui peut être amélioré ou ce qui manque" , ça me fait finalement gagner du temps car je n'ai pas énormément à améliorer dans le second temps, et mon code est un peu plus présentable à tout moment et pourrait partir en prod.

d'ailleurs dès qu'il y a des commits de la part de collègues je fais du code review pour vérifier que tout semble compréhensible niveau sémantique et que tout semble ok niveau styles de code communément utilisés.
et je fais des remarques direct
et on le fait pour moi également

dans les deux cas c'est rare qu'il soit nécessaire de faire des remarques, car les deux cas (code qui pose problème) sont rares (mais bon ça arrive

VampireGirl il ne me semble pas que le code d'UNIX soit disponible

C'est ce que je me dis, néanmoins ce lien fourni vraiment beaucoup de code :louche:

Je suis en desaccord complet avec l'approche, on code comme un crado et on regarde a posteriori ou sont les problemes de performance. Ca ne marche que si les besoni de performance que l'on a sont faible.

La performance, comme la securite, doit etre considere depuis la conception du logiciel jusqu'a son implementation. Obtenir de la performance, ca veut dire avoir toutes les structure de donnee dans le format qui est adapate a la machine sur laquelle on va construire l'application.

Le probleme de l'approche "j'optimise ce qui prends du temps" est que c'est un vrai jue de "whack a mole", a chaque fois que tu optimizes un cote, tu t'apercois qu'un autre devient le probleme. C'est particulierement vrai dans les systeme pipeline ou parallele en general.

" La performance, comme la securite, doit etre considere depuis la conception du logiciel jusqu'a son implementation. "

Je pense que ça dépends de quel genre d'optimisations on parle, des optimisations au niveau algorithmique sont à considérer dès le départ, personne n'a jamais dit le contraire, en revanche des optimisation bas-niveau avec des petits trucs de hacker sont plutôt à considérer seulement après avoir fait du profiling.

Salut tout le monde ! Alors voila on m'a conseillé ce tuto pour commencer JAVA :http://java.developpez.com/livres-collaboratifs/j
avaenfants/
mais le truc c'est que le tutoriel d'installation est pour Windows XP et j'ai Windows 7 :'( je n'arrive pas à trouver la variable Path dans mon ordinateur alors auriez vous des tutoriels pour installer Java 8 pour windows 7 ? Merci d'avance pour vos réponses !

Variable path : clic droit sur ordinateur Propriétés (ça devrait ouvrir une nouvelle fenêtre) (sur la gauche) Paramètres systèmes avancés Variables d'environnement Et en bas dans variables système, trouver et modifier la variable PATH

Oui mais en fait je ne comprend pas comment crée la variable :'(