Outre les problèmes de spécifications et de gestion des équipes, les technologies utilisées sont à mon humble avis un frein important : programmer est une "métaphorisation" d'une spécification, d'un besoin dans un langage très lié à l'outil qu'on utilise : l'ordinateur. Métaphorisation, au sens où programmer consiste à transformer la représentation humaine d'un traitement de données (dans les logiciels orientés gestion), de comportements d'agents (dans le jeux)
On constate, en caricaturant un peu, qu'il existe deux types de langage :
- les langages de haut niveau permettant un développement rapide car la métaphorisation à effectuer est moins spécifique à la machine : elle est plus proche (ou moins lointaine, comme on préfère) d'une façon humaine de se représenter les choses.
La notion de pointeur y est généralement absente, ils gèrent leur mémoire eux-même, ils sont concis. Ces langages sont généralement assez lents. - les langages bas niveau permettent de produire du code cible rapide, mais ils restent complexes à maîtriser (gestion semi-automatique de la mémoire, pointeurs, volubilité [4]) et nécessitent de bien connaître le fonctionnement de la machine. Leur complexité et leur volubilité est génératrice de bugs.[4]
Peut-on considérer, qu'outre les habitudes et les coûts de migration, le fait que les langages haut niveau soient lents[5, 6 ?], reste des freins à leurs développement dans de nombreux cas (pour des applications serveurs par exemple) ? Ou peut-on considérer qu'étant donné que l'on dispose d'une puissance de calcul très confortable, des langages produisant du code relativement lent sont suffisants ?
À l'heure où les processeurs deviennent nativement multi-thread et/ou multi-core, les langages bas-niveau ne vont-ils pas devenir prohibitifs en coûts de développement, car devant gérer la programmation parallèle "à la main" ? [1,2,3]
Ou doit-on compter sur des compilateurs permettant de cacher cette complexité de la programmation parallèle (ADA95) ?
Il est à parier que ces paramètres seront très importants dans les choix technologiques futurs et dans l'évolution de la réussite des projets informatiques.
Problématiques du multi-core :
[1]http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)
Faut-il adapter l'enseignement à la programmation parallèle ?
[2]http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)
[3]http://www.onversity.net/cgi-bin/progcafe/cafetted.cgi?Eudo=bgteob&(...)
On constate qu'avec le temps, le nombre de projets informatiques réussis augmente :
1995 : Succès 16% ; Mitigés 53% ; Échec 31%
2000 : Succès 28% ; Mitigés 49% ; Échec 23%
2004 : Succès 29% ; Mitigés 53% ; Échec 18%
(source : http://www.agentsolo.com/membre/llconseils/capsules/9322.jsp(...) )
La part de succès mitigé (dépassement du budget, du temps imparti, cahier des charges insuffisament respecté) reste à peu près inchangée.
Je n'aborde pas les problématiques et technologies de spécifications qui sont pourtant très importantes, c'est un tout autre débat. Je m'intéresse à l'outil final permettant la métaphorisation de l'expression du besoin, le langage.
La distinction haut niveau / bas niveau s'effectue principalement sur la gestion automatique de la mémoire, car comme le dit Joel Spolsky "The real significant productivity advance we've had in programming has been from languages which manage memory for you automatically. It can be with reference counting or garbage collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of scripting languages. "
[4]http://www.joelonsoftware.com/articles/APIWar.html(...)
Par extension, on peut mettre dans cette catégorie les langages permettant une plus grande productivité, par exemple de par une plus grande abstraction.
Globalement, les langages de très haut niveau sont assez lent parce que les techniques de compilation ne permettent pas d'optimiser le code de façon à être plus proche de la machine, bien que cette tendance ait l'air de s'infirmer lentement :
[5]http://linuxfr.org/2005/05/19/18959.html(...)
[6]http://shootout.alioth.debian.org/benchmark.php?test=all〈=all(...)
Néanmoins, Java et C# qui s'imposeront de force dans l'industrie restent des langages dont le compilateur produit du code assez lent. Je ne saurais dire si c'est un choix des éditeurs ou si cela est intrinsèque aux technologies utilisées par les compilateurs.
En effet, les langages objets s'imposent, mais à part SmartEiffel et Lisaac, aucun ne résoud la liaison dynamique coûteuse en performance (par vidage du cache du processeurs et impossibilité d'inliner le code). SmartEiffel n'a pas l'air d'être prêt à s'imposer malgré une maturité grandissante. Il reste un langage universitaire.
On peut entendre de tout : "Non, la lenteur du code produit par les compilateurs est secondaire car nos machines sont maintenant très puissantes" ou au contraire "Oui, de nombreux logiciels gâchent les performances disponibles, quand d'autres (logiciels serveurs, jeux, logiciels graphique exigeants) nécessitent des temps de réponse très courts".
Peut-on considérer que ce iatus est central en informatique, ou tend-il à disparaître ?
Pour s'enfoncer plus loin dans le débat, il faut le contextualiser avec l'évolution du matériel où l'on se trouve dans une situation où les fabriquants de processeurs "ne savent plus quoi faire" du nombre de transistors sans cesse en augmentation exponentielle. Résultat, on se tourne vers le multi-core et le multi-thread.
Des questions fusent alors :
- doit-on adapter l'enseignement afin d'apprendre la programmation concurrente ?
- doit-on compter sur des compilateurs capable de masquer la concurrence par le haut niveau (un peu comme ADA) ?
( http://ada.developpez.com/cours/enseigner/(...) section "Deux exemples de programmation concurrente")
Reste qu'on peut espérer de nouveaux paradigmes de développement ainsi que nous y invitent Jaron Lanier :
http://java.sun.com/features/2003/01/lanier_qa1.html(...)
http://java.sun.com/features/2003/02/lanier_qa2.html(...)
A suivre...
# Lien manquant
Posté par Ontologia (site web personnel) . Évalué à 2.
http://www.onversity.net/cgi-bin/progcafe/cafetted.cgi?Eudo=bgteob&(...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Lien manquant
Posté par Antoine . Évalué à 8.
Je trouve naïf de penser qu'avec de nouveaux outils on résoudrait tous les problèmes, même les plus mal posés.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Lien manquant
Posté par woopla . Évalué à 10.
Le problème des crayons, c'est que la mine peut se casser, et qu'il y avait un risque de se prendre des bouts dans l'oeil ou de causer des courts-circuits (ben oui, ca conduit l'électricité le graphite).
Donc une boite américaine, Fisher Pen Co., a créé un stylo et l'a proposé à la NASA, une fois le produit développé sur ses propres fonds. Et ils ont acheté par la NASA.
Depuis, russes et américains utilisent des stylos, parce que c'est plus pratiques.
C'est donc une légende urbaine (ou spatiale, plutôt).
[^] # Re: NASA
Posté par spell (site web personnel) . Évalué à 4.
Le film appola 13, avec tom Hanks, est basé là dessus si je me souviens bien. Pour sauver les gars, ils réunissent quinze cerveaux qui doivent résoudre une contrainte quasiment impossible.
# Pas très clair
Posté par Cali_Mero . Évalué à 10.
Et outre cette mise dos à dos des langages de haut niveau et de bas niveau sur le seul critère de la rapidité (qui est rarement le critère décisionnel entre les deux en pratique) dans sa forme la plus générique (qui n'a pas de sens en tant que tel, il faut voir selon l'application demandée), je vois mal où se situe la "crise du logiciel" dont tu parles.
[^] # Re: Pas très clair
Posté par spell (site web personnel) . Évalué à 6.
elle préfère les languages de haut niveau, car plus facile à mettre en oeuvre.
plus facile de travailler à plusieurs dessus, plus facile à maintenir, plus facile de trouver du personnel etc...
Et en plus de cela, on augmente encore le niveau, en utilisant des bibliothèques pour effectuer des tests automatiquement, des outils pour générer la doc... etc...
Y'en a même qui programme avec des tags XML !
Ca n'empêche pas que dans ma ssii je vois toujours du code de goret, avec des pans immenses de code "Copier-Coller", alors qu'il suffisait de définir une fonction.
(Le pire c'est que c'est sencé être du language objet, et que les gens ne savent même pas faire du procédural)
Alors les languages de bas niveau c'est vraiment quand on peut pas faire autrement.
# lent pas lent.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Un langage de haut niveau lent, est un langage qui fait des vérifications dynamique ou des liaisons dynamiques. C'est juste un moyen de se faciliter la vie.
On peut comparer la vitesse d'un Ocaml proche du C avec l'investissement mis dans gcc ou icc à comparer au compilo Ocaml.
Vu la complexité des cpu actuelles, l'expressivité du code C est bien trop pauvre pour que le compilateur puisse vraiment optimiser.
"La première sécurité est la liberté"
[^] # Re: lent pas lent.
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Tu voulais peut-être dire "Un train sec" ?
[^] # Re: lent pas lent.
Posté par JoeBar . Évalué à 8.
Les insectes sont nos amis, il faut les aimer aussi
Comme nous ils ont une âme
Comme Morback et Moucham'
[^] # Re: lent pas lent.
Posté par salvaire . Évalué à 4.
C, C++, ... -> langage générique -> Assembleur générique -> Assembleurs
Parrot est l'équivalent en machine virtuelle. Je trouve cette approche excellente.
Il serait probablement profitable à tous de porter Ocaml sur Gcc et Parrot.
[^] # Re: lent pas lent.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
# Attention aux assertions
Posté par Miguel Moquillon (site web personnel) . Évalué à 7.
Hum ... un peu présomptueux de ta part de déclarer qu'aucun à part Eiffel (SmartEiffel ici qui n'est qu'une implémentation d'Eiffel) et Lisaac (qui pour l'instant semble abandonné (?)) ne résoud le coût de la liaison dynamique. Il existe un très grand nombre de langages objet et je ne pense pas que tu les connaissent suffisamment tous pour te permettre une telle assertion.
Exemple d'Haskell (qui certe n'est pas réellement un langage objet).
Sinon, quant à la lenteur d'exécution de code des langages de haut niveau, ils peuvent être relative. Voir par exemple le C++ avec Eiffel ; dans l'ensemble, avec la dernière version de SmartEffeil (2.2), c'est kif-kif. Voir aussi Squeak (une implémentation de Smalltalk) qui est pourtant un langage à typage dynamique.
De toute façon, qu'un programme soit écrit avec un langage de bas niveau ne suffit pas pour qu'il soit performant. Voir GNOME par exemple. En effet, avec la complexité des applis et le choix de technologies dans ces langages, ils atteignent leur limites et peuvent être même plus lourds qu'un même programme écrit avec un langage de haut niveau. Déjà, il n'y a qu'à voir, dans la catégorie langages de haut niveau, la différence de perfs entre un programme graphique Java (par exemple Eclipse) avec l'environnement graphique Squeak.
Malheureusement, comme tu le soulignes, ce sont plutôt des langages "lent", aux choix techniques des fois douteuses, qui vont prendre le dessus parce que derrière il y a un veritable rouleau compresseur marketing pour les imposer : Java et C#.
[^] # Re: Attention aux assertions
Posté par qdm . Évalué à 10.
Y a des trolls d'or sur Linuxfr ? Celui là est de toute beauté.
[^] # Re: Attention aux assertions
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Et celui là, il est pas en diamant 36 caras, hein ? :-)
[^] # Re: Attention aux assertions
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
[^] # Re: Attention aux assertions
Posté par Troy McClure (site web personnel) . Évalué à 3.
En voici un: http://kadreg.free.fr/perso/moules/troll-or.jpg(...) , attention il est lourd.
[^] # Re: Attention aux assertions
Posté par norbs . Évalué à 2.
> différence de perfs entre un programme graphique Java (par exemple
> Eclipse) avec l'environnement graphique Squeak.
Pour contredire un peu tout ton post, sache que la couche graphique d'eclipse n'est pas écrite en java
[^] # Re: Attention aux assertions
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Pour préciser nos écris respectifs :
la couche graphique d'Eclipse, SWT, est bien du Java, mais elle est native. Autrement dit SWT est un front-end au-dessus d'un back-end qui est un toolkit natif (Gtk2, Motif, etc.);
Ce qui fait qu'effectivement, l'exécution d'Eclipse est plus rapide que si cette couche était du Swing - on peut comparer par exemple Netbeans 4 et Eclipse (j'ai travaillé avec les deux).
Pourtant, malgré cela, Eclipse (ou tout autre programme Java) reste plus lourd que l'environnement graphique Squeak qui lui est codé tout en Smalltalk ! Ce qui prouve encore que l'on peut trouver des grandes disparités entre les langages ou frameworks dits de haut niveau, et que ce n'est pas toujours les meilleurs technos qui s'imposent.
[^] # Re: Attention aux assertions
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
ouch. Sachant la réputation de lourdeur de squeak, j'ai très peur d'un coup.
"La première sécurité est la liberté"
# Lent ?
Posté par Pierre Tramonson . Évalué à 7.
Code lent, langage lent ?
Mais ça ne veut rien dire ! Lent pour qui ? Pour l'utilisateur d'une IHM ? Si l'appli est bien codée, c'est imperceptible avec ces deux langages !
Lent pour l'exécution d'un algo complexe ?
C'est possible mais là encore je te trouve une foultitude de benchs qui montrent que c'est pas plus lent que ça, tu perds quoi, allez 5/10% dans les cas les plus défavorables et tu en gagnes quelques % dans les cas les plus favorables des algos...
Et tu gagnes combien en facilité de maintenance, fiabilité, absence de fuite mémoire, évolutivité, lisibilité par d'autres développeurs par rapport à du C ou C++ ?
Java et C# s'imposeront de force dans l'industrie
Tu y bosses ? Parce qu'ils s'y sont déjà imposés (en tout cas Java).
Là où je bosse la question ne se pose même plus, on ne fait plus de C, de C++, de VB, d'ASP. (je ne suis pas éditeur, ni dev de driver).
Par contre on fait toujours du Cobol :p
[^] # Re: Lent ?
Posté par salvaire . Évalué à 5.
[^] # Re: Lent ?
Posté par Romain Be. . Évalué à 3.
Allons, tout le monde devrait savoir que ce sont bien les decideurs qui font les choix technologiques, meme si souvent ce sont les dernieres personnes au courant de la mecanique de la bestiole.
Alors parlons en termes de decideurs:
-- TTM ou encore le fameux Time To Market
-- ROI alias le Return Over Investisment
Et bien dans ces deux cas, les languages dits 'haut' ont un argument de choc: plus vite developpe, plus vite deploye -- pas besoin de dev specifiques sur chaque archi ni de refaire sans cesse les memes taches rebarbatives et 'time consuming' ;)
Apres le client, dans une dite 'industrie' qui se cherche pas mal encore, il est souvent condamne, faute de connaitre lui aussi les reelles possibilites, a acheter ce que l'editeur lui propose, au tarif qu'il lui propose, pourvu que ca arrive vite et que ca couvre son besoin.
Apres il y a les LL qui prennent souvent plus de tps ds leur dev mais dont les contraintes sont souvent posees et resolues par les dev eux mm, cad ceux qui connaissent les reelles possibilites, et qui n'ont pas d'investissement a valoriser :)
Romain
# Facteur limitant du projet
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 10.
Il y a sur le marché un bon paquet de baltringues qui se prétendent experts, développeurs confirmés, consultants ou chefs de projets ou DSI et envoient des projets dans le mur par leur incompétence. Dans ce cas là, il faut un "manager" qui fasse son boulot, mais le plus souvent, il fait le "mort". (Principe de Peter, non appropriation du projet, difficulté du marché de l'emploi, manque de courage). Toute ressemblance ...
Haut ou bas niveau, pas de solution miracle, il faut choisir en fonction de nombreux paramètres. Il est important d'avoir une bonne "culture générale" des langages, beaucoup oublient souvent les critères de maintenance et portabilité.
Les problématiques paralèlles, bien que passionantes, n'impactent véritablement qu'une niche de développements spécifiques. Hors le calcul intensif, la gestion du "parralèlisme" est le plus souvent effectuée dans l'OS ou la DB.
Si ces sujets t'intéressent, il existe des filières dédiées qui offrent une formation de qualité.
Il me semble avoir lu que MS s'intéresse à MPI. Vont ils nous sortir un
MPI-C#?
Enzo Bricolo
[^] # Re: Facteur limitant du projet
Posté par spell (site web personnel) . Évalué à 4.
Un prof me disait qu'il fallait mettre le meilleur techniquement en tant que chef de projet.
Mais moi je pense que c'est pas à cause des difficultés techniques que les projets se cassent la gueule. C'est à cause d'une mauvaise spécification.
Je vois tous les jours les chefs de projets qui courent partout pour boucher les fissures, et jamais ils ne prennent le temps de réfléchir à qu'est ce qui a causé la fissure, et comment faire pour que cela ne se reproduise pas. Tôt ou tard, ils ne pourront plus boucher les fissures.
[^] # Re: Facteur limitant du projet
Posté par kesako . Évalué à 4.
Avis typique d'un prof.
J'ai ete jadis dans une equipe avec un tres bon CP , pas vraiement fort en programation., mais a marchait super bien. Puis il a ete muté ailleurs et c'est le meilleur techniquement de l'equipe ( un kador parmis les kadors !) qui a pris sa place. Une catastrophe , il ne savait pas communiquer et n'avait dailleurs pas envie . Ca s'est terminé en eau de boudin : tout le monde est parti... pourtant les spec etaient au carré , le produit magnifique, etc...
[^] # Re: Facteur limitant du projet
Posté par Pierre Tramonson . Évalué à 2.
# Justement, j'y pensait toute l'après-midi...
Posté par iug . Évalué à 5.
http://www.c2.com/cgi/wiki?SmugLispWeenie(...)
[^] # Re: Justement, j'y pensait toute l'après-midi...
Posté par Matthieu Lemerre (site web personnel) . Évalué à 4.
Ces langages permettent un developpement beaucoup plus rapide et sont meme plus rapide a l'execution... Ces communautes grincent des dents lorsqu'on entend parler des "nouvelles" features du moment: compilateur just in time, garbage collection, templates... Qui existent dans Lisp depuis 30 ans.
Comme le dit Paul Graham:
"All languages are slowly moving toward Lisp", alors, pourquoi attendre? :)
http://l-lang.org/ - Conception du langage L
# programmation concurrente enseignée
Posté par gradix . Évalué à 3.
Dans ma région, en Suisse, la programmation concurrente est enseignée à toute personne faisant de l'informatique/téléinformatique dans une école d'ingénieurs car effectivement, ce sont des problèmes qui vont prendre encore plus d'ampleur ces prochaines années...
[^] # Re: programmation concurrente enseignée
Posté par iug . Évalué à 7.
Dans mon école, ou l'enseignement était très correct, la moitié au moins de la promo serait infoutue de faire autre chose que du java de mauvaise qualité. Toute les finesses de l'info ne sont pas acquises, et le diplôme est quand même donné : sécurité, système, tolérance aux fautes, parallélisme, programmation de niveau non bas, architecture des programmes.
[^] # Re: programmation concurrente enseignée
Posté par kesako . Évalué à 2.
Des qu'on leur demande du C++ ou du perl c'est la cata...
# La memoire goulot d'etranglement
Posté par cedric . Évalué à 10.
Donc aujourd'hui si tu n'utilises pas correctement ta memoire et ton CPU couche bas niveau tu peux prendre rapidement jusqu'a un facteur 400 (100 dans les acces memoires mal foutu et fois 4 si les acces memoires ne permettent pas de faire du SIMD). Il est vrai que peu d'application le fond correctement. Ainsi sur une base de donnees, exemple dont j'ai vu les resultats aux WTH cet ete, tu peux en optimisant les acces memoires (manipulation par colonne + compression rapide a la vole + vectorisation) obtenir un gain qui permet sur un bete P4 3Ghz de pouvoir avoir des perfs superieurs a celle d'un octo proc IBM... Ca laisse reveur, j'esperes voir ce genre de technique implemente dans SQLite ou PostgreSQL.
Et par experience personnelle, si tu as une application qui est lente commence par optimiser tes acces memoires, c'est souvent la que tu gagnes le plus et le plus rapidement. Le probleme c'est que tes langages de haut niveau considere souvent la memoire comme une zone ou il ne faut pas laisser les gens reflechir, car c'est trop difficile, mais c'est pourtant la que tu peux gagner le plus. Tu vas me dire que les delais tout ca augmentent, que forcement on peut pas optimiser. Mais on oublie un truc, on fait du logiciel libre ici, donc il y a une reutilisation importante du code et des mecs motives juste pour optimiser...
Donc tes langages hauts niveaux n'ont finalement d'interet que sur le court terme ou tu veux absolument courrir face a un concurrent et que tu n'as pas de personne suffisament competente pour avoir le resultat que tu veux autrement. Mais dans le logiciel libre, je suis convaincu que ce n'est pas le meme objectif.
[^] # Re: La memoire goulot d'etranglement
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Par contre, le choix de ces appels et quand peut permettre des améliorations de performance. Ainsi par exemple, sous Linux et d'autres Unix il est plus "performant" de faire appel à mmap une fois pour toute pour allouer toute la mémoire qu'aura besoin l'application et de l'utiliser pour les variables à allouer dans le tas que d'utiliser de multiples malloc.
Dans ce cas, par exemple, les langages de haut niveau qui gèrent automatiquement la mémoire sont dotés d'algorithmes (soit le runtime soit le compilateur) très poussés pour gérer de façon à peu près optimale la mémoire (pour les compilateurs par une analyse sémentique en une ou plusieurs passes).
De la même façon, depuis les années 80 (le garbadge collecting existe bien avant ces années), les algorithmes et les techniques de garbadge collecting se sont bcp améliorés.
Aussi, de nos jours, les problématiques de gestion de mémoire sont moins pertinantes qu'il y a quelque temps et ne méritent plus que l'on s'y consacre autant de temps avec des langages de bas niveau (excepté prog système, embarqué, noyau, ...).
[^] # Re: La memoire goulot d'etranglement
Posté par BAud (site web personnel) . Évalué à 3.
/me se demande s'il va pas faire une pétition pour libérer la mémoire ;-)
[^] # Re: La memoire goulot d'etranglement
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
[^] # Re: La memoire goulot d'etranglement
Posté par boris . Évalué à 3.
Ensuite, c'est pas très correct pour les devs, ce que tu dis là. Ils ont certainement mis les free/delete là où il le fallait, et ils n'y sont pour rien si le tas est fragmenté.
Mais une fois de plus, on s'en balance. C'est l'espace d'adressage qui fait 200Mo, c'est tout.
[^] # Re: La memoire goulot d'etranglement
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: La memoire goulot d'etranglement
Posté par Damien (site web personnel) . Évalué à 2.
En Smalltalk les Array sont pas prévues pour être redimensionnées ; je suppose qu'elles sont implémentées à la C avec toutes les données bien contigues en mémoire. Par contre évidemment ça contient des références d'objets donc c'est intéressant seulement pour les objets immédiats comme les petits entiers ou les caractères. Peut-être qu'il y a d'autres astuces, je sais pas.
On peut quand même redimensionner une Array, mais c'est fait violemment : on en alloue une autre, on copie le contenu, et on met à jour la référence. Vous avez bien lu, la référence change, c'est pas une double indirection. La représentation du tas est prévue pour être facilement parcourue/mise à jour et les objets peuvent bouger en mémoire. Ça permet en particulier au GC de défragmenter, et de garder une image compacte.
Disclaimer : Prendre avec des pincettes ce que je rapporte ci-dessus, c'est ce que j'ai compris/intuité d'une courte exploration du langage, je sais pas si ça marche aussi bien que ça pourrait mais les idées sont intéressantes.
[^] # Re: La memoire goulot d'etranglement
Posté par ckyl . Évalué à 7.
La gestion mémoire ce n'est pas simplement faire des couples malloc/free. C'est savoir gérer ses données pour optimiser un paramètre qui peut être la taille ou la vitesse d'exécution. Ce qui n'a pratiquement rien a voir avec la VMM qui basiquement ne te fournit qu'un espace d'adressage.
C'est au langage de se débrouiller avec cette plage de mémoire pour l'utiliser au mieux possible. Par exemple si tu allignes pas tes données sur un mot machine soit ca sera horriblement lent soit ca explosera. La gestion mémoire est donc au contraire extrêment interessante quelle soit réalisée par un compilateur ç la main ou je ne sais. Un cache miss c'est cher, une lecture sur le disque n'en parlons même pas...
Il y a aussi la gestion du code pour tirer au maximum parti du fonctionnement des CPU mordernes et leur eviter d'avoir un pipeline vide ou à flusher toute les 12 instructions. Bien évidement ca n'a aucun interet dans 99% des projets; mais il reste les 1% ou ces optimisations vont te faire gagner un facteur 50 ou 100.
Toutes ces choses sont très difficiles à réaliser avec un langage de haut niveau. Et même en bas niveau y'a pas grand monde qui a les compétences pour pondre un code rapide, portable et maintenable. Et bien sur cela à un coup qui est de réinventer la roue à chaque fois alors que tu pourrais utiliser des fonctionalités très puissantes. Il reste à définir tes priorités chose qui est bien difficile.
[^] # Re: La memoire goulot d'etranglement
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Je suis d'accord que la gestion de la mémoire ce n'est pas simplement faire du malloc/mmap/... mais aussi gérer ses données comme par exemple sa taille ... qui peut dépendre de l'architecture matérielle sous-jacente. je suis d'accord aussi que c'est au langage de gérer au mieux la gestion mémoire en fonction de l'architecture sous-jacente. Mais là, contrairement à ce que tu dis, les langages de haut niveau ne sont pas pour autant mis hors jeu, au contraire...
De plus, ce qui fait gagner la majorité des cas en performance, c'est l'optimisation globale et non locale.
Et sur ce point, un certain nombre de langages de haut niveau gère très bien cela, et surtoût mieux que nous pourrions le faire dans la plupart des cas. Je m'explique sur ce point. Dans des applications complexes, tu peut effectivement avec un langage de bas niveau optimiser un certain nombre de choses, mais cette optimisation se fait localement et non globalement ; autrement dit, tu as optimisé les parties de l'application qui finalement ne seront peut-être utiles que dans 20% dans le meilleur des cas tout simplement parce que ton application est trop complexe pour avoir un aperçu globale de ces optimisations (leur pertinence, etc.). Le tout se durcit si en plus ton application doit être multi-plateforme : la particularité de chaque plate-forme doit être prise en compte ! Ceci est particulièrement pertinent avec les SGBDR.
Faire de l'optimisation pour faire de l'optimisation ne sert à rien ! L'optimisation est un moyen, pas un but en soit.
Au jour d'aujourd'hui, les compilateurs de certains langages haut niveau (malheureusement pas ceux que l'on utilise au quotidien) ont atteint une grande maturité et permettent d'écrire des programmes multi-plateforme d'une grande efficacité, en tout plus éfficace et bug free que si on avait à les écrire en optimisant nous même avec un langage de bas niveau (qu'il soit ou non équipé d'un compilateur performant). Et le progrès de ce côté là continue.
Par contre, je suis d'accord que ce n'est pas parce que ton langage, ton framework ou autre permet d'optimiser globalement ton appli en fonction de l'architecture sous-jacente que tu dois pour autant ne pas te préoccuper dans certains cas des problématiques d'optimisation de ton code. De la même façon, ce n'est pas parce que tu programmes avec un langage de bas niveau (donc soit disant plus performant) ou de haut niveau (il sait faire les optimisations mieux que moi) que tu dois choisir des technos ou faire une conception à chier qui finalement conduit à produire un bousin (souvent parce que c'est la mode).
[^] # Re: La memoire goulot d'etranglement
Posté par cedric . Évalué à 9.
Or on alloue quand meme de la memoire pour l'utiliser et c'est l'utilisation qui compte. Si tes donnees au moment ou tu les utilises sont completement disperse en memoire (fragmente) et non aligne, et bien tu vas facilement te prendre un facteur 100 voir de plus en plus grand avec le temps puisque le rapport entre la vitesse du CPU et la latence memoire a tendance a grandir.
Et pour optimiser quelque chose, il n'y a qu'un seul moyen que lorsque tu compiles, tu compiles l'integralite de ton univers (ou en tout cas tout ce qui produit et utilise de la memoire, ce qui revient au meme). A ma connaissance, seul l'eiffel peu proposer se genre de mecanisme. Maintenant j'ai de gros doute qu'ils aient implemente la capacite a changer les algorithmes et les structures memoires pour optimiser de maniere globale ton programme.
Et contrairement a ce que tu dis, si tu arrives a faire cette optimisation globale, tu aura un gain collossal souvent sous estime. Maintenant, si tu choisis un langage qui ne te permettra jamais d'optimiser ton application (en gros qui ne te donne pas la main sur la manipulation memoire), il va arriver un moment ou tu vas te dir que entre rajouter une nieme fonction avec peu de demande ou optimiser ton appli pour qu'elle tourne mieux sur de petite machine, c'est l'optimisation que tu vas choisir. Et la soit tu peux faire des optims globales qui payent (et l'optimisation memoire ca paye bien), soit tu ne peux pas. Et dans ce cas, si tu es en competition avec des gens qui eux le peuvent, tu devra tout redevelopper. Autant dire que tu vas perdre sur le long terme.
C'est pourquoi d'apres moi les langages qui ne permettent pas ce genre d'optimisation doivent rester cantonner sur du RAD sans interet sur le long terme. D'ailleur ca explique le peu de prise des langages dit haut niveau dans le domaine du libre, ou une bonne partie des developpeurs aime bien optimiser (et oui, pour certain c'est un but...). Maintenant dans l'industrie, je veux bien croire que les productions a court terme sont plus importante, mais ils finiront toujours par ce faire depasser.
[^] # Re: La memoire goulot d'etranglement
Posté par mdlh . Évalué à 8.
Pour eviter les trolls, je ne vais pas preciser l'architecture sur laquelle je travaille. Mais je voudrais juste dire que je suis assez souvent face a des cas ou 30% du temps d'execution de l'appli est perdu du a des problemes de cache. Pour les fixer, il faut soit:
- reduire les latences en travaillant sur l'organisation des donnees en memoire de telles sortes que les donnees susceptibles d'etre utilisee en meme temps soient sur des espaces contigus
- rendre le programme tolerant a ces latences en utilisant le fameux "Prefetch", ce qui necessite de pouvoir calculer en avance les adresses memoires utilisees.
Dans les deux cas:
- Il faut modifier le code source
- Il faut avoir un minimum de control sur l'organisation memoire des donnees manipulees.
Cela a deux consequences:
- On perd en lisibilite du code. Meme si on peut trouver des solutions "propres", le nouveau code correspond a du "bruit" par rapport a l'algorithm lui meme
- Tous les langages ne le permettent pas. Plus specialement les langages de haut niveau ne le permettent pas.
Certes, tout le monde y gagnerai si cela etait automatise de telle sorte que cela ne soit pas apparent au niveau du code source. Malheureusement c'est loin d'etre le cas ou du moins ce n'est pas encore efficace.
# haut niveau performant
Posté par bobefrei . Évalué à 5.
Que dire alors du language D qui possède à la fois une gestion automatique de la mémoire et permet de faire du "aussi bas niveau" que le C?
[^] # Re: haut niveau performant
Posté par Troy McClure (site web personnel) . Évalué à 2.
Qu'il est bien bandant. Y'a même un type qui essaie de faire un frontend D pour gcc:
http://home.earthlink.net/~dvdfrdmn/d/(...)
# intéressant
Posté par BAud (site web personnel) . Évalué à 10.
1. (rappel) "toute solution n'est pas informatique"
2. ton lien http://www.agentsolo.com/membre/llconseils/capsules/9322.jsp(...) donnant les pourcentages de réussite de projets informatique prend résolument une approche utilisateur (MOA diraient certains... Maîtrise d'OuvrAge en clair), ce qui ne transparaît pas du tout dans ton post
3. ton post est l'évidence de l'approche nombriliste de certains informaticiens : se poser la question de la technique, plutôt que celle de ce qu'il faut faire, ce que le produit va réaliser (après le comment en découle de manière logique).
En fait, l'outil informatique est souvent vu comme la panacée, la solution miracle.
Malheureusement (ou heureusement), la finalité de l'informatique est d'effectuer un traitement automatique : si ce traitement ne peut être décrit par les utilisateurs - avec ses règles, pour être appliqué méticuleusement - ce n'est pas le développeur qui ne connaît pas forcément le métier qui va pouvoir le faire, encore moins le programme qu'il aura pu pondre, quel qu'en soit le langage.
Combien je vois d'utilisateurs arriver avec "une solution technique à mettre en place" ! Là où je ne leur demande que "quel est votre besoin ?". Forcément, je ne suis pas content : ils font mon boulot, mais pas le leur, ça ne peut pas marcher ;-) (le pire c'est que c'est loin d'être faux...).
voilà je vous laisse élaborer ;-)
[^] # Re: intéressant
Posté par Papey . Évalué à 3.
Pour répondre à son besoin, il ne te reste plus qu'à faire de l'ingénierie inverse sur son pseudo-code MS Excel pour en déduire les vrais besoins, et lui demander confirmation derrière pour pouvoir commencer à bosser. Le bonheur.
[^] # Re: intéressant
Posté par BAud (site web personnel) . Évalué à 2.
Je passe sur les 600 "applis" recensées sur les postes client, celles en access non portables d'une version à l'autre (sympa quand tu changes l'os et les versions d'applis supportées), et le pompon à celle qui demande l'installation d'une base Oracle sur le poste client (ah bah vous nous aviez pas dit qu'on devait pas l'installer côté client et vu que la norme c'est Oracle, bin nous on a pris, ... grumpf).
# I had a dream...
Posté par qstone . Évalué à 3.
- une fonction xxxx me renvoie 'vrai' ou un code d'erreur, et je ne teste jamais (paresse)
- je présuppose que mes variables d'entrée, quelles que soient leur provenance, sont correctement formées (grosse paresse)
- en codant, je ne parviens pas à gérer la multiplicité des cas pouvant se produire, en j'en loupe (limite de mon ptit cerveau)
(Je précise que même que je ne fais pas ces erreurs partout, tout le temps (non mais). Mais quand j'en fais, ça vient de là).
Ma liste est certainement partielle, ce serait intéressant de la compléter!
Et comment résoudre ça? Les tests systématiques sont longs à écrire, pas franchement marrants, et alourdissent le code (à la lecture surtout).
<fantasme>
Je rêve d'un IDE sans code (enfin si, mais beaucoup moins), où programmer se résumerait à : expliciter les flux d'entrée/sortie, et définir les actions en fonction des cas possibles...
Bon avant de recourir à des substances psychédéliques pour me suivre dans mon raisonnement, lisez plutôt cet exemple :
Objectif : réaliser une application permettant à un utilisateur de saisir son nom et sa date de naissance, puis d'afficher 'bonjour'+son nom, ou 'bon anniversaire'+son nom si c'est le cas.
J'ai une interface, 2 champs de saisie et un bouton pour valider (même si je préfèrerais un niveau d'abstraction + haut), un flux d'utilisateurs venant sur cette interface pour faire de la saisie. J'ai aussi un traitement (calcul du message à afficher) et une seconde interface affichant le résultat du traitement. Jusque là ça va.
Je construis mon appli : 1ère interface, 2 zones de saisie, un bouton qui valide, et j'ajoute le flux d'utilisateurs.
Avec les règles actuelles, d'IDE voit que mes users peuvent saisir (ou pas) ce qu'ils veulent dans 2 champs, cliquer sur le bouton, et bien sûr arrêter d'utiliser mon appli. L'IDE injecte des entrées possibles (=simule des utilisateurs) qui font un nombre aléatoire d'actions parmis celles possibles, puis s'arrêtent. Il conclut bien vite que mon programme ne fait rien et que 100% des utilisateurs quittent le programme là, sans qu'il ne se passe rien.
Puis je crée mon calcul (vide), et j'associe le clic sur le bouton à l'action 'envoie les données des 2 champs au calcul'. Pouf l'IDE me trouve 2 cas distincts : celui des utilisateurs qui cliquent, et celui des utilisateurs qui cliquent pas. Je commence mon calcul (là, du code: si date saisie=date du jour, alors message commence par "bon anniversaire " sinon "bonjour";ajouter le nom saisi au message).
En créant ma condition 'SI', l'IDE me trouve (toujours par simulation) 3 cas : test vrai, test faux, problème de prérequis (je ne suis pas sûr que la date saisie est bien une date, et qu'elle répond au format voulu). Il (l'IDE) me dit que pour 99% des personnes déclenchant le calcul, il ne se passera pas ce que j'ai prévu. A moi maintenant de rattacher ce flux à quelquechose (message "saisie incorrecte"), ou de faire en sorte que ce flux n'existe plus (tests à la saisie).
En gros à l'aide de tests successifs et aléatoires, l'IDE de mes rêves m'aide à identifier tous (ok beaucoup) les cas possibles, et à les gérer. Mon programme n'est plus orienté objet ou procédural, il dépend du flux utilisateur, et ça tombe bien, parce que c'est comme ça qu'il fonctionne, et c'est comme ça que les gens tombent sur des bugs.
</fantasme>
<retour sur terre>
Waouh, ça a l'air bien complexe, assez lourd à la longue (pour un programme de 10 millions de lignes de code, ça en fait des cas à tester!), ça demande un moteur de génération de code source (ou compilateur) pas évident, etc.
</retour sur terre>
Mais si c'était finalement faisable, à votre avis, ça vaudrait le coup ou pas ? Est-ce qu'il 'suffit' de faire ça pour diminuer fortement, voire éradiquer, les bugs et autres nuisances ?
[^] # Re: I had a dream...
Posté par Yusei (Mastodon) . Évalué à 5.
Ce qui pose un probleme: admettons que tu veuilles ecrire un interpreteur pour un langage quelconque. Ton IDE va devoir simuler un utilisateur qui tape un script aleatoirement, mais comment va-t-il faire pour distinguer un comportement valide d'un comportement invalide ?
Admettons que le script qu'il produit soit conforme a la syntaxe du langage, l'IDE va pouvoir observer les cas suivants:
1- l'interpreteur execute le script et produit un resultat
2- l'interpreteur execute le script mais s'arrete sur une erreur
3- l'interpreteur ne s'arrete pas
Seul le cas 2 peut-etre traite efficacement: on a trouve une erreur, il faut la resoudre. Dans le cas 1, on ne sait pas si le resultat obtenu est valide, dans le cas 3, on ne sait pas si le fait que l'interpreteur ne s'arrete pas est normal ou non.
[^] # Re: I had a dream...
Posté par qstone . Évalué à 4.
Encore une fois, l'outil à tester-prévoir-gérer 100% des cas n'est pas encore écrit (j'imagine ça sur des traitements "lourds" : imagerie 3D, calculs scientifiques etc., où on ne peut pas faire à l'avance tous les calculs que le logiciel pourrait faire au long de sa vie, c'est aberrant)
D'où la question subsidiaire : si on ne peut pas tout tester, comme être fiable à 100% ?
[^] # Re: I had a dream...
Posté par Yusei (Mastodon) . Évalué à 6.
Je ne suis pas sûr d'avoir correctement compris ton idée, mais si tu cherches un logiciel qui puisse valider tout seul un programme quelconque, c'est impossible.
Si tu es obligé de changer la grammaire du langage compris par l'interpréteur que tu essayes de coder, alors tu te retrouves dans un cas où ton programme final sera différent de celui que tu voulais faire au départ. Par exemple si tu voulais coder un interpréteur LISP, et que ton IDE-magique t'oblige à restreindre la grammaire, à la fin tu n'auras pas un interpréteur LISP.
Plus généralement, tu ne peux pas systématiquement contourner le problème de l'utilisateur qui rentre une donnée qui fait boucler le programme. Ton IDE-magique ne peut pas toujours décider "ah mais dis donc, c'est une boucle infinie ça, il faut corriger".
Il y a des outils de preuves formelles de programmes, comme Coq, mais c'est très chiant à utiliser, donc ce n'est pas une solution pour ceux qui ont la flemme de tester une valeur de retour :)
Dans un premier temps, tu devrais essayer la programmation par contrat, c'est très efficace pour attraper la plupart des gros bugs, et ça demande assez peu d'effort de la part du programmeur. Par exemple en Eiffel, tu peux déclarer des prérequis sur tes fonctions ("ce paramètre là doit être compris entre 2 et 56"), une fonction peut promettre des choses aux autres ("la valeur que je retourne ne dépassera jamais 56"), et on peut aussi déclarer des invariants ("la valeur de cette variable ne sera jamais supérieure à 42"). En pratique si tu n'as pas une batterie de tests, tu ne peux pas être sûr qu'une de ces conditions ne sera pas violée, mais tu peux être sûr que si c'est le cas, tu n'auras pas de mal à trouver l'erreur.
[^] # Re: I had a dream...
Posté par vieuxshell (site web personnel) . Évalué à 2.
Par exemple si tu as une fonction qui prend en param un entier (sans prendre en compte les considerations algorithmiques) tu lui file sizeof(int) et sizeof(int+1). L'exemple est volontairement simpliste, mais tu peux considerer que ton code est capable de manger tout les entiers qui passeront par là.
Le problème réside dans la définition des limites.
L'exemple ci-dessus va laisser passer un cas d'erreur si l'entier en question doit être utilisé pour diviser un autre nombre.
Alors de là a valider un interpreteur ....
[^] # Re: I had a dream...
Posté par golum . Évalué à 6.
1-Le traitement des exceptions a été inventé pour les paresseux comme toi et moi.
2-Les préconditions sont là pour ça
3-il existe des outils de couverture de code et des packages de test s unitaires pour te facilter la vie
conclusion arrêtes de coder en C ;-) <\TROLL>
[^] # Re: I had a dream...
Posté par Damien (site web personnel) . Évalué à 2.
En fait, les contrats en général... c'est très utile pour localiser les bourdes dans le code. Il faut juste un moyen propre de les exprimer et de compiler sans pour les versions finales. Évidemment en Eiffel c'est facile :)
conclusion arrêtes de coder en C
Exactement...
[^] # Re: I had a dream...
Posté par vieuxshell (site web personnel) . Évalué à 4.
Là, tu définis ton probleme dans un langage de haut niveau, qui est sensé te generer le code qui va bien et les tests qui vont bien également (Ou alors que les tests dans le cas d'une appli existante ou d'une appli que tu souhaites voir fonctionner).
Une autre piste moins IDE:
Via UML tu peux définir tes données (class), tes flux de d'informations (sequence), les états prévus de ton appli (statechart), les cas d'utilisation.
Je pense qu'il y a moyen, à partir de ca, de genrer une bonne partie de code générique et validable.
Si en plus tu generes dans un langage objet, tu pourras redéfinir les classes importantes pour y faire des optim.
[^] # Re: I had a dream...
Posté par billbaroud . Évalué à 1.
Ca c'est du soft qui envoie du bois...
<petite pensée de soutient aux etudiant en iup info à brest :D>
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.