Pas de problème. Étant donné que j'ai pris la remarque du dessus pour un mauvais troll, j'ai enchaîné. Et puis, c'est la classe d'avoir une récompense à son nom. :-)
« Ce n'a été un évenement mondial que parce qu'on a bien voulu le montrer comme tel. Et puis dire que ça a eu une portée mondiale alors que ça n'a touché qu'une ville des Etats-Unis, c'est un peu exagéré. »
Pardon ? D'une, dans le WTC, différentes personnes de différentes nationalités travaillaient là-bas : c'était un centre d'affaires international. De deux, ça a eu un véritable impact au niveau mondial, et le nier, en disant que « ça n'a touché qu'une ville des Etats-Unis », c'est un discours à la limite de celui où l'on parle de « détail de l'histoire ». Seulement comme ça touche les USA, c'est moins grave, n'est-ce pas ?
Enfin, estimer que la portée symbolique de cet attentat est nulle, c'est faire preuve d'un manque d'ouverture d'esprit flagrant.
« Donc si on part de l'équation symbolique "1 centrale = 1000 éoliennes" mais que l'on prend en compte les points précédents on peut arriver à quelque chose comme "1 centrale = 600 éoliennes" par exemple. »
Non, car si toutes tes affirmations sont vraies, comme on ne sait pas si on parle de l'énergie produite par une centrale directement à sa « sortie » ou bien s'il s'agit de l'énergie qu'on peut consommer dans les ménages, l'effet n'est pas le même tu en conviendras (le posteur précédent n'a pas précisé).
De plus, tu donnes arbitrairement une diminution de 400 éoliennes, mais tu n'en sais rien (moi non plus du reste). Ca pourrait être plus, ça pourrait être beaucoup moins.
« Dans le cas de Linux, on a un megalomaniaque qui decide (avec ou sans justification) ce qui est bon ou non »
C'est tout bonnement faux. Linus le dit lui-même : l'une des premières choses qu'il a dû apprendre à faire, c'est déléguer. Au final il a le mot de la fin si « en-dessous » ils n'arrivent pas à se mettre d'accord quant à certaines orientations techniques, oui. Un peu comme un chef de projet, quoi. Il fait confiance aux gens à qui il délègue.
Le côté mégalomane, je ne le vois pas vraiment. A-t-il un ego très fort ? Oui, assurément. Et là encore, c'est l'un des premiers à dire quelque chose du genre "Le plus simple pour être célèbre, c'est de commencer quelque chose, et de laisser tout le monde compléter l'embryon de projet - en ensuite d'en récupérer tout le mérite" (ce à quoi, Larry Wall, papa de Perl, aurait répondu « vas-y mon frère, dis-leur ! »)
J'ai dû être un peu trop cryptique, donc je vais essayer de mieux m'expliquer : dans une base de données orientée XML, les données peuvent très bien être traduites en interne par des structures de données tout à fait « binaires » : il faut juste qu'il existe une DTD ou un schéma XML disponibles (et comme on parle de gros documents, il serait étonnant que ça n'existe pas).
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
<!ELEMENT adresse (rue,zipcode,ville,pays)>
<!ELEMENT rue (#PCDATA)>
<!ELEMENT zipcode (#PCDATA)>
<!ELEMENT ville (#PCDATA)>
<!ELEMENT pays (#PCDATA)>
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
for $x in doc("mes_personnes.xml")/identite/adresse return $x/rue
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.
Par définition, lorsque tu optimises, tu risques de perdre en lisibilité.
L'optimisation intervient tout à la fin, quand tu as déjà fait les bons choix pour ton logiciel (par exemple en utilisant un tri rapide ou un tri fusion pour trier tes éléments). Choisir un bon tri n'est pas faire de l'optimisation, c'est faire de bons choix de conception.
Ce que j'appelle « optimisation » pourrait sans doute plutôt être appelée « micro-optimisation » : on se rend compte qu'on passe 90% du temps dans une boucle, alors on essaie de voir si on ne pourrait pas améliorer la façon dont elle s'exécute. Maintenant, si ta boucle est en réalité un tri à bulle, tu auras beau optimiser et gagner 10 ou 20 % en perfs, tu seras toujours plusieurs ordres de grandeur derrière un tri rapide ou fusion.
C'est pour ça que les (micro-)optimisations viennent en fin de développement : on a déjà réglé le plus gros des détails, et on a déjà une application raisonnablement rapide.
Donc, de mon point de vue, optimiser un tri à bulles ou un tri rapide, c'est *toujours* de l'optimisation. C'est juste que dans un cas, tu optimises un truc pas très efficace.
« XML est un format d'échange de données, il peut être utilisé pour exploiter en "temps réel" de petites quantités de données (surtout avec les machines actuelles), mais il n'est pas adapté à remplacer une base de données - surtout lorsque le volume stocké augmente. »
Tu vas vexer beaucoup de chercheurs en SGBD, là. Il ne faut pas confondre la forme finale d'un document XML, le document « plat », et ce qu'est un document XML, à savoir un arbre ordonné et étiqueté. La forme finale, c'est ton fichier « lisible par un humain » (qui a pris deux-trois aspirines avant de lire le fichier de 3000 balises). Mais la base en elle-même fait exactement comme les autres : elle indexe les documents, les noeuds fils, les noeuds parents ...
« Mais stocker en XML, dans un fichier 'plat', des données qui peuvent se montrer volumineuses et sur lesquelles on a besoin d'un accès direct: AMA non. »
Du point de vue d'une BDD, un document XML est un arbre (ou un graphe, si tu utilises les IDREF - mais là t'es déjà bien vicieux ;-) ). Rien n'empêche la base d'avoir cette structure version « binaire » (structure de graphe/d'arbre donc) dans la base, et de ne dumper les fichiers XML que lorsque tu en as besoin. D'ailleurs c'est plus ou moins ce que fait BDB/XML : tu importes tes fichiers dans la base, et il garde le tout chez lui, dans une forme interne qui l'arrange. Ensuite, tu peux faire des requêtes sur la base avec XQuery, et récupérer un document au format XML en sortie.
En ce moment, beaucoup d'efforts sont fournis pour adapter les optimisations connues des SGBD/R vers les SGBD/XML. L'indexation est particulière, car si dans un SGBD/R on a des types fixes, avec des lignes de table de taille fixes elles aussi, XML est un langage semi-structuré : il faut en tenir compte.
« Tous ça, c'était surtout utile avant, quand les compilos étaient cons comme des balais. Aujourd'hui, ils optimisent tellement le code qu'il vaut mieux les laisser faire. »
Ben tout dépend de quel compilateur on parle. :-)
Au risque de me répéter vis à vis de ce que j'ai pu dire dans d'autres réactions, gcc n'est pas (encore) le plus optimisant des compilos, et on peut clairement faire mieux à la main, si on a le temps et la volonté d'apprendre l'assembleur de la machine cible. Alors que pour faire mieux à la main que certains autres compilateurs, il faut se lever très tôt.
« Enfin, un argument sensé que j'ai lu je ne sais plus où:
avec des "hacks" comme ça, tu gagnes un peu, mais ce peu va se réduire avec les années (progrès du compilo/métériel). Par contre, tu perds en lisibilité, et pour toujours... »
C'est vrai. C'est pour ça que les deux grandes règles de l'optimisation sont :
1°) N'optimise pas.
2°) (pour experts seulement) N'optimise pas encore.
L'optimisation vient en toute fin de développement, lorsque ton code fonctionne déjà bien, sans bug, etc.
Les manipulations de bits, en règle générale, sont tellement dépendants de la machine qu'il est sans doute plus « simple » si on connaît l'architecture cible d'éditer le code assembleur et de les faire soit-même (ou bien d'insérer le code ASM dans le source C, mais non seulement c'est crade, mais en plus les options d'optimisation sont désactivées automatiquement dans certains compilateurs quand ils détectent ce genre de magouille) :-)
En fait, dès que tu as des ressources matérielles très limitées, ce genre d'algorithmes peut faire gagner beaucoup de temps - ou bien de place, quand le problème tient plus au nombre de registres disponibles, par exemple (exemple tout bête : l'échange du contenu de deux variables à base de XOR).
Sinon, lorsqu'on entre en phase d'optimisation (et donc que le logiciel tourne déjà bien), et qu'une boucle doit être optimisée, parfois avoir recours à des opérations sur les bits peut accélérer les choses - mais j'ai l'impression que c'est très dépendant de l'architecture cible.
Bon, je t'ai pertinenté, mais quand même, j'ai envie de répondre un peu à certains trucs :
« La solution que j'ai trouvé est simple : laisser la gestion de la mémoire, tâche fastidieuse et source de nombreuses erreurs, à un gestionnaire automatique, prévu pour ça. C'est-à-dire en gros, ne pas programmer en C. »
Si si, c'est de la programmation en C. Utiliser un ramasse-miette externe n'est jamais une mauvaise idée si c'est la seule chose qui te gêne dans le langage.
« il est surprenant que, malgré de longues et brillantes recherches en théorie des langages, on se tape encore un langage aussi difficile à programmer que le C. »
Le C n'est pas un langage « difficile ». Sa syntaxe est l'une des plus simples qui existe, je trouve : il y a peu de concepts à retenir, et le plus difficile d'entre eux, le pointeur, est une notion qu'il est nécessaire de connaître si on veut faire de l'informatique professionnellement - enfin je trouve.
Par contre, pour paraphraser certains grands intervenants de fr.comp.lang.c : « C n'est pas un langage de débutant », et « C is a sharp tool ».
Là où par contre je suis tout à fait d'accord : utiliser le langage C est la plupart du temps inutile, car d'autres langages permettent de faire la même chose plus rapidement, avec beaucoup moins de bugs.
Le C est un langage à destination des programmeurs qui savent ce qu'ils font. Il est très important d'en avoir déjà fait à mon avis pour savoir ce qui peut clocher dans des langages de plus haut niveau, mais pour autant, à moins de programmer pour de la haute performance ou du « bas-niveau », utiliser le langage C dans les programmes de tous les jours relève souvent du masochisme.
Ca vient sans doute de gcc 4.x
J'ai testé sur une debian testing, avec gcc 4.0 et 4.1 : bug ;
Sur une red hat customisée : gcc 3.2.3, puis un gcc pré version 4 (gcc-ssa) : ça marche. Idem avec gcc 2.96.
En fait, avec gcc 4, il faut lancer l'optimisation pour que ça marche correctement .
« À ma connaissance, c'est plutôt ton système qui fluh si la sortie est un terminal (je crois qu'il le fait aussi pour les socket et les pipes, non ?) »
Non non, il a raison, c'est le '\n' qui fait que le vidage du tampon est effectué pour printf().
« Ben faut dire que quand tu cherches un bug dans une application multithreadée avec tâches concurrentes, des communications entre objets par signaux/slots et des communications interprocessus genre avec un DCOP serveur ou un kioslave, le débugger ça fait plus perdre de temps qu'autre chose. »
Sauf qu'en fait, dès que tu passes à du multi-process/multi-thread, l'utilisation de printf sur la sortie standard est plutôt déconseillée, vu que tu ne maîtrises pas l'ordre d'affichage des messages et que tu peux même en avoir certains qui passent à la trape.
« d'après mes propres tests non scientifiques et à mon humble avis, ICC n'a rien d'exceptionnel. »
Tout dépend quels programmes tu fais tourner. L'utilisation d'IPO (inter-process optimization) est quand même un super booster de performances. Je ne parle pas de 50% d'accélération (même si ça peut arriver), mais même avec 20%, c'est déjà exceptionnel.
Lorsqu'en plus tu utilises des logiciels qui sont plutôt du genre à boucler 90% du temps sur une boucle avec des codes réguliers (en gros du code « scientifique »), l'utilisation de -O3 et -ipo fait vraiment des merveilles. Tu peux gagner 40% en vitesse d'exécution par rapport à gcc 3 ou 4 en -O3.
Maintenant, je te l'accorde, pour la plupart des codes concernant le noyau, on s'en fout. Mais pour des codes concernant des flux multimédia, etc., ça peut jouer énormément. Idem pour les codes faisant entrer tout plein de calculs en jeu (calcul 3D, analyse numérique, etc).
Concernant les codes irréguliers, ICC se débrouille beaucoup moins bien, mais reste encore bien au-dessus de GCC.
« Surtout sur les systèmes AMD et sur ceux ayant une ou deux années de vie. »
Bon, je suppose que tu sais que ICC = Intel C Compiler. Ca ne me surprend pas outre mesure que les optimisations soient bien meilleures sur architecture Intel. D'ailleurs, si je me souviens bien, il est fortement déconseillé d'utiliser ICC avec un processeur AMD sous peine d'avoir des applications qui pourraient planter à cause de certaines optimisations effectuées par ICC et qui ne peuvent être faites que sur des archis Intel, parce qu'il y a quand même certaines grosses différences au niveau du modèle de processeur, tout ia32 qu'ils soient chez Intel et AMD. Et oui, ICC utilise très certainement des fonctionnalités non documentées des procs d'Intel.
« Par ailleurs, l'interêt que j'ai pour Gentoo vient plus de sa "hackabilité" que de ses performances. »
Possible, mais le titre du fil est « Performances de Gentoo ». Et je répondais sur ce critère uniquement.
Tu l'as dit, tes tests sont non-scientifiques, et il s'agit de ton avis. Ben il est à revoir, dès lors qu'on parle d'applications mettant beaucoup la pression sur le micro-processeur (et bien sûr, en supposant qu'il s'agisse d'un proc Intel, ce qui fait beaucoup de paramètres à prendre en compte, j'en suis conscient).
Mon objectif dans mon post initial était surtout de bien mettre l'accent sur le fait que
1) Des « distributions » source, ça existe depuis un moment (c'est plus ou moins la norme chez les *BSD), et si effectivement parfois ça peut se révéler un bon point pour les perfs, globalement c'est absolument pas concluant pour le système en général ; je pense aussi à LFS, dans le genre « [meta-]distributions source » ; dans tous les cas, je n'ai jamais entendu ceux qui s'en servaient dire « comme ça je peux vraiment gagner en performances », à quelques exceptions près pour certains programmes très précis.
2) GCC n'est pas encore au niveau des bons compilateurs optimisants, et parmi eux, ICC est vraiment l'un des meilleurs. Donc les optimisations proposées par GCC commencent à peine à avoir un « sens » (il suffit de mater comment les gens de chez MPlayer ont configuré le makefile pour comprendre qu'ils ne font pas vraiment confiance à GCC). Cela dit j'espère très fortement que ça va arriver !
Je ne suis pas du tout anti-GCC, je suis anti-jacky-distrib-linux, et franchement, beaucoup de gens utilisant Gentoo m'ont donné cette impression (ce sont les mêmes qui mettent en avant le côté performances avant les avantages que tu abordes, qui sont cent fois plus importants).
Si les performances étaient tellement meilleures avec une distrib orientée source, je me demande vraiment pourquoi les gens qui sont sur BSD depuis bien longtemps n'ont jamais vraiment crâné avec ça.
De plus, faut arrêter un peu, avec les « optimisations ». GCC, jusqu'à sa version 4, était un compilateur vaguement optimisant au mieux. Et même maintenant, on commence à peine à avoir de vraies optimisations (merci la forme SSA, de simplifier le boulot).
Jusqu'à preuve du contraire, ICC explose GCC pour toute architecture ia32/ia64 (et c'est bien normal, quand on n'a que 2 architectures comme cibles, c'est plus simple que pour GCC qui en a trois mille). Là par contre, si on me disait « avec les options -O3 -ipo d'icc, tu vas voir, ça booste », je dirai que ok, y'a des chances. Mais c'est tout.
Ils ont fait comme on fait d'habitude quand on a besoin d'héritage multiple en Java :
- dans les cas simple, l'utilisation des interfaces est suffisant ;
- dans les cas plus complexes, il y a plusieurs techniques. L'une d'entre elles est de dériver la classe depuis l'une de celles dont on voudrait hériter, et de créer des objets privés des autres classes, en reproduisant l'interface publique de chaque objet (oui, c'est fastidieux), par exemple.
Dans mes souvenirs, avant qu'il y ait des empereurs à Rome, Jules César avait été nommé dictateur ; dans la Grèce Antique, on nommait des tyrans en cas de crise majeure (surtout pour des problèmes de guerre), etc.
La distinction dictateur/tyran, ainsi que les sens originels puis modernisée ne me semble pas tellement grande...
« A l'origine, les DUT et BTS étaient destinés aux sections techniques justement, mais les sections générales les thrusts actuellement. »
Ca par contre c'est faux.
Les STS ont été faits explicitement pour les section technologiques, alors que les IUT ont toujours visé les sections générales. Je peux d'autant plus l'affirmer que lorsque j'avais émis la même idée que toi à propos de ces deux formations, la prof d'IUT qui m'a répondu a clairement été patiente en m'expliquant ce qu'il en était, mais on sentait une légère tension quand même (je n'étais pas vraiment la première personne à dire ça, je suppose).
J'ai trop simplifié, en effet. Ma réponse était donc incomplète (quand on me dit « c'est faux » de façon aussi péremptoire, j'ai un peu envie de me gonfler de mauvaise foi).
Ben c'est simple, ils n'incluent rien de propriétaire dans le noyau. Un firmware ne s'exécute pas au niveau de l'OS, mais directement au niveau du périphérique. Et la politique d'OpenBSD est très claire à ce niveau : un module noyau propriétaire, JAMAIS, mais un firmware propriétaire, aucun problème, vu que ça ne concerne pas l'OS en tant que tel.
C'est vraiment étonnant, vu que les STS sont explicitement créées à destination des gens venant de sections technologiques, alors que les IUT sont à destination de gens venant de sections générales.
En IUT génie info [de gestion] en tout cas, la majeure partie des étudiants venaient de S, et une autre partie (non négligeable) venait de SES.
En pratique, je sais que peu de personnes venant de section ST{T,I} parviennent à aller en IUT (leur filière privilégiée est la STS), donc tu devais être plutôt bon au lycée pour avoir été pris. J'ai souvenir que la seule personne venant de STS dans ma promo n'a pas réussi à passer en 2è année, comme quoi...
Mais ton cours d'info était-il une option dans ta branche ? Si oui, qu'y faisiez vous (quel était le programme, etc.) ?
[^] # Re: 11 septembre, jour férié ?
Posté par lasher . En réponse au journal Joyeux 11 septembre. Évalué à 2.
[^] # Re: 11 septembre, jour férié ?
Posté par lasher . En réponse au journal Joyeux 11 septembre. Évalué à 2.
[^] # Re: pas chez moi, et cela ne semble pas près de changer
Posté par lasher . En réponse à la dépêche Du logiciel libre dans les Universités. Évalué à 3.
[^] # Re: 11 septembre, jour férié ?
Posté par lasher . En réponse au journal Joyeux 11 septembre. Évalué à -2.
Pardon ? D'une, dans le WTC, différentes personnes de différentes nationalités travaillaient là-bas : c'était un centre d'affaires international. De deux, ça a eu un véritable impact au niveau mondial, et le nier, en disant que « ça n'a touché qu'une ville des Etats-Unis », c'est un discours à la limite de celui où l'on parle de « détail de l'histoire ». Seulement comme ça touche les USA, c'est moins grave, n'est-ce pas ?
Enfin, estimer que la portée symbolique de cet attentat est nulle, c'est faire preuve d'un manque d'ouverture d'esprit flagrant.
[^] # Re: Ca fait plaisir
Posté par lasher . En réponse au journal [HS] Consommation d'électricité. Évalué à 2.
[^] # Re: Pas seulement diminuer la consommation électrique ...
Posté par lasher . En réponse au journal [HS] Consommation d'électricité. Évalué à 2.
Non, car si toutes tes affirmations sont vraies, comme on ne sait pas si on parle de l'énergie produite par une centrale directement à sa « sortie » ou bien s'il s'agit de l'énergie qu'on peut consommer dans les ménages, l'effet n'est pas le même tu en conviendras (le posteur précédent n'a pas précisé).
De plus, tu donnes arbitrairement une diminution de 400 éoliennes, mais tu n'en sais rien (moi non plus du reste). Ca pourrait être plus, ça pourrait être beaucoup moins.
[^] # Re: Ne pas tout croire...
Posté par lasher . En réponse au journal NetBSD : droit dans le mur ?. Évalué à 3.
« Dans le cas de Linux, on a un megalomaniaque qui decide (avec ou sans justification) ce qui est bon ou non »
C'est tout bonnement faux. Linus le dit lui-même : l'une des premières choses qu'il a dû apprendre à faire, c'est déléguer. Au final il a le mot de la fin si « en-dessous » ils n'arrivent pas à se mettre d'accord quant à certaines orientations techniques, oui. Un peu comme un chef de projet, quoi. Il fait confiance aux gens à qui il délègue.
Le côté mégalomane, je ne le vois pas vraiment. A-t-il un ego très fort ? Oui, assurément. Et là encore, c'est l'un des premiers à dire quelque chose du genre "Le plus simple pour être célèbre, c'est de commencer quelque chose, et de laisser tout le monde compléter l'embryon de projet - en ensuite d'en récupérer tout le mérite" (ce à quoi, Larry Wall, papa de Perl, aurait répondu « vas-y mon frère, dis-leur ! »)
[^] # Re: Stockage des données...
Posté par lasher . En réponse à la dépêche Sortie de Tellico 1.2. Évalué à 2.
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 3.
L'optimisation intervient tout à la fin, quand tu as déjà fait les bons choix pour ton logiciel (par exemple en utilisant un tri rapide ou un tri fusion pour trier tes éléments). Choisir un bon tri n'est pas faire de l'optimisation, c'est faire de bons choix de conception.
Ce que j'appelle « optimisation » pourrait sans doute plutôt être appelée « micro-optimisation » : on se rend compte qu'on passe 90% du temps dans une boucle, alors on essaie de voir si on ne pourrait pas améliorer la façon dont elle s'exécute. Maintenant, si ta boucle est en réalité un tri à bulle, tu auras beau optimiser et gagner 10 ou 20 % en perfs, tu seras toujours plusieurs ordres de grandeur derrière un tri rapide ou fusion.
C'est pour ça que les (micro-)optimisations viennent en fin de développement : on a déjà réglé le plus gros des détails, et on a déjà une application raisonnablement rapide.
Donc, de mon point de vue, optimiser un tri à bulles ou un tri rapide, c'est *toujours* de l'optimisation. C'est juste que dans un cas, tu optimises un truc pas très efficace.
[^] # Re: Stockage des données...
Posté par lasher . En réponse à la dépêche Sortie de Tellico 1.2. Évalué à 3.
Tu vas vexer beaucoup de chercheurs en SGBD, là. Il ne faut pas confondre la forme finale d'un document XML, le document « plat », et ce qu'est un document XML, à savoir un arbre ordonné et étiqueté. La forme finale, c'est ton fichier « lisible par un humain » (qui a pris deux-trois aspirines avant de lire le fichier de 3000 balises). Mais la base en elle-même fait exactement comme les autres : elle indexe les documents, les noeuds fils, les noeuds parents ...
« Mais stocker en XML, dans un fichier 'plat', des données qui peuvent se montrer volumineuses et sur lesquelles on a besoin d'un accès direct: AMA non. »
Du point de vue d'une BDD, un document XML est un arbre (ou un graphe, si tu utilises les IDREF - mais là t'es déjà bien vicieux ;-) ). Rien n'empêche la base d'avoir cette structure version « binaire » (structure de graphe/d'arbre donc) dans la base, et de ne dumper les fichiers XML que lorsque tu en as besoin. D'ailleurs c'est plus ou moins ce que fait BDB/XML : tu importes tes fichiers dans la base, et il garde le tout chez lui, dans une forme interne qui l'arrange. Ensuite, tu peux faire des requêtes sur la base avec XQuery, et récupérer un document au format XML en sortie.
En ce moment, beaucoup d'efforts sont fournis pour adapter les optimisations connues des SGBD/R vers les SGBD/XML. L'indexation est particulière, car si dans un SGBD/R on a des types fixes, avec des lignes de table de taille fixes elles aussi, XML est un langage semi-structuré : il faut en tenir compte.
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 3.
Ben tout dépend de quel compilateur on parle. :-)
Au risque de me répéter vis à vis de ce que j'ai pu dire dans d'autres réactions, gcc n'est pas (encore) le plus optimisant des compilos, et on peut clairement faire mieux à la main, si on a le temps et la volonté d'apprendre l'assembleur de la machine cible. Alors que pour faire mieux à la main que certains autres compilateurs, il faut se lever très tôt.
« Enfin, un argument sensé que j'ai lu je ne sais plus où:
avec des "hacks" comme ça, tu gagnes un peu, mais ce peu va se réduire avec les années (progrès du compilo/métériel). Par contre, tu perds en lisibilité, et pour toujours... »
C'est vrai. C'est pour ça que les deux grandes règles de l'optimisation sont :
1°) N'optimise pas.
2°) (pour experts seulement) N'optimise pas encore.
L'optimisation vient en toute fin de développement, lorsque ton code fonctionne déjà bien, sans bug, etc.
Les manipulations de bits, en règle générale, sont tellement dépendants de la machine qu'il est sans doute plus « simple » si on connaît l'architecture cible d'éditer le code assembleur et de les faire soit-même (ou bien d'insérer le code ASM dans le source C, mais non seulement c'est crade, mais en plus les options d'optimisation sont désactivées automatiquement dans certains compilateurs quand ils détectent ce genre de magouille) :-)
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 4.
Sinon, lorsqu'on entre en phase d'optimisation (et donc que le logiciel tourne déjà bien), et qu'une boucle doit être optimisée, parfois avoir recours à des opérations sur les bits peut accélérer les choses - mais j'ai l'impression que c'est très dépendant de l'architecture cible.
[^] # Re: Heisenbug
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 10.
« La solution que j'ai trouvé est simple : laisser la gestion de la mémoire, tâche fastidieuse et source de nombreuses erreurs, à un gestionnaire automatique, prévu pour ça. C'est-à-dire en gros, ne pas programmer en C. »
Si si, c'est de la programmation en C. Utiliser un ramasse-miette externe n'est jamais une mauvaise idée si c'est la seule chose qui te gêne dans le langage.
« il est surprenant que, malgré de longues et brillantes recherches en théorie des langages, on se tape encore un langage aussi difficile à programmer que le C. »
Le C n'est pas un langage « difficile ». Sa syntaxe est l'une des plus simples qui existe, je trouve : il y a peu de concepts à retenir, et le plus difficile d'entre eux, le pointeur, est une notion qu'il est nécessaire de connaître si on veut faire de l'informatique professionnellement - enfin je trouve.
Par contre, pour paraphraser certains grands intervenants de fr.comp.lang.c : « C n'est pas un langage de débutant », et « C is a sharp tool ».
Là où par contre je suis tout à fait d'accord : utiliser le langage C est la plupart du temps inutile, car d'autres langages permettent de faire la même chose plus rapidement, avec beaucoup moins de bugs.
Le C est un langage à destination des programmeurs qui savent ce qu'ils font. Il est très important d'en avoir déjà fait à mon avis pour savoir ce qui peut clocher dans des langages de plus haut niveau, mais pour autant, à moins de programmer pour de la haute performance ou du « bas-niveau », utiliser le langage C dans les programmes de tous les jours relève souvent du masochisme.
[^] # Re: Heisenbug...
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 2.
J'ai testé sur une debian testing, avec gcc 4.0 et 4.1 : bug ;
Sur une red hat customisée : gcc 3.2.3, puis un gcc pré version 4 (gcc-ssa) : ça marche. Idem avec gcc 2.96.
En fait, avec gcc 4, il faut lancer l'optimisation pour que ça marche correctement .
[^] # Re: Au final...
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 2.
Non non, il a raison, c'est le '\n' qui fait que le vidage du tampon est effectué pour printf().
[^] # Re: ouais
Posté par lasher . En réponse au journal printf debugging considered harmful. Évalué à 4.
Sauf qu'en fait, dès que tu passes à du multi-process/multi-thread, l'utilisation de printf sur la sortie standard est plutôt déconseillée, vu que tu ne maîtrises pas l'ordre d'affichage des messages et que tu peux même en avoir certains qui passent à la trape.
[^] # Re: Performances de Gentoo
Posté par lasher . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 3.
Tout dépend quels programmes tu fais tourner. L'utilisation d'IPO (inter-process optimization) est quand même un super booster de performances. Je ne parle pas de 50% d'accélération (même si ça peut arriver), mais même avec 20%, c'est déjà exceptionnel.
Lorsqu'en plus tu utilises des logiciels qui sont plutôt du genre à boucler 90% du temps sur une boucle avec des codes réguliers (en gros du code « scientifique »), l'utilisation de -O3 et -ipo fait vraiment des merveilles. Tu peux gagner 40% en vitesse d'exécution par rapport à gcc 3 ou 4 en -O3.
Maintenant, je te l'accorde, pour la plupart des codes concernant le noyau, on s'en fout. Mais pour des codes concernant des flux multimédia, etc., ça peut jouer énormément. Idem pour les codes faisant entrer tout plein de calculs en jeu (calcul 3D, analyse numérique, etc).
Concernant les codes irréguliers, ICC se débrouille beaucoup moins bien, mais reste encore bien au-dessus de GCC.
« Surtout sur les systèmes AMD et sur ceux ayant une ou deux années de vie. »
Bon, je suppose que tu sais que ICC = Intel C Compiler. Ca ne me surprend pas outre mesure que les optimisations soient bien meilleures sur architecture Intel. D'ailleurs, si je me souviens bien, il est fortement déconseillé d'utiliser ICC avec un processeur AMD sous peine d'avoir des applications qui pourraient planter à cause de certaines optimisations effectuées par ICC et qui ne peuvent être faites que sur des archis Intel, parce qu'il y a quand même certaines grosses différences au niveau du modèle de processeur, tout ia32 qu'ils soient chez Intel et AMD. Et oui, ICC utilise très certainement des fonctionnalités non documentées des procs d'Intel.
« Par ailleurs, l'interêt que j'ai pour Gentoo vient plus de sa "hackabilité" que de ses performances. »
Possible, mais le titre du fil est « Performances de Gentoo ». Et je répondais sur ce critère uniquement.
Tu l'as dit, tes tests sont non-scientifiques, et il s'agit de ton avis. Ben il est à revoir, dès lors qu'on parle d'applications mettant beaucoup la pression sur le micro-processeur (et bien sûr, en supposant qu'il s'agisse d'un proc Intel, ce qui fait beaucoup de paramètres à prendre en compte, j'en suis conscient).
Mon objectif dans mon post initial était surtout de bien mettre l'accent sur le fait que
1) Des « distributions » source, ça existe depuis un moment (c'est plus ou moins la norme chez les *BSD), et si effectivement parfois ça peut se révéler un bon point pour les perfs, globalement c'est absolument pas concluant pour le système en général ; je pense aussi à LFS, dans le genre « [meta-]distributions source » ; dans tous les cas, je n'ai jamais entendu ceux qui s'en servaient dire « comme ça je peux vraiment gagner en performances », à quelques exceptions près pour certains programmes très précis.
2) GCC n'est pas encore au niveau des bons compilateurs optimisants, et parmi eux, ICC est vraiment l'un des meilleurs. Donc les optimisations proposées par GCC commencent à peine à avoir un « sens » (il suffit de mater comment les gens de chez MPlayer ont configuré le makefile pour comprendre qu'ils ne font pas vraiment confiance à GCC). Cela dit j'espère très fortement que ça va arriver !
Je ne suis pas du tout anti-GCC, je suis anti-jacky-distrib-linux, et franchement, beaucoup de gens utilisant Gentoo m'ont donné cette impression (ce sont les mêmes qui mettent en avant le côté performances avant les avantages que tu abordes, qui sont cent fois plus importants).
[^] # Re: Performances de Gentoo
Posté par lasher . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 1.
De plus, faut arrêter un peu, avec les « optimisations ». GCC, jusqu'à sa version 4, était un compilateur vaguement optimisant au mieux. Et même maintenant, on commence à peine à avoir de vraies optimisations (merci la forme SSA, de simplifier le boulot).
Jusqu'à preuve du contraire, ICC explose GCC pour toute architecture ia32/ia64 (et c'est bien normal, quand on n'a que 2 architectures comme cibles, c'est plus simple que pour GCC qui en a trois mille). Là par contre, si on me disait « avec les options -O3 -ipo d'icc, tu vas voir, ça booste », je dirai que ok, y'a des chances. Mais c'est tout.
[^] # Re: héritage multiple?
Posté par lasher . En réponse à la dépêche Trolltech publie les avancées de Qt pour Java. Évalué à 4.
- dans les cas simple, l'utilisation des interfaces est suffisant ;
- dans les cas plus complexes, il y a plusieurs techniques. L'une d'entre elles est de dériver la classe depuis l'une de celles dont on voudrait hériter, et de créer des objets privés des autres classes, en reproduisant l'interface publique de chaque objet (oui, c'est fastidieux), par exemple.
[^] # Re: Dans les réponses
Posté par lasher . En réponse au journal NetBSD : droit dans le mur ?. Évalué à 4.
La distinction dictateur/tyran, ainsi que les sens originels puis modernisée ne me semble pas tellement grande...
[^] # Re: Mouais, pas top de cocorico non plus ...
Posté par lasher . En réponse à la dépêche Trois médailles pour la France aux Olympiades Internationales d'Informatique. Évalué à 2.
« A l'origine, les DUT et BTS étaient destinés aux sections techniques justement, mais les sections générales les thrusts actuellement. »
Ca par contre c'est faux.
Les STS ont été faits explicitement pour les section technologiques, alors que les IUT ont toujours visé les sections générales. Je peux d'autant plus l'affirmer que lorsque j'avais émis la même idée que toi à propos de ces deux formations, la prof d'IUT qui m'a répondu a clairement été patiente en m'expliquant ce qu'il en était, mais on sentait une légère tension quand même (je n'étais pas vraiment la première personne à dire ça, je suppose).
[^] # Re: Une 4ème option ?
Posté par lasher . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 2.
[^] # Re: Une 4ème option ?
Posté par lasher . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 8.
[^] # Re: Mouais, pas top de cocorico non plus ...
Posté par lasher . En réponse à la dépêche Trois médailles pour la France aux Olympiades Internationales d'Informatique. Évalué à 3.
En IUT génie info [de gestion] en tout cas, la majeure partie des étudiants venaient de S, et une autre partie (non négligeable) venait de SES.
[^] # Re: Mouais, pas top de cocorico non plus ...
Posté par lasher . En réponse à la dépêche Trois médailles pour la France aux Olympiades Internationales d'Informatique. Évalué à 2.
En pratique, je sais que peu de personnes venant de section ST{T,I} parviennent à aller en IUT (leur filière privilégiée est la STS), donc tu devais être plutôt bon au lycée pour avoir été pris. J'ai souvenir que la seule personne venant de STS dans ma promo n'a pas réussi à passer en 2è année, comme quoi...
Mais ton cours d'info était-il une option dans ta branche ? Si oui, qu'y faisiez vous (quel était le programme, etc.) ?