beagf a écrit 763 commentaires

Il faudrais peut-être qu'ils mettent à jour leur page d'acceuil alors car je ne pense pas être le seul à refuser d'installer un gros SGBDR juste pour stocker trois options des utilisateurs d'un webmail.

Mettre un peu plus en avant sqlite (au moins autant que les deux autres) ne pourrais que faire du bien roundcube.

J'avais déjà entendu parler de Roundcube plusieurs fois et à chaque fois j'avais été séduit par son interface sore mais éfficace. Mais à chaque fois j'avais abandonné en regardant la première page du site qui indique qu'il nécessite MySql ou Postgre.

Ton commentaire, bien que légèrement sarcastique à un moment ou il fallait mieux pas me chercher ;-) m'a mit la puce à l'oreille. Je me rend donc sur leur site, et confirmation la page n'a pas changée...

Par acquis de conscience j'ai quand même été voir plus loin, et bien m'en à pris car, en effet la version 3-rc1 supporte sqlite. (en version 2 pas 3 hélas...)

Donc je viens de tester et en effet ça marche à merveille. J'ai plus qu'à attendre la version finale de la 3.0 pour tester ça un peu plus en profondeur et surement envisager une migration. Ça va faire plaisir à mes utilisateurs.

Et petite question, est-ce que quelqu'un ici à déjà mit en place roundcube sur une messagerie un peu importante, aux alentour de 1500 utilisateurs ? Qu'elle est la charge sur le serveur par rapport à squirelmail ? Est-ce qu'il est fiable ?

Je me traine toujours un SquirrelMail car c'est le seul webmail pas trop pourri que j'ai pus trouver qui ne demande pas d'installer un gestionnaire de base de données.

MySQL est utilisé pour quoi ? Le carnet d'adresses (qui est basique d'après le site web) Les logins/mot de passe ?

C'est pas un peu prendre un marteau piqeur pour écraser une mouche, surtout pour un webmail qui fonctionne au dessus d'IMAP ?

Je pense que tu n'a pas du bien comprendre ce qu'il disait.

4 milliards d'humain qui ont plusieurs comptes, donc plusieurs logins. (je devrais compter le nombre de login que j'utilise, mais à première vue je dirais plus de 20 facile).
Beaucoup d'informaticiens on bien plus de 10 mots de passe, mais madame michu n'en a en general qu'un seul. J'ai compris que protéger un site avec un mot de passe ne servait à rien après une discution avec des amis sur le sujet où j'ai apris qu'ils utilisaient tous un seul mot de passe quel que soit le site.
Donc en moyenne je pense même que 10 mot de passe par personne soit surestimè.

10 mots de passes de 10 caractères ==> 10x10 = 100 ???? WTF

Si tu as 10 caractères dans un mot de passe, tu as un choix (bas) de 62 caractères par caractères (26 lettres min, 26 lettres maj, 10 chiffres et je ne compte pas les caractères spéciaux..) donc c'est 62^10 possibilités...

Si je recompte, on obtient donc, rien que pour les mots de passe: 745 Petta Octets de données....

Non, sont calcul est juste, si tu doit stocker 10 mot de passe de 10 caracteres, tu as besoin de 10 emplacement de 10 octets, donc 100 octets.

Il parle de stocker le mots de passe utilisés par les gens, pas l'ensemble des mots de passe possibles.

Ensuite, tu indiques que les mots de passe sont stockés sur le site de sourceforge. J'espère que ce n'est pas le cas. Normalement, les mots de passe sont hachés. Lorsque tu donnes ton mot de passe, il est haché à son tour et les hashs sont comparés. (Regarde le contenu de ton /etc/shadow par exemple, les mots de passe ne sont pas présents. De plus, pour éviter les attaques par précalcul des hash, les mots de passes sont souvent 'salés' puis hachés. Le sel est contenu entre les $ du mot de passe. Le mot de passe est toujours: $sel$hash si tu regardes bien).
Ceci dit, pleins de sites conservent les mots de passe en clair, mais c'est MAL.

Il parle ici de créer une base de donnèe de mots de passe pour des attaque, pas de celle de sf. Pour faire cette base de donnée tu crer de faux sites aléchants ou l'utilisateur doit s'enregistrer, ou bien tu pirate un site du genre sf et tu modifie le code pour qu'il t'envoie les couples login/password.

Donc le site peut conserver ces mots de passes comme il veut, toi tu te constitu ta base d'une maniere ou d'une autre et ensuite tu essaye tous les couple que tu as en base. la probabilitee qu'un d'entre eux marche est loin d'être négligeable.

Tous les symptomes de l'utilisateur classique qui ne sait faire qu'une chose : gueuler sans réfléchir.

Oui, c'est le bordel pour les joindre mais remet toi un peu en cause, c'est quand même toi qui à fait l'anduoille à la base. Un mot de passe c'est un truc qu'il est important de retenir ou de mettre en lieu sur, principalement pour un truc comme un serveur. Ensuite au cas ou tu l'oublierais ils mettent en place un système pour que tu puisse le récupérer, mais comme ils sont sympa et qu'ils ne veulent pas que n'importe qui puisse le récupérer, il te l'envoie sur ton portable.
Pas de bol toi tu te contetappait de pouvoir récupérer ton mot de passe donc tu ne leur à pas dit que tu avais changer de portable. Maintenant assume.

Soit, tu paye tous les mois pour ton serveur, mais tu payes pas cher, donc tu en as pour ton argent.
Ensuite tu dis que tu te souviens du mots de passe original. Dans ce cas pourquoi tu ne l'as pas utiliser des le début ?

Et le pire pour la fin : Tu gueule sur le fait qu'ils ont regénéré un mot de passe plutôt que de te renvoyer le tiens. Regarde ton fichier /etc/shadow et tu auras un bon exemple de ce que l'on fait pour stocker de manière un minimum sécurisé les mots de passes. Free ne stock pas ton mot de passe mais un hash de celui-ci, donc ils ne peuvent pas te le renvoyer. Et je suis presque persuadé que si tu avais réussit à faire fonctionner leur système et qu'il t'avaient renvoyé ton mot de passe d'origine, tu aurais été le premier à venir gueuler ici sur le fait que free c'est pas sécurisé.

Donc désère le string, assume ta boulette et insiste un peu plus calmement sur le chat avec un vrai client irc ou sur les newsgroup, au pris que tu payes, tu n'à pas vraiment à attendre mieux.

Tu as l'interface d'IE ?
Tout comme toi je n'ai pas dit que c'était facile, mais si wine l'a fait c'est que c'est possible.

On peut la reprendre librement ? On peut supprimer le moteur de windows par le notre avec la même interface ?
De la même maniere que tu peut remplacer l'explorer et mettre une autre interface graphique a Windows. Il suffit de remplacer les programmes ou bibliothèques fournies par Microsoft par les tiennes.

Voila, tu as ta répondu tout seul à ta première question.
Donc, en effet j'ai répondu à ma question : «tu es de mauvaise foi car s'il suffit de coder, et bien tu as le choix de coder une interface entre IE et Gecko» donc je continue de penser que ton commentaire était inutile at n'apportait rien à la discution.

Perso ce qui me gène dans ton commentaire c'est que tu est à côter de la plaque et que ton commentaire est inutile.

Soit tu es sincère en disant que c'est possible et «qu'il suffit de le coder» et dans ce cas là je te répond qu'il est possible de remlacer IE par Gecko, «il suffit juste de coder une lib qui expose la même interface qu'IE» [1] et donc ton commentaire est relativement inutile.

Soit c'est un appel au troll débile et aussi méprisante que les «t'as qu'a le coder» que l'on voit fleurir à la moindre petite critique d'un logiciel libre, et donc ton commentaire est completement inutile.

Et comme je pense que justifier un plussage/moinsage est inutile, n'hésitez pas à enfoncer aussi ce commentaire.

[1] En cadeau bonnus, je pense que c'est deja plus ou moins fait puisque wine utilise le moteur Gecko pour les applis windows qui demandent un rendu HTML.

Je vais résumé mon point de vue en essayant d'être plus clair car j'ai l'impréssion que ce n'était pas le cas : Un bench qui n'est pas fait correctement, même s'il peut être marrant quand on le fait dans son coin, fait du mal au langage de manière général quand il est public comme celui que tu propose ici :
- Tu peut mettre tous les avertissement sur le fait que ce que tu vas dire est une grosse connerie, il y aura toujours des personnes pour reprendre tes chiffres et les utiliser comme une parole d'évangile. Les gens aiment les chiffres même lorsqu'ils sont faux, il suffit de regarder les débats sur les perfs de java ou autres langage de haut-niveau ;
- Pour quelqu'un qui regarde le bench d'un peu plus près, tu donne l'impression d'avoir chercher un cas à tout pris où tes perfs sont meilleur que celle du langage auquel tu te compare (même si ce n'est pas forcément le cas) donc tu perd toute crédibilité. Donc même si ton langage est bon, tu pousse les gens que cela pourrait intéresser à passer leur chemin.

Ce que je critique dans mes message c'est principalement le fait de publier un bench tels que celui que tu donne. Les chiffres que tu donne ne veulent strictement rien dire à l'exception d'un cas très particulier qui n'apparait pas jamais dans la vraie vie. Le programme auquel tu l'oppose est trivialement mal programmé pour quelqu'un qui connait le C++, alors que l'on peut supposer que celui en OCC est bien codé puisque c'est ton langage, on peut donc en déduire que tu est de mauvaise foie.

Bref, même si cela part d'une bonne intention, je pense que ton bench fait plus de mal qu'autre chose, et c'est général pour les mauvais benchs. Après, c'est peut-être moi qui suit tordu et qui voit le mal partout, mais au niveau bench j'ai vu le meilleur comme le pire, et j'ai pris l'habitude de me méfier de chiffre donnée sur la base des micro-bench.
Mais de ce que j'ai pus voir les gens gobent ces chiffre aveuglément et globalement c'est plus facile de ce battre contre les mauvais bench que contre les idées qu'ils ont répendues.

[...]exemple avec plein de systeme qui créent des objets dans tous les sens[..]
Ton exemple illustre tout à fait ce que je critique, même si la création/libération des objets est un facteur important : dans le cas que tu illustres, il y a beaucoup de chose qui ce passe en plus de ces opérations. Notament, et c'est souvnt très important les objets sont rarement libérés dans le même ordre qu'ils sont créés, certains ont une durée de vie bien plus longue que les autres, beaucoup de paramètres entrent en jeu. Au final on est très loin de la situtation idéale du micro-bench que tu présente.
Résultat : dans ce cas réaliste les perfs du GC doivent chuter dramatiquement et au final les perfs sont surement au mieux similaires à celle du C++.

Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
Ne me fais pas dire ce que je n'ai pas dit. Nulle part je ne dit que gérer la mémoire sans GC est trivial. Ce que je dis c'est que,dans un cas comme celui de ton micro bench, l'utilisation d'un pool est très simple : un grand nombre d'objet tous de même taille à allouer et libérer dans une portion réduite du code.
De manière générale, l'utilisation de pool reste relativement simple tant que tu restes sur l'allocation d'un grand nombre d'objets identiques et dans ces cas là, c'est à ma connaissance toujours plus éfficace d'utiliser un pool qu'un GC.
Si tes objets sont de tailles variable et contiennent des références les un aux autres, je suis d'accord qu'un GC deviens intéressant et qu'un pool n'est plus adapté.

Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
Je suis loin d'être un fan du C++ contrairement à ce que tu dis, j'ai parlé du C++ car ton bench comparait OCC à C++ uniquement. Donc si tu veut délirer sur ma fierté et mon grand savoir libre à toi, mais fais comme pour le bench qui ne veulent rien dire, s'il te plait, ne les publies pas.
Pour ton information et pour t'éviter de me relire, je suis pour le choix de la solution adaptée à chaque problèmes, et donc dans le cadre de ton micro bench pour la version en C++ c'est un pool et pas une gestion basique qu'il faut utiliser.
L'avenir de OOC et le fait de pouvoir utiliser plusieurs modèles d'allocation mémoire c'est au dernier message que tu as commencé à en parler, je t'ai même répodu que ce serait bien de le faire, donc depuis que tu en parle, je pense l'avoir lut et en avoir tenu compte...

> Ton benchmark ne prouve qu'une chose
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
Pour entrer dans le jeu, ça prouve juste que ça ne prouve rien ;-)

> Il n'y a aucun interet au programme que tu montre
Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...

> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut?
Bah non ce n'est pas ce que tu as répété come tu le dis si bien juste après :

La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"


Une tâche très précise qui ne se produit jamais en dans un vrai code et en plus mal coder de manière à déformer les résultats du bench ? Ça c'est du bench intéressant...
Tout ce que tu réussit à faire avec ton bench c'est dire «dans un cas que vous ne rencontrerez jamais dans la réalitée OOC fait mieux que C++ (et encore /une/ implémentation de C++), mais pour des cas réaliste je vous laisse deviner.»
Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir.
Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.

ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
Tout d'abord ce que tu fais n'est pas un vrai bench dans le sens ou tu biaise un des langages testés en l'utilisant mal. Si je fais un bench entre du C du CAML je peut déjà te dire que CAML sera dix fois plus lent et pourtant certains on montrer qu'il avait des perfs honorables.
Ensuite où est l'interet d'un bench qui mesure des performances même vagues dans des conditions telles qu'elles ne seront jamais rencontrer dans aucun programme ?

> en réalité tu ne fais pas un ++ sur variable
c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
Je pense que tu le fais exprès mais au cas ou... Je ne critique pas le fait que tu fasse un ++, ce que je critique c'est que tu ne fasse que ça. Tu as souvent écrit des programme qui créait un million d'objet pour juste faire un ++ sur une variable et ensuite libéré l'objet ?
Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ? C'est ce point qui est important. Ce qu'il faut te poser comme question c'est, qu'ai je sacrifier pour ça et est-ce que ça vaut le cout ?
C'est la même chose que l'argument classique en faveur des GCs : On perd générallement un petit peu en perf mais on y gagne une facilitée d'utilisation.
Tu gagne par rapport à C++ lors de la création de grande quantitée d'objet sans utilisation de pool, mais dans des condition réelle ou chaque objet réalise un vrai traitement tu ne gagne qu'un pouième de perfs, est-ce que c'est valable ? est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
(vrai question puisque je ne sais pas comment marche OOC)

> Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
Là j'ai du mal à voir le rapport avec Firefox. Si j'écrit une appli en OOC qui à plein de fuite mémoire ça veut dire que OOC est une merde ?
Le gros problème de Firefox c'est que la gestion mémoire à été conçue progressivement en rajoutant des couches petit à petit. Le lien que tu indiques montre que la mémoire se fragmente et donc qu'elle ne peut être récupéré par le système. Ce problème n'est pas lié au C++ ou à des pool ou n'importe quoi d'autre, un GC aurra éxactement le même.

Si tu allous un million de petits objets et que tu en libère un sur deux, quel que soit le système que tu utilises tu ne pourra pas libéré la mémoire. A moin d'utiliser un GC compacteur mais là ça pose d'énorme problème puisque tout les pointeur doivent être indirects.
Bien au contraire, un système de pool peut même améliorer la situation car il t'assure que les objets de même types sont regroupés au même endroit, donc il facilite la gestion.

Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
Ça c'est déjà mieux. Intégrer dans le langage ce que l'on fait de manière plus crade en C++ serait pas mal à condition que ce soit fait proprement ;-)

> il faut être capable de choisir le langage adapté à la tache et à l'environement.
eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
D'un autre côté, ça fait des années que je le dis, et je suis sûr que d'autres l'on dis avant nous. Heureusement qu'il n'y a pas encore de brevets sur les opinions....

> C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
Pour le C++, j'ai un ensemble classes et de templates que je réutilise à chaque fois que j'en ai besoin et qui me font ce genre de merde toutes seules. Ensuite, c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Et pour retourner le compliment, j'ai vu des programmeur (paix à leurs âmes) qui, obligé de programmer dans un langage qui pensait savoir mieux qu'eux comment gérer la mémoire était obliger de passer par de grand tableaux d'objets pour émuler les pool si simple à coder en C ou en C++. Bien sûr c'est pas des cas courrant, et c'est loin d'être systématiquement valable, mais ça arrive à mon avis plus souvent que créer un million do'bjets juste pour faire un ++....

> strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
Je ne lance pas le débat sur l'immutabilité des string mais sur le fait qu'il est dangeureux de cacher des chose, surtout dans les éléments de base d'un langage. Je voulais surtout montrer les effets pervers que peuvent avoir dans certains cas le GC et bien expliquer que ce n'est pas la solution ultime et que la gestion manuelle de la mémoire n'est pas le mal absolu.

Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
Et le jour ou un programmeur stockera un poiteur vers un objet de manière un peu cryptée ou utilisera une variable entière dont la valeure est la même que l'adresse d'un objet qui traine quelque part, le Bohem GC va se planter et l programmeur aurra une surprise...
J'admet que le premier cas relève d'une connerie de la part du programmeur, mais le deuxième est tout à fait réaliste.

Il est incohérent de critiquer un microbenchmark « non réaliste » et d'expliquer ensuite que le C(++) permet des tas de micro-optimisations coûteuses en développement et en maintenance, comme si c'était « réaliste » de faire ce genre de micro-optimisations sur des applications de la vraie vie.

Ta critique ne tient (et encore que vaguement) que dans le cadre de ce micro-bench. Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.

Tout d'abord, tu trouvera de nombreuse classe sur le net, déjà testées intensivement, qui implémentent ce genre de pool. Donc le cout de dévellopement à ce niveau est quasiment nul. Tu commence par créer un pool en lui donnant éventuellement une indication du nombre d'élément que tu pense créer, et ensuite tu lui demande et et éventuellement redonne les objets de la même manière que les allouerais/libererais de manière classique. Avec l'avantage que tu as un netoyage global à la fin en libérant le pool.
Donc tu peut même gagner du temps dans certains cas, en éliminant la nécéssitée de libéré les objets au fur et à mesure.

Ensuite, un objet qui doit être créer à suffisament d'exemplaire pour qu'utiliser un pool soit vraiment intéressant c'est pas forcément tous les jours que tu en rencontre. Donc de base c'est le genre de chose auquel on a tendance à penser au moment ou l'on prévoit le design de l'application, pas en dernière minute.

De manière plus générale, l'utilisation d'un pool n'est pas, comme tu le dis, une «micro-optimisation» mais un point de design et dans des programme réaliste, les cas ou tu dois le mettre en oeuvre ne sont pas si fréquents, sont bien prévu, et au final ne complexifie pas le code mais on tendance à le simplifier beaucoup quand c'est bien fait.

Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.

Le développeur utilisant un langage plus haut niveau aura écrit un logiciel à la couverture fonctionnelle trois fois plus grande, et qui apporte plus aux utilisateurs.

C'est un joli mythe mais dans la réalitée c'est loin d'être toujours le cas. Il y a énormément de chose qui jouent dans ta capacité à produire du code et le niveau d'abstraction ou de fonctionalité du langage n'est pas la plus importante.

De manière générale il faut être capable de choisir le langage adapté à la tache et à l'environement. Je n'utilserais pas du C pour faire un programme qui fait des manipulations complexe de chaine de caractère sur un petit volume de donnée une fois par mois, tout comme je n'utilserais du bash pour faire un calcul scientifque complexe qui tournera sur un gros serveur de calcul.

Pour revenir au sujet de base : le garbage collector, J'ai eu un soucis il y a de cela quelque temps :
Un petit programme pas extrèmement compliqué qui lisait un fichier ligne par ligne. Il découpait la lignes, faisait quelques traitement et reassemblait une nouvelle ligne pour la sortie.
J'ai fait une première version de ce programme en Lua, ce fut rapide à programmer, mais le programme devenait vite lent à mourir des que le fichier grossisait un peu.Sur le moment je n'avais ps le temps de chercher plus loin, j'ai donc recoder le truc en C en au final c'est les disque qui ne suivait plus le rythme. (ce qui dans mon cas n'était pas génant puisque la sortie du programme était traiter par un autre programme qui prenait le reste du temps CPU)
Quelques temps plus tard, je me repenche sur le problème pour en déterminer la cause. J'aime beaucoup utiliser des langages de scripts pour prototyper des programmes ou pour des petits dévellopement qui n'on pas à être particulièrement rapide. Lua est un langage que j'apprécie beaucoup et donc j'avais envie de savoir d'ou venait vraiment le problème. Après investigation, le problème venait à la fois du GC et du fait que les chaine sont imutables dans lua : chaque ligne représentait un objet, mais aussi chaque morceau de la ligne découpée, chaque étape de transformation de ces morceaux ainsi que la ligne finale. Ce qui fait que pour chaque ligne traité, de nombreux petits objets était créés et le GC se déclenchait sans arret et libérait tous ceux des lignes précédentes. Bref pas mal de boulot inutile.
La version en C utilisait juste deux buffer alloués statiquement.

Cet exemple est, en partie, lié à la gestion des chaines imutable de lua, mais surtout met en avant le problème de ces langages de haut niveaux : Il y a beaucoup de choses qui sont cachées et que l'on ne peut pas forcément prédir et dont on ne connait pas forcément les conséquences. Et l'utilisation d'un GC peut cacher certains problèmes qui serait explicite sans eux.

C'est quand tous les outils, il font utiliser le bon au bon moment, c'est tout.

Donc, pour en revenir au bench, je maintient que celon moi il est stupide et ne prouve qu'une chose, quand on demande à C++ de faire quelque chose de stupide et qu'on lui demande mal, il est plus lent que OOC.
Ce qui ne donne aucune information sur les perfs réelles de OOC.

Et tu crois vraiment qu'il y a beaucoup de non-francophone qui viennent lire les journaux sur LinuxFR ?

Et même dans le cas où il y en aurait effectivement, ne serais-ce pas plus claire de faire un paragraphe en français et un en anglais, plutôt que ce mélange fort peu lisible ?

Ton benchmark ne prouve qu'une chose, le C++ est plus lent que OOC quand tu lui demande de faire quelque chose de stupide et qu'en plus tu le fait mal.

Il n'y a aucun interet au programme que tu montre et même pire, c'est une des plus mauvaise manière de faire cete chose sans interet. Lorsque un objet doit être alloué et libéré très rapidement et en très grande quantité, la bonne manière de faire est d'utiliser un pool d'objet, tout comme en C quand tu dois allouer et libérer un très grand nombre de petites zones mémoire, tu en alloue un gros paquet d'un coup que tu libère aussi en une fois à la fin.

Tu pourras dire ce que tu veux, ce benchmark ne veut absolument rien dire. La seule bonne manière de faire un benchmark, indépendament du test lui même, c'est déjà de bien connaître les deux langages, et d'écrire un bon code pour chacun d'eux.

Il suffit de regarder les résultats du shoutout pour s'en rendre compte, certains langages se retrouvent à la traine, non pas car ils sont réellement moins bon, mais uniquement car les benchs ont étés codés n'importe comment.

Les benchs c'est super pratique, quand tu veux prouver quelque chose, en cherchant bien tu finis toujours par en trouver un qui approte la preuve que tu veux. Par contre dans la réalité, trouve moi un seul code qui fait quelque chose d'aussi stupide que ton bench.
Dans la réalité, tu ne fait pas juste un ++ sur variable de ton objet mais tu fais un traîtement qui justifie la création de cet objet, donc l'allocation/libération à beaucoup moin d'impact sur les perfs et l'écart ce réduit.
Ensuite dans la réalité, tu fais un profile de ton code et tu t'apperçois que cette gestion mémoire continue d'avoir un impact sur les perf, donc tu utilises un pool, et là, la version OOC n'a plus rien pour elle.

Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement. Le nombre d'objets est connu à la base donc un seul malloc/free est nécessaire dans toutes la durée du programme.
Moralité, même le programme OOC me semble écrit avec les pieds, lui aussi méritrait l'utilisation d'un pool ;-)

C'est surtout que je vois pas vraiment l'intéret de la traduction en anglais sur linuxfr... à part, peut-être, pour faire croire que le journal à plus de contenut que ce n'est vraiment le cas...

Bien au contraire, prouver l'inéxistance de dieu serait une magnifique preuve de son existance. Dieu demande une foi aveugle, et donc ne peut reconnaitre les siens que en démontrant sont inexistance et en observant ceux qui, malgré cette preuve, continuent de croire en lui.

MS a fait un filtre export vers ODF, et, comme par hasard, ça ne respecte pas ODF.

Petite correction, MS à ajouter le support ODF et non pas un filtre d'export, et comme par hasard celui respecte trop bien la norme ODF et donc n'est pas totalement compatible avec les autres suites qui elles aussi respectent cette norme, étant donné que la norme ODF est incomplète.

Tout d'abort félicitations pour ton projet qui continue d'avancer malgré tout ce que l'on a pût dire dans le dernier journal, et j'avoue ne pas avoir été dans les plus tendres...

Et le pire c'est que je reviens à la charge... Avant de commencer je tiens à te dire que je ne fais pas ces remarque méchamant mais que je donne mon point de vue de manière honête. Je suis pas sur LinuxFR pour descendre les projets libre mais je n'y suis pas non plus pour faire de la lèche.

Je me souviens que ton objectif était de «sacrifier le rendu au profit de la simplicité». Et moi quand je vois ta doc, j'ai quand même vraiment l'impression que le rendu tu le sacrifie beaucoup.

Je comprend parfaitement que tu ne veuilles pas te lancer dans le codage des algos très complexe de typo tels que ceux de TeX mais il y a quand même une chose qui moi me parait horibles : l'espacement des caractères dans les mots.
Les logiciels tels que TeX utilisent des infos de kerning présentent dans les polices afin d'obtenir un espace visuellement homogène mais ces complexe à mettre en place. Dans ce cas la le minimum à faire, il me semble, c'est au moin d'avoir un espacement techniquement homogène.
Si je prend le mot «possibilities» au début de la table des matières et que je zoom dessus avec mon lecteur pdf pour compter, entre le «i» et le «e» tu as 4 pixels, alors qu'entre le «s» et le «i» ou bien entre le «b» et le «i» tu en a 8, soit le double.

Je suis peut-être un intégriste de la typographie, mais moi j'ai du mal à lire ta doc à cause de ça, et pourtant elle n'est pas bien longue. Un rapport complet écrit de cette manière, il faudra pas compter sur moi pour le lire.

Ma deuxième remarque est plus nuancée. J'ai vu que tu avais ajouté le support pour les formules mathématiques. et je pense que ces très récent et donc qu'il y a encore beaucoup de boulot à faire avant que l'on puisse parler d'un vrai support. Mais pour être honête, vu leur rendu actuel, pour une formule un peu complexe je préfère lire directement son code en TeX que ce que tu produit.

Donc pour conclure, je pense que tu ne dois pas arrêter ton projet, bien au contraire. Par contre, à mon avis, tu devrais pour l'instant mettre de côter les fonctions marrantes du style les diagrammes en camembert ou les formules et te concentrer quand même un peu sur le rendu.
Tu es peut-être près à sacrifier le rendu mais dans ce genre d'outils il faut surtout penser au lecteur. Quand tu écris un rapport, c'est très bien d'avoir un outils simple pour le faire, mais si ces pour obtenir un document horrible à lire ce n'est pas la peine.
Dans l'état actuel, si on me rend un rapport (purement textuel) écrit avec Quapote, j'aurrais beaucoup de mal à l lire en entier et au moment de noter le rapport, cela ce sentira sûrement.

La typographie n'a pas besoin d'être parfaite, mais je pense qu'il ne faut pas la négliger complètement non-plus. Il y a une grosse part d'incoscient dans ça perception. Quand elle est parfaite, le plus souvent les gens ne le remarquent pas, mais quand ça commence à déraper, même les plus tolérants finissent par grogner.

Un autre problème c'est que modifier le matos réseau ça coute du temps et de l'argent tandis que changer la config des machines, suivant de quoi tu part, ça coute du temps.

De plus, dans le cadre évoqué de serveurs de calculs, le réseau doit souvent être partagé entre les transferts de données via NFS et ceux effectués directement par l'algorithme pour la parllélisation du calcul.
Si une grosse majorité des données snt disponibles en local, on limite les transfert NFS et donc on libère de la bande passante pour MPI par exemple.

Donc le choix entre améliorer le réseau ou la localisation des données dépend de ce que tu fais. Dans mon cas par exemple, sur le petit cluster ou j'ai travaillé, j'ai gagner énormément en perf lorsque j'ai modifié un programme parrallèle pour qu'il utilise les disque dur locaux plustôt que le NFS pour le stockage des données.

Chaque machine accede dans plus de 80% des cas à ses données donc il reste moins de 20% du temps ou les données circules sur le réseau qui est quasiment entièrement libre pour les message de MPI.

Tout ça pour dire que le réseau est loin d'être la seule solution de même que le choix entre :
- données centralisées et cache local sur les machines ;
- donnée réparties et système d'accès à distance.

Il n'y a pas de solution miracle et ça dépend vraiment des applications qui tournent sur le système.

fclose non plus ne t'assure pas que les données sont sur le disque :

man 3 fclose
Notez que fclose() ne vide que les tampons fournis par la bibliothèque C dans l’espace utilisateur. Pour s’assurer que les données sont écrites physiquement sur le disque, il faut aussi vider les tampons du noyau à l’aide, par exemple, de sync(2) ou fsync(2).

Il faut vraiment un sync pour être sûr que les données soient bien écrites.

Heureusement qu'il y a pas trop de gens dans le monde qui prennent ça pour une insulte sinon il y a bien longtemps qu'on l'aurait eu la guerre termonucléaire...

Alors bien sûr, tu peux voir dns ma dernière phrase du «dénigrement implicite» et je te le dit tout de suite c'est voulu, mais ce n'est pas pour cela que je t'insulte. Je ne te demande même pas d'essayer d'y voir un brin d'humour.

Donc je maintient qu'il faut desserrer le string et arrêter de se prendre pour un martyr.

Faut pas exagérer non plus. Dis moi où tu vois une insulte dans son message.
Faut desserrer le string de temps en temps et arrêter de ce prendre pour un martyr.

Je ne crois rien. Ce que je dis c'est que dans le cas dont on parle depuis le début du fil, c'est à dire dans le cas ou l'on a 87% de chance de récupérer chaque bit, il est tout à fait possible de récupérer beaucoup d'information de manière fiable.

Le seul problème c'est que vous avez finit par comprendre que en effet c'était le cas et maintenant vous chercher à vous rattraper au branches en signalant que atteindre ce taux est difficile voir impossible.

Pas de bol, depuis le début on s'est bien placer dans ce cadre et donc vous pouvez sortir tout ce que vous voulez, ça ne changera rien.

Donc je le repette une dernière fois : "Dans le cas ou l'on a une probabilité de 87% de retrouver chaques bit, il n'y a aucun problème à retrouver beaucoup d'informations avec une grande fiabilitée. Dans un cas réaliste quelconque, on se tape de savoir si il y a du bruit ou quoique ce soit, de toute façon le gens lorsqu'il jette des disque, c'est qu'il a servit quelques temps, donc la probabilité deviens ridicule."

Vous sous estimez totalement le problème de localisation des données

Le problème de localisation est une forme particulière du prolème de récupération. Tu as un gros ensemble de données et tu connais une signature particulière. Avec un viterbi tu cherche quelle sont les position dans tes données qui ont la plus forte probabilitée de correspondre à ta signature.
C'est le principe de la resynchronisation de flux à travers un canal bruité et ça ce fait très bien.

coté irréaliste d'un scan avec un microscope à force atomique ou magnétique d'une surface de cette taille.

Pas du tout, le raisonement est le suivant : Dans le cas ou l'on peut récupérer une image du disque dur ou chacun des bits à 87% de chance d'être correcte il est possible re retrouver énormément d'informations.
Le cadre était clairement placé depuis le début du fil, et le fait que ce cadre soit difficile, voir quasiment impossible, à mettre en place ne change rien au fait qu'une fois en place il n'y a aucun problème pour retrouver de l'information.

Il faut bien voir que toute la discution ici est purement théorique. Vu l'état actuel des technologies il est bien sûr inenvisageable de traiter un disque de cette manière et donc une simple réécriture des données rend toute récupération utopique.
Mais, si un attaquant dispose d'une image bruité avec un taux d'erreur de 13%, que ce soit de cette manière ou d'une autre, il peut retrouver énormément d'informations et c'est ça qui est important ici.

Je n'ai pas le temps de le faire pour le moment mais retrouver le texte d'origine dans ce cas n'est pas extrèmement difficile.
Pour savoir comment faire, je te recommande la lecture de cete page de wikipedia : Algorithme_de_Viterbi.

Le principe est simple : onsait qu'a l'origine on a un texte en anglais, ce texte est passé dans un canal bruité qui a 87% de préserver la valeur de chaque bit, donc on cherche quelle est la séquence de texte en anglais la plus probable qui puisse donner cette séquence.

C'est utilisé de manière fréquente notament lors des transmition hertziennes ou le taux d'erreur est en général plus faible mais ou il peut aussi y avoir des erreur d'insertion/suppression de bits qui sont plus dures à gérer.

Donc il y a de très fortes chance que l'on puisse récupérer au moin une version très proche de ton texte d'origine.

Tu peut même améliorer encore les perfs si tu as des infos sur le contenu du texte d'origine. Si le disque récupéré proviens d'un entreprise, tu peut tenter une récupération en biaisant les probabilités du vocabulaire propre au domaine d'activité de cette entreprise.

Ce qu'il faut bien voir c'est que les deux scientifiques en question on raison MAIS dans le contexte très particulier de leur études :
- Il est improbable de récupérer de manière 100% sure le contenu du disque sans information sur celui-ci et si le disque à été utiliser quelques temps.
Par contre :
- il est tout à fait possible de récupérer de portion de contenus avec une bonne confiance si l'on dispose d'information sur ce contenu (ce qui est quasiment toujours le cas) et si le disque n'a été utilisé qu'une seule fois (ce qui n'est jamais le cas ou presque)

Personne ou presque ne jette un disque ou tu as 87% de chance de récupérer les bits, c'est à dire un disque qui n'a été utilisé qu'une fois. Par contre dans le cas ou tu le fais, il est tout à fait possible de retrouver du contenus.

C'est là le problème...

En effet si c'est réellement 87% de on ne sait pas quoi, on irra pas loin. Mais en pratique c'est plustôt 87% de j'ai une petite idée de ce qu'il peut y avoir quelque part sur le disque.

Imaginons que tu récupère un disqu de la société Bidule et que tu te doute qu'il y a dessus des lettres que tu as envie de lire. Tu sais que la secrétaire utilise le logiciel Truc pour taper ces lettres.

Après une petite analyse, tu vois que le logiciel Truc met un entête "FICHIERTEXTELOGICIELTRUC" au début de chaque fichier et ensuite le contenu de la lettre en ascii.

Tu parcours le disque à la recherche d'une chaine de bit, alignée sur un octet, et dont la distance de haming avec l'entête est faible (probablement au alentour de 0.87 ;-). À chaque fois que tu la trouve, il y a une bonne probabilitée que la suite soit une lettre tapée par la secrétaire. A ce moment la, tu récupère la suite, et tu sais que c'est de l'ascii et que cela représente des mots, suposé cohérents. Donc tu utilise un algo qui permet de recupéré un message passé dans un canal bruité du style Algorithme_de_Viterbi et tu récupère la lettre.

Bien sûr la c'est un exemple simpliste, mais dans la pratique tu as presque toujours un minimum d'information. Si tu sais le systeme d'exploitation qui était utilisé, tu peu souvent deviner le système de fichier et donc savoir comment les données sont organisées sur le disque.
Quasiment tous les formats de fichiers ou des entêtes plus ou moins fixe, cela facilite leur repérage, et une fois que tu les a repéré, vu que tu connais le type de fichier tu peut tenter une récupération.

Pour du texte brut, une perte de 13% des bits c'est loin d'être énorme, et avec de bons modèles $n$-grammes et un viterbi, à mon avis tu peux récupéré sans trop de problème le texte d'origine.
Pour des données binnaire par contre c'est bien plus dur car il te faut un bon modèle probabiliste de ce que tu t'attend à retrouver, et souvent c'est dur à avoir. En plus les formats binnaire éssaye souvent de réduire la redondance au max, donc grosse difficultée.

Pour de fichiers compressé par contre la récupération deviens presque impossible dans le cas d'algo générique. Par contre, il y a pas mal d'algo qui sont fait pour tolérer les erreur : une erreur dans le flux d'entrée produit des artefact dans le flux de sortie mais n'empeche pas de récupérer le reste. Donc avec un bon modele, il devrait être possible de recupérer une info, même si celle-ci est dégradée, un peu comme la negie sur un télé lorsque la réception est mauvaise.

Faut qand même faire gaffe et réfléchir un peu avant d'attribuer les tords à l'un ou à l'autre. Sinon, on finit par tomber dans une "époque décomplexée" comme la notre...

Que penser d'une commune ou le maire fait démonter tous les térrains de jeux pour enfants suite à un procès perdu face à des parents dont le gamin s'est cassé le bras en tombant du tobogan ?

Je connais certaines persones à qui j'ai répété un paquet de fois que lorsqu'ils reçoivent un mail d'une personne qu'ils ne connaissent pas, on ouvre pas la pièce jointe. Ça ne les empêche pas de continuer à le faire et là, Microsoft n'y est pour rien.
Il le savent, mais de souvent c'est juste une image marrante ou un powerpoint à renvoyer à tout le monde, et parfois un méchant virus... Ils prennent le risque, et réinstallent Windows s'ils ont pas de bol.

Donc oui Windows est une merde au niveau sécuritée, mais faut pas oublier que certains utilisateurs sont aussi des abrutis.