Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Heu, je dirais plutôt 5 x 600€ = 3000€ lol pour un bon dev, et encore...
optimiser c'est aussi rendre le code plus facile à maintenir et pas seulement plus performant.Et qu'en est il de la maintenabilité de son code (je ne l'ai pas trouvé sur la page du projet) ?
alors déjà les fractales étant récursives par nature, elles sont propices à l'optimisation
ensuite l'exécutable n'est pas standard, au lieu d'avoir un DOS STUB et différentes sections, les informations se chevauchent afin d'obtenir un format de fichier le plus compact possible tout en étant compatible Windows...l'application plante probablement si elle est lancée sous DOS au lieu d'afficher (en mode DOS) "ce programme nécessaire Windows" ou équivalent.
mais bon personnellement je suis favorable à la réduction de la taille des executables sans avoir recours aux compresseurs d'exe qui ont des conséquences dramatiques sur la gestion mémoire. et cela n'implique pas forcément un code plus complexe, ni même des outils plus limités...en tant que développeur Delphi je déplore notamment la constante augmentation de la taille des exécutables pour un même source quand on utilise un compilateur plus récent.
J'avoueEnvoyé par GLDavid
http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main
ça ne fonctionne qu'avec des cartes graphiques "assez" modernes.
Pour cette démo, pas grand chose à dire si ce n'est que c'est très connu que ce genre de démos est une vraie mine d'or pour obtenir des programmes aussi petits. Ah et au fait : on ne peut pas battre l'ASM en terme de code size, peut importe l’intérêt que ça peut avoir (ah si, l'embarqué...). Pour du code "normal" (hors embarqué), diminuer la code size sert franchement à rien, tellement le gain est marginal.
Sinon, en général, je pense pouvoir m'autoriser à penser qu'il soit possible que les développeurs actuels ne pensent pas à optimiser leur code. C'est une des seules explications que j'aie pour expliquer la Loi de Wirth, avec l’essor de la programmation orientée objet et des implémentations de langages basées sur de la compilation JIT (heureusement que nos CPU sont de vrais brainiac, ça aide pour exécuter du code Java).
Quand au pourquoi de cette non-optimisation par les programmeurs...
-> La croyance en ce soit-disant progrès technologique qui ferait en sorte que nos processeurs deviennent de plus en plus puissants avec le temps alors que les augmentations de performances dues au hardware deviennent de plus en plus marginales sur les PC x86. Le tout colporté par des ignares en architecture des ordinateurs qui croient que la loi de Moore est synonyme d’augmentation de performance et qui ne connaissent pas la Loi d'Amdhal généralisée et son corolaire sur les rendements décroissants), ou la notion de Memory Wall ?
-> La "croyance" que l'optimisation prend tu temps, nuit à la maintenance ou la lisibilité, etc. J'ai l'impression que c'est vrai pour les micro-optimisations obsolètes qui jouaient sur le cout des opérations, mais les optimisations algorithmiques et/ou de la localité (ou autres tout aussi efficaces) qui foutent en l'air la lisibilité ou la maintenabilité ne m'ont pas l'air d'être si nombreuses que cela. Mais je peux me tromper.
-> La croyance que " early optimisation is evil ", inculquée de force dans les écoles d'informatique, qui pousse à utiliser des profilers et autres outils de benchmarking qui font pire que mieux et donnent des chiffres totalement biaisés. Changez de PC et vous aurez des résultats totalement différents en fonction de l'organisation du sous-système de cache, et vos soi-disant optimisations prouvées à grand cout de profilers auront des effets pires que le mal. Et il parait qu'en plus, il y a pas mal de biais dans ces profilers : il y a des trucs dits dessus dans les manuels d'optimisation d'Agner Fog (qui déconseille les profilers)), et vous aurez plus de renseignements là dedans : http://www.parleys.com/#st=5&id=2103&sl=15, dans les références données vers la fin de la vidéo.
-> L'usage actuel qui est fait des complexités algorithmiques, qui pousse à passer sous le tapis les constantes multiplicatives. Sans compter que compter des opérations arithmétiques à l'heure où certaines applications passent 50% du temps d’exécution d'un code est passé dans les caches miss (et encore, c'est pour des applications scientifique, optimisées comme il faut pour la localité), et 15 à 35 % dans les miss prédiction de branchement... Bon, OK, l'effet doit être très faible, j'admets.
-> Le fait que les programmeurs lambdas ne savent pas optimiser convenablement. Qui connait le concept de Cache oblivious Algorithm dans l'assemblée ? Qui sait comment optimiser un programme de manière à améliorer sa localité ? Pire : de nos jours, qui sait ce qu'est une mémoire cache ?
Je parie qu'une majorité de programmeur ne connait rien au fonctionnement d'un ordinateur moderne et a oublié ses cours d'architecture des ordinateurs qu'on lui a donné dans sa formation de base.
Ça va être joli quand il faudra passer aux processeurs multicœurs !
-> La paresse ? Pourquoi optimiser alors qu'on peut s'en passer ? A ce rythme là, je me demande pourquoi je perds du temps à indenter mon code, vu le nombre fois que mon code sera relu comparé au nombre de fois qu'il sera exécuté !
Je n'ai pas regardé le programme, mais à ceux qui veulent voir le code, amha, le source est livré avec, aux noms de variables près: il suffit d'un désassembleur
Pour en revenir à la question de l'optimisation, ce que je me souviens de mon BTS, ce sont des profs qui encouragent l'utilisation du type int en C et en C++.
Y compris parfois pour de simples flag.
"Au prix ou est la ram..." qu'ils disaient.
Si on cogite un tant soit peu, un int (dans cet exemple) pose d'autres problèmes que la RAM:
_ place sur le disque dur de l'exe selon les options de compilation
_ combien d'écart en temps processeur comparé à un unsigned char?
Le tout multiplié par n collections de plusieurs milliers d'éléments, je pense que ça se sent.
Et ce, y compris sur un serveur (surtout?) parce que sur un serveur les ressources sont quand même plus critiques.
Ca, c'est pour du C, du code bas niveau. Maintenant, l'optimisation, c'est aussi sur des langages de plus haut niveau, comme les *SQL.
Et lorsqu'il y a des jointures inutiles ou des requêtes non optimisées, ça peut donner des trucs assez impressionnant. De l'ordre d'utiliser 5 minutes pour une requête équivalente qui donne son résultat en moins d'1s.
Négligeable l'optimisation?
Ca dépend la situation, mais on nous enseigne que ça ne sert à rien, "le client peut racheter une bécanne". Je n'en suis pas si sûr, moi. D'autant que la plupart des optimisations que l'on peut faire ne nécessitent pas d'aller dans l'assembleur.
Par exemple en C++ utiliser des références pour les types non natifs ne prends pas forcément beaucoup de temps, mais on gagne à chaque fois au moins 2 appels:
_ constructeur de copie (pour créer un objet temporaire)
_ destruction (de l'objet temporaire)
Et ça n'a aucun impact sur la lisibilité du programme.
Mais bon, longue vie aux constructeurs.
Sérieusement, quand je vois des jeux du genre breakout qui ne peuvent même pas tourner sur un netbook récent (de moins d'un an) alors que des FPS y fonctionnent (même sans carte graphique, même s'ils sont vieux et pas excessivement beaux), je pense qu'on peut se poser des questions.
D'autant qu'a l'ère ou l'on parle de réutiliser le code le plus possible, un code réutilité qui est optimité, ça veut dire qu'on optimise tous les programmes qui en dépendent.
Qu'est ce qui est optimisé ici ?
Qu'est ce qui est optimisé ici ?
Attention pour moi, pour un programme standalone classique il existe plusieurs types d'optimisations qui n'ont pas le même objectif.
On peut vouloir optimiser :
* la taille de son Exécutable (taille du binaire) et des DLL.
Cela permet de consommer un (peu) moins de mémoire vive si on a beaucoup de DLL et de taille disque...
Ce n'était plus trop à la mode... mais cela revient avec les mobiles...
* la taille de la mémoire consommé lors de l’exécution d'un programme.
Toujours nécessaire quand on manipule de gros volume de donnée... pour en mettre toujours plus... même si la pression aurait tendance a se relâcher avec le passage au 64 bits...
* l'utilisation du CPU.
Vaste programme... et beaucoup de stratégie en fonction du contexte (algorithmie pure, passage en multi-thread, passage en calcul distribué, utilisation de processeur spécialisé, etc...)
En pratique, peu de programme on besoin d'optimisation de code...
Dans tous les cas à faire avec des outils de mesures... et à partir d'un certains seuils devient bien technique...
Bonjour. Je ne suis pas programmeur de formation, mais j'ais suivi une sous-filière... Où l'on a pas expliqué cette histoire de Memory wall ? Ni de Cache oblivious Algorithm ? As-tu/Auriez-vous des références vers ces principes (francais ou english).
Pour l'instant je m'en tiens à coder une "tile array" et à l'adapter pour un binary tree, afin d'éviter les "cache misses".
Merci.
En terme de temps processeur, il me semble qu'à moins de remplir des unités vectorielles ça doit être pareil int ou unsigned char non ?
Bon selon le case on peut gagner en terme d'occupation mémoire, et donc de bande passante mémoire, et aussi d'occupation dans les caches en général.
Google est ton ami... La page wikipedia sur Cache Oblivious Algorithm est assez claire je pene.
il me semblait que les int était plus rapide sur un processeur 32bits vu que l'écriture se faisait en une seule instruction (pas besoin de cast) mais c'est peut-être vrai que sur les processus RISC.
Sinon je suis pas sur de comprendre la page Wikipedia de Cache Oblivious Algorithm. En gros c'est juste faire attention à ne pas faire ça :
?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6for(int i = 0; i < rowCount; i++){ for(int j = 0; j < columnCount; j++){ matrice[j][i] = 0;//ici il faudrait : matrice[i][j] } }
EDIT : Le code ci-dessus est en Java/C, en Fortran ce serai le contraire.
Ou alors c'est l'utilisation un cache logiciel ? Mais j'ai du mal à comprendre comment en implémenter un. Pour un cache disk => RAM j'arrive à comprendre mais là...
code_optimise != code_reduit
D'ailleurs c'est même quasiment le contraire dans la plupart des cas, j'ai plein d'exemples.
Personnellement, en c++, je fais presque que du "inline", ça prend deux fois plus de place (osef ?) mais c'est deux fois plus rapide !
Elle est vaguement claire. Mais je voulais aussi éviter d'apprendre les concepts au fur et à mesure qu'on daigne me les citer, et espérait un cours où je trouverais une explication de ces concepts de performence. La page "software optimization" sur wikipédia a peu de liens…
Merci, toutefois si vous avez des référence plus complètes, partagez-les !
Tu ne devrais pas... La plupart des développeurs regardent les performances de leur code, et cherchent à l'améliorer *quand c'est nécessaire*, sinon il n'y a pas grand chose qui tournerait, même sur des ordinateurs modernes, compte tenu de l'explosion des volumes de données gérés (même par des programmes assez basiques).
A mon avis, ce n'est pas la bonne... une fois de plus, il faudrait chercher du côté des volumes d'information traités, du nombre de programmes tournant concurremment.
La programmation orienté objet c'est aussi une forme d'optimisation: celle des temps de développements et des couts de maintenance évolutive. Et ce n'est pas forcément plus lent que le procédural.
C'est pourtant vrai... Optimiser du code demande des tests, du développement supplémentaire, et se traduit souvent par des algorithmes plus compliqués que les 'basiques' qu'on a fait au début (sinon on n'optimiserait pas).
C'est vrai et faux... L'un des principaux pourvoyeurs de cette croyance est Knuth, qui n'est pas exactement un mauvais programmeur (ni un moderne). Je crois que la façon dont il faut comprendre l'adage est que l'on ne peut optimiser qu'une procédure que quand on en a compris le fonctionnement et les limites. En général, quand on commence à développer, on se fait une idée fausse des difficultés, des blocages, des volumes à traiter, des temps nécessaires. En optimisant trop tôt, on a de grandes chances de s'attaquer au mauvais problème, et de compliquer gratuitement le code sans pour autant l'accélérer.
C'est jeter le bébé avec l'eau du bain... L'objet d'un profileur, ce n'est presque jamais de te donner des chiffres justes, sur le nombre de cycles, d'accès au cache, ou chaipaquoi, mais de te donner une vision correcte des endroits de ton code ou le temps est perdu... Un profileur, ca compte des appels, des accès, et des durées à la louche. Les mesures de temps précises, c'est juste le marketing.
En revanche, optimiser sans profileur? tu fais quoi? tu mesures des temps d'exécution avec ton i-phone, et tu mets les nombres d'appels dans des variables locales?
Euh? Un calcul de complexité donne toujours les constantes multiplicatives. Maintenant, elles n'interviennent qu'au second ordre. Le premier objectif de l'analyse de complexité, c'est de savoir comment un algorithme résiste à l'augmentation des volumes de données. Entre un linéaire et un logarithmique, il y aura rarement photo, pareil entre un linéaire et un quadratique.
Personne sauf toi, bien sur... Sérieusement, ce type d'optimisation 'machine' est généralement laissée au compilateur. Optimiser correctement, quand on est programmeur, la plupart du temps, c'est s'intéresser à l'algorithmique et à la mémoire utilisée. C'est là qu'on gagne les ordres de grandeur, quelle que soit l'architecture...
Maintenant, je pense que la principale raison pour laquelle il y a pas mal de code non optimisé tient au fait que l'optimisation, ça demande pas de l'expérience, du recul et du temps. Dans la vraie vie, ça manque, pas qu'en informatique, d'ailleurs.
Ca demande aussi un bon bagage scientifique (des maths, plutôt qu'une connaissance des architectures machines, si tu veux mon avis...)
Francois
Dernière modification par Invité ; 22/05/2012 à 22h52.
sûrement vrai dans 95% des cas...
mais dans certains cas, même en améliorant "sur papier" la complexité d'un problème, il se peut qu'en pratique la pensée d'une optimisation entre en conflit avec un aspect du matériel cible et cause au final du tort.
clairement ce genre de problème ne survient que lorsqu'il devient nécessaire de descendre bas niveau pour adapter au mieux le programme au matériel, ou lorsque la système conçu approche des limites du modèle prévu initialement
Pas seulement le matériel, les données sont parfois en cause. Un exemple typique est celui des tris, où l'algorithme "optimal" changera suivant que les données sont très mélangées ou juste un peu en désordre, ou qu'elles présentent un grand ou un petit nombre de valeurs différentes.
Dans le cas du matériel, le problème vient souvent du fait qu'on n'analyse pas la "bonne" complexité. Pour rester sur les tris, on optimise généralement le nombre des comparaisons, ca c'est censé être la bonne mesure du travail à effectuer. Mais si l'accès à la donnée est le facteur bloquant, la nature du problème change du tout au tout.
C'est à cela que servent les profileurs, en fait. Ce renvoie aussi, quelque part, à l'optimisation prématurée dont parle Knuth.
Francois
Je sais, mais le fait est que les profilers sont moins bon que prévu pour identifier les portions de code les plus gourmandes parmi toutes les autres, et pas mal de biais peuvent rendre les résultats globaux fournis par le profiler non signifiants. De quoi se mettre à optimiser la mauvaise portion de code dans certains cas. J'ai déjà lu quelques articles de recherche dessus, comme celui-ci : http://pl.cs.colorado.edu/papers/mytkowicz-pldi10.pdf. La cause serait simplement les méthodes utilisées pour l’échantillonnage des données.
Pour les remplaçants du profilers, il y a bien des solutions mentionnées dans les PDF d'agner fog, mais je trouve ces solutions assez gores.
Ou sinon, on peut aussi coder proprement dès le départ, sans trop passer de temps à optimiser dessus en pensant qu'on a affaire à un hot spot et en évitant de toucher à la lisibilité/maintenabilité du code. Mais c'est vrai qu'il faut faire cela correctement. Personnellement, je considère que rien que penser à la localité de son code aide beaucoup, et prend assez peu de temps comparé aux gains qu'on peut y gagner sur les architectures actuelles.
Sauf que pour ce qui est de la localité, si on ne pense pas à celle-ci dès la conception du code, ton compilateur ne pourra rien faire. Si tu ne choisit pas les bonnes structures de données et que tu n'accède pas à celle-ci comme il faut, cela empêchera ton compilateur d'appliquer les optimisations liées au cache qu'il est capable de faire. La localité se pense parfois à assez haut niveau : devoir y penser au niveau des algorithmes et des choix de structures de données n'est pas si rare que ce qu'on peut penser. Et les gains peuvent être assez élevées dans ce genre de cas : avoir un programme 3 à 4 fois plus rapide n'est pas négligeable dans certains cas.
Dernière modification par Invité ; 22/05/2012 à 23h56.
Là où il me semble que la fainéantise est flagrante, c'est dans le développement des jeux vidéo. Le temps des super bons jeux qui tiennent sur un CD est loin... très loin...
Merci pour l'article, très intéressant. On rencontre le même genre de problème avec des langages compilés, notamment quand on a des accès au disque, ou à d'autres périphériques, ou qu'on utilise d'importants volumes de mémoire contigue.
A mon avis, ça ne disqualifie pas les profileurs, mais ca demande de bien savoir les utiliser. C'est un peu comme le débogage, en fait, on a des outils puissants, mais souvent, on les utilise mal.
Egalement, le profileur ne remplace pas le benchmark.
Je suis d'accord. Pour être optimisable (par un compilateur ou par toi), un code doit être raisonnablement efficace au départ.
Francois
Le résultat est très impressionnant !
Pour ce qui est du débat sur l'optimisation du code, je ne suis pas un développeur professionnel, je viens à peine de commencer (2-3ans).
Mais il est clair que la plupart des développeurs n'ont plus la même motivation ou curiosité d'il y a quelques années... On peut leurs parler du fonctionnement des registres ou encore des théories sur la mémoire, comment tous cela fonctionne et bim, pas de réponse.
C'est vraiment dommage... Mais bon, beaucoup de nouveaux développeurs deviennent de plus en plus fainéant et non plus la même connaissance, car justement cette connaissance est devenu obsolète pour la plupart des gens :s
Mais bon, en tous cas, joli performance
Quelle librairies ont été utiliser?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager