Je ne suis pas d'accord sur le terme 'manuelle' ; pour moi la gestion mémoire de Rust est automatique, mais faite (en grande partie) à la compilation, et pas à l'exécution (comme avec les langages à GC)
Yep, tout comme les techniques de RAII à la C++11 ( en particulier unique_ptr ) qui définit à la compilation le/les scopes et l'ownership de l'objet.
Il est difficile de qualifié ce genre de memory management, ce n'est pas vraiment "manuel" car il y a une forme d'automatisme, mais ce n'est pas non plus complètement automatique, car contrairement un GC traditionnel, le développeur a le contrôle de la durée de vie de l'objet, de sa destruction, voir de sa stratégie d'allocation.
C'est justement là tout l’intérêt du model: s'offrir 90% de la facilité d'un système de mémoire "complètement automatisé" tout en gardant la possibilité d'avoir une gestion "fine" quand le besoin s'en fait sentir.
Mes excuses si ce que j'ai dit était confus précédemment. Pour moi "manuel" signifie tout ce qui n'est pas sur base de GC et qui donne un control manuel, y compris la RAII.
Mouarf. Soit les bibliothèques et applications C qui ont régulièrement des trous de sécu et des fuites mémoire sont écrites par des clampins (c'est quand même ballot, ça : ils auraient dû demander l'aide des gens comme toi), soit tu surestimes largement la protection contre les défauts qu'apportent des compétences en programmation bas niveau.
La "safety" d'un langage et sa gestion mémoire sont deux chose différentes.
Tu as des programmes vulnérabilité dans Java et PHP tout aussi souvent que dans des bloats en C, pourtant ces langages sont à mémoire managé.
Rust est plus résistant aux buffer overflow que la plupart des langages des script, pourtant sa gestion mémoire est manuel. La différence c'est qu'il a été désigné avec la sécurité en tête comme priorité. Il en va de même pour Swift d'Apple.
Ce que tu constates, c'est que le C est unsafe. Et Oui il l'est.
Il l'est par design dù avec son arithmétique des pointeurs, pas à cause de sa gestion des allocations / desallocations ou parceque tu peux faire des memory pool.
Tu peux d'ailleurs faire un buffer overflow ou créer une faille de sécurité en C sans même faire une seule allocation dynamique.
l'arithmétique des pointeurs en C te permet de te promener partout en mémoire, pratiquement sans restriction… forcement ça a un cout en terme de sécurité, même si c'est extrêmement puissant
Les sociétés de courtage manqueraient-elles de pragmatisme ?
Sinon, je n'ai jamais croisé d'universitaire qui m'a soutenu qu'un système avec GC pouvait faire mieux que du C sur le plan de la latence (remarque de bon sens, un GC rajoute toujours de l'overhead).
On doit pas connaitre les même société de Fast-Trading alors.
Au passage… "Jane Street Capital" est une société de Trading, pas de "Fast Trading".
Les vrai sociétés de Fast trading que je connais ( comme Jump Trading aux USA ) vont jusqu'à recoder leur propre driver InfiniBand qu'ils pour gagner quelques nano-secondes sur leur opérations.
Toute leur stack logiciel est en C/C++, ils disposent de leur propre supercomputer et sont présent chaque année dans les plus grosses conférences du monde HPC (SC ou ISC) juste pour tenter comment gagner un petit poil de latence sur leur transactions.
Ces gens là te rigoleront à la figure dés que tu commenceras à leur parler de Garbage Collector ou d'OCaml. Et sincérement, ils auront raison.
Dans le cas général (oui on va parler de temps réel dur, d'embarqué, etc), le préfère définitivement laisser un gc s'occuper de ça et si je rencontre un problème le paramétrer ou passer le bout de code qui pose problème « Off the heap », plutôt que de faire l'inverse.
Dans le cas général, tu laisses la RAII et malloc() gérer ça. Dans le cas où tu utilises un home-made Allocator pour faire des (millions) d'allocations en chaine de petit objets, c'est déja un cas qui tuerait 90% des GC.
Pour faire ce genre de choses il te faut une vision assez précise des cas d'utilisation. Pour cet exemple, il faut savoir quelle va être la quantité de mémoire utilisée (ou faire une estimation)
Généralement en C/C++, tout bon allocator est une chaine d'allocator. Tu fais une estimation pour une première pool X, si elle se remplit tu alloues une deuxième pool Y, si elle se remplit, tu te rabas sur malloc() ou similaire.
Il y a un trés bon talk à la dernière CPPcon sur le sujet si certaines personnes sont interessées.
D'une part un compteur de référence est une forme de garbage collector
On peut jouer avec les mots, mais ce n'est pas un garbage collector classique mark & sweep ou generationel et ça n'en a pas les propriétés. Ça n'a ni les problemes de lifetime associés au GC GC classiques, ni les problemes de surconsommation memoires ( meme si ca en a d'autres ) . Ce qui le rend par ailleurs beaucoup plus facile a interfacer avec du C/C++ que du Java… entre autres…
Inexact. En fonction de la façon dont ton application alloue et désalloue la mémoire, un GC peut s'avérer plus performant qu'une gestion manuelle. En particulier si tu as des structures profondes (arbres ou listes) que tu modifies peu au cours de leur vie (i.e tu les alloues, tu les utilises sans les modifier, puis tu les désalloues). Dans ce cas, un bon GC pourra tout désallouer d'un coup alors qu'une gestion manuelle t'obligera à désallouer chaque nœud de ta structure.
Pour reprendre ton pattern.
Non. Une gestion manuelle bien fait sera toujours plus performante et plus facile à profiler. Un GC peut savouer un poil plus performant qu'une gestion manuelle naive dans certains cas précis. Le cas que tu cites se résoud avec une simple Memory Pool local au life time de ton graphe.
Faux. Il existe des GC temps réel (donc qui garantissent une latence max). Bien sur, on n'a rien sans rien et ces GC sont généralement encore plus gourmands en mémoire que les autres.
Non. Ça c'est ce au'on nous annonce depuis 10 ans environ. Fait est qu'en pratique, même Android malgrés les sommes colossales investi par Google dans Dalvik, continue d'avoir des problèmes de latence associés á son GC.
Note que de toutes façons ceux qui développent des systèmes vraiment critiques en termes de performances (jeux, par ex.) évitent les allocations dans la partie critique (aussi bien avec un GC, qu'avec malloc) car ni l'un ni l'autre n'ont de performances garanties.
Non. Ça c'est la théorie. En pratique tu ne peux pas éviter d'avoir des allocations même dans la partie critique. Ce que en C/C++ tu compenseras par un pool allocator, un stack allocator ou par l'utilisation de jemalloc, tcmalloc ou le tbbmalloc si ton problème vient d'un haut niveau de concurrence. Toutes ces strategies sont communément deployé dans des apps que vous utilisez tous les jours ( jeux video, database, server web, etc, etc )
Moi je remarque surtout que des langages massivement plus lents que ça sont lourdement utilisés en production (Javascript, Ruby, PHP, Python, etc.),
Python n'utilise pas de garbage collector mais un compteur de référence, tout comme Swift et PHP. PHP a une fonction "GC", mais que de nom, c'est en réalité un simple détecteur de référence cyclique.
Ceci dit, je suis entièrement d'accord avec toi. Les languages à GC sont populaires, ils tendent à rendre le memory model des applications grand publique plus simple et plus safe et, j'ai envie de dire, c'est tant mieux !
Ce qui tend par contre à m'énerver, c'est cette légende populaire (largement véhiculé par le monde académique d'ailleurs) qui prétend que les garbages collectors ont un coût en terme de performance nulle, qu'ils sont une solution parfaite et sans effet de bords… et qu'ils vont tôt ou tard conquérir le monde et remplacer tous les langages à memory management fine grain, C inclu.
Je ne compte même plus le nombre de petit boutonneux sortis de l'école qui m'ont débalé ce genre d’âneries.
Non, tous les langages qui supporte un memory management sans GC ( C, C++, Rust, Ada, Swift, Python ) n'ont pas été inventé par des imbéciles. Il y a des raisons à un memory management manuel ou à un ref counter: un GC a un coût, en terme de performance, en terme de ressources ( 2x à 8x la quantité de mémoire ), en terme de déterminisme, en terme de latence.
Si ce coût est acceptable pour des services de petite et moyenne taille, il l'est beaucoup moins quand on parle de jeux videos, de 3D, d'application système lourde, de calcul scientifique ou simplement de systèmes embarqués.
Je pense qu'il serait bon d’arrêter l’hypocrisie et d'enseigner la programmation un poil plus pragmatiquement. Spécialement en ce qui concerne certains aspects comme le memory management ou le multi-theading.
Ça se discute : Java a des performances proches du C. Ocaml est également connu pour ses performances proches du C et utilise aussi un GC.
Dépend de ta définition de "proche".
Si tu prends les benchs du shoutaut que j'ai mis en lien plus haut et que je considère comme une réference en terme d'optimisation. Java est généralement entre 10% et 20% plus lent que C/C++. OCaml est encore plus loin derrière.
L'écart tend même à se creuser sur dés que l'on commence à travailler avec un grand nombre d'objets, à parler multi-threading ou NUMA. Il y a une plétoire de publications à ce sujet ( genre là, là ou là ).
Si un bon nombre de DB NoSQL en Java comme Druid ont fait le choix de ré-implémenter leur propre mémory allocator, c'est pas juste pour décorer et histoire d'être unsafe.
Allez, juste pour le plaisir du troll et parce que c'est Lundi. Une petite dédicace venant de la FAQ de cassandra:
"In most cases, the capability of Java to gracefully handle garbage collection above 8GB quickly diminishes."
Cela dit, la mention d’un garbage collector sans précision sur son fonctionnement est un peu inquiétante, pas seulement pour le fonctionnement des destructeurs. Enfin peut-être celui-ci (voire celui de Ruby) fonctionne-t-il mieux que ce que j’ai eu l’occasion de voir avec d’autres langages (pas de libération de mémoire quand on en manque, lancement éventuel du garbage collector… au moment où l’en aurait besoin de performances).
Sans parler que c'est aussi s'imposer une limite concernant les performances…. Ce qui peut être un problème pour un langage qui se veut "avec des performances proches du C".
Un langage avec GC fait le choix de troquer de l'usabilité contre le déterminisme et la gestion fine de la mémoire. Et ça a un impact en terme de performance qui d'ailleurs s'illustre assez bien sur le Computer Language Benchmarks Game.
Dans le meilleur des cas, Crystal pourra rivaliser avec Go ou Java… mais pas avec C, C++ ou Rust.
Juste pour donner quelques chiffres: les 15 porte-containaires les plus polluants rejettent autant de soufre que l'ensemble du parc automobile mondial.
Ton point de vue est intéressant. Mais tu loupes à mon sens un aspect essentiel: la localité.
Ce que je reprocherai le plus au parc automobile ( specialement diesel), c'est la localité, pas la quantité. La pollution automobile est indissociable de la ville elle-meme et ça c'est un problême
Même si il est terriblement polluant, ton porte containers ne crache pas sa merde sous tes fenêtres à Paris, ne re peint pas tous les monuments de ta ville en couleur goudron en moins de 5 ans, et ne cause pas de crises d'ashme par un fog omnipresent aux gamins qui respire ca en permanence.
Ton porte container est sale, mais il est en mer. Son principal problème c'est ses emissions CO2. A l'opposé le principal problème de l'automobile, c'est tout le reste.
La voiture électrique peut être une solution à ces problèmes, bien plus qu'a celui du CO2
C'est ça la réponse des concepteurs de compilateur a cette horreur que sont les templates?
Pourquoi les concepteurs du langage ne se sont pas occupés de ce problème en amont? En obligeant l'instantiation explicite des templates, en séparant l'implémentation des templates dans des fichiers séparés
Si c'était si simple, le problème aurait été réglé depuis longtemps.
La généricité des templates en C++ est bien plus puissante et poussée que les demi-generics dans des languages comme Java par exemple.
Ça empêche tout type d'instanciation / compilation tant que les types dont ils dépendent n'ont pas été spécifiés. Forcer leur implémentation dans des fichiers séparés ne changeraient rien au problème, il faudrait toujours les parser à chaque spécification.
#ifndef est quand meme vachement utile pour eviter de parser 25 fois le meme header.
Ça rends les choses "moins pire" on va dire. #ifndef t'empechera de parser 25 fois le même header pour compiler le même fichier source.cpp mais il te fera quand même parser 100 fois le même header si tu l'inclues 100 fois depuis différents fichiers.
Ça reste acceptable si tes headers sont de simple déclarations et des forwards comme en C. Ça l'est malheureusement beaucoup moins quand les headers contiennent du code templaté comme en C++.
Le gros soucis avec le "#include header" c'est que c'est stateful. Le résultat de ton include varie suivant les déclarations ou pre-processor précédent ton include…. Et ça c'est un cauchemar à optimiser / pre-compiler pour un compiler.
Il faut absolument sortir du langage les commandes préprocesseurs. Aujourd'hui, il est impossible de faire un logiciel en C++ sans utiliser la commande #include. C'est pas normal qu'un langage doive s'appuyer sur un autre pour fonctionner.
Je dirais que c'est pas tellement un problème de préprocesseur. Le fond du problème est que le systeme d'include est a la fois trop bas niveau pour être simple d'utilisation et trop primitif pour être efficace.
Trop bas niveau car contrairement aux "import X" des autres languages, les includes C/C++ force encore à gérer manuellement la séparation déclarations / implémentations, les forwards, les guards, etc, etc
Trop primitif car les temps de compilation affreusement long du C++ viennent principalement du fait que par design, les headers doivent etre re-parsé a chaque inclusion.
Mais la déchéance de nationalité je suis pour, vu que ça n'a rien à voir. Mais voilà, chez les gauchistes, sous prétexte de la défense des libertés on ajoute son petit grain mélenchoniste…
La déchéance de nationalité est une grosse connerie, et tout le monde le sait.
Rien d'autre qu'une belle opération de populisme pour plaire aux électeurs de la droite dure et faire du jeu de jambes aux électeurs du FN ( et occuper l'espace médiatique au passage ).
Il y a une personne saine d'esprit qui pense qu'une personne prêt à se faire exploser en public va y réfléchir à deux fois parce qu'il risque de perdre son passeport ? Sérieusement ?
Sans parler du fait que la place de tout individu dangereux ayant commis un tel acte est en taule, sous contrôle, et pas dans son pays d'origine en liberté, si il en a un.
Ce genre de loi ne peut que finir détournée, ou servant de prétexte pour foutre dehors un individu X ou Y pour ses activités politiques, ou pour son journalisme un peu trop poussé, comme ça se fait très bien dans certains pays dictatures.
J'ai surtout l'impression que ce magnifique amont de bullshit sert à renforcer le sentiment que "le terrorisme, c'est les autres, les étrangers, les immigrés".
Nan les gars, je désolé pour vous, mais toutes les tragédies récentes en France, ce sont des bon français bien nationaux qui les ont faites.
Donc soit on attend 1h que son achat de baguette soit validé, soit on exclut tous ceux qui n'ont pas un i7+SSD ? Rien de critique pour une monnaie en effet.
Non. Tu parles juste sans savoir.
Et ça a déjà été expliqué sur DLFP il y a quelques temps au passage.
Le temps d'attente moyen "original" d'une génération de bloc est de 10 min, et tu n'attends pas non plus 10 min pour acheter une baquette.
Il n'y a nullement besoin d'attendre qu'une transaction soit inscrite dans la block-chain pour considérer qu'elle soit valide. La plupart des clients considère une transaction comme "valide" si elle a été propagé sur une majorité des nœuds du réseau sans refus.
Pour faire un parallèle avec le système bancaire :
La validation par un nombre de noeud "X", c'est comme le paiement par Carte Bancaire. Tu reçois l'argent, mais il y a toujours une possibilité de refus plus tard si la carte qui t'a payé a été volé.
L'inscription dans la block-chain, c'est le virement bancaire, avec confirmation écrite de la banque. C'est définitif et indélébile.
La plupart des solutions de paiement Bitcoin, Bitpay entre autres, n'attendent bien évidemment pas 10min pour confirmer que le paiement est effectif. Il considère la transaction comme valide après une propagation sur une profondeurs de 6-8 noeuds ( quelques secondes suffisent ).
De plus, 50% n'est qu'une barrière théorique, en réalité tout est question de probabilité. Par exemple la pool AntPool possède ~25% de hash rate, ça veux dire qu'elle a 1 chance sur 4 de réussir une modification de la blockchain. Ce qui est déjà beaucoup.
Et ça ne change rien.
Même avec 25%, 50%, 75% de réussir une modification ne signifie pas pouvoir tricher. Une transaction "malhonnète" sera tout de même refusée par le restant des noeuds "honnêtes", et la block-chain forkera, rendant la triche visible aux yeux de tous.
Ceci dit oui, je suis d'accord avec toi sur le fait que les grosses pools sont un problème. Mais là encore, rien de nouveau.
Techniquement cet argument est faux, car les transactions sont organisées sous forme d'arbre, un arbre de Merkel plus exactement. Il suffit « d'élaguer » les branches qui sont trop grosse, voir même juste garder le hash de chaque blocks (c'est simplifié, mais c'est l'idée).
C'est un filtre de Bloom backé par un arbre de Merkel pour être parfaitement exacte. Et non l'élagage ne résout pas tout: il est toujours nécessaire de stocké clé + valeur de tous les acomptes ayant un seuil positif, ça prends de la place, et ce n'est pas compressible.
Sans parler que le concept d'élaguage et de check points a d'autre problèmes, comme la perte potentiel de l'historique du réseau, ou la perte des méta-data associées aux transactions ( commentaires, indexing par ID ). Ce n'est pas aussi simple que ça en a l'air.
C'était le début du débat, et comme tu peux le voir, la situation n'a pas évoluée depuis.
C'est justement mon point.
Je n'arrive pas à te comprendre, est-ce-que pour toi ça sent le FUD juste parcequ'il n'y a rien de nouveau sous le soleil ? Montre en quoi les arguments de Mike Hearn sont fallacieux pour montrer que c'est du FUD.
Ce qui est fallacieux, c'est de présenter des faits qui sont là depuis longtemps comme "la fin de Bitcoin" juste pour créer le buzz et la spéculation qui va avec.
Mais là encore, rien de nouveau… Les mouvements de paniques ne se compte même plus dans l'histoire de Bitcoin…
Et comme je l'ai dit plus haut, si il y a une chose à mon humble opinion qui risque de tuer Bitcoin, c'est son instabilité permanente et son utilisation comme pure produit de spéculation, pas ses défauts techniques.
Si c'est le cas, qu'un type quasi-inconnu puisse manipuler les cours en dit long sur la robustesse du bitcoin et sa souhaitabilité comme monnaie.
Ça je ne te le fais pas dire. Et c'est justement un point que l'auteur loupe complétement.
Le plus gros échec de Bitcoin à mon humble opinion n'est pas technique: c'est son incapacité d'avoir résister à la spéculation et son échec de s’être développé comme réel medium d'échange.
Bitcoin n'est maintenant que relayé et utilisé comme un produit spéculatif parmi d'autres.
Ce ne sont pas des détails, lorsqu'une pool a le pouvoir de modifier la blockchain (attaque des 50%), il y a de quoi s'inquiéter !
Je ne pense pas être un expert de l'historique de Bitcoin, mais ce n'est à ma connaissance ni la première fois ni la dernière fois que ça arrive. De mémoire, ça c'était déja produit lors de l'introduction des ASIC avec la pool "asicminer". La pool s'était disloqué progressivement aprés l'annonce, comme celle là risque de le faire.
Ce qui serait inquiétant, c'est si une pool avait essayé d'effectivement généré de la faussé monnaie.
Lorsque le développement est trusté par des personnes malhonnêtes, c'est très alarmant. Ce qu'il fait là dans son article est une synthèse de l'état de actuel, ne crois-tu pas ?
Ça doit faire maintenant plus d'un an que je ne suis plus le developpement de Bitcoin, et pourtant il y a un an il y avait déjà des discussions qui pullulaient sur le forum officiel sur la taille des blocks et l'interet de l'augmenter ou pas.
Certains y voyait une nécessité pour des transactions rapide, d'autre y voyait une barrière a ne pas franchir car ça augmenterait drastiquement la taille de la blockchain au point de rendre impossible son utilisation sur des configurations modeste. Rien de critique la dedans.
Certains des arguments qu'il avance sont fondés, comme la taille des blocs et les limitations que ça imposent en terme de transactions par seconde, mais la plupart est pure FUD sur des détails connus depuis longtemps comme les pools de Hong Kong.
Son action a surtout l'air d'une bonne grosse opération de spéculation. Le type revend tous ses bitcoins et prêche l'apocalypse, fait baisser massivement le cours et disparait juste après… Ou miraculeusement le cours remonte, juste après la tempête médiatique.
Je n'ai parlé que du président de la MoFo, du trésorier, du directeur, etc.
Ce sont des fonctions classiques d'administration et je ne vois pas pourquoi cela mériterait un salaire d'un million de dollars par an.
Et tu as parfaitement raison, je réagissais uniquement à la remarque de rewind sur "motivation vs salaire".
De manière générale, j'aurai tendance à dire que des différences de salaire de plus de 10x (20x max) entre le bas de l’échelle et le haut de l’échelle d'une société est déjà très discutable.
Mais dans le cadre d'une associations à but non lucratif qui fait des appels de dons, et à une telle échelle de salaire, c'est assez honteux oui.
Non mais il faut arrêter avec cet argument à la con. Les gens ne sont pas motivés que par l'argent. Il existe des gens très compétents qui feraient sans doute mieux pour 10 fois moins d'argent (et ça représente déjà beaucoup)
Oui, le petit étudiant sur-doué qui acceptera peut être de bosser pour des guenilles pendant deux ans.
Et après il fera comme les autres, il ira voir ailleurs où on doublera son salaire.
C'est pas pour rien que les salaires d'ingénieurs de Google, Intel, Facebook and co sont si élevés.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1. Dernière modification le 10 mai 2016 à 23:26.
Yep, tout comme les techniques de RAII à la C++11 ( en particulier unique_ptr ) qui définit à la compilation le/les scopes et l'ownership de l'objet.
Il est difficile de qualifié ce genre de memory management, ce n'est pas vraiment "manuel" car il y a une forme d'automatisme, mais ce n'est pas non plus complètement automatique, car contrairement un GC traditionnel, le développeur a le contrôle de la durée de vie de l'objet, de sa destruction, voir de sa stratégie d'allocation.
C'est justement là tout l’intérêt du model: s'offrir 90% de la facilité d'un système de mémoire "complètement automatisé" tout en gardant la possibilité d'avoir une gestion "fine" quand le besoin s'en fait sentir.
Mes excuses si ce que j'ai dit était confus précédemment. Pour moi "manuel" signifie tout ce qui n'est pas sur base de GC et qui donne un control manuel, y compris la RAII.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
La "safety" d'un langage et sa gestion mémoire sont deux chose différentes.
Tu as des programmes vulnérabilité dans Java et PHP tout aussi souvent que dans des bloats en C, pourtant ces langages sont à mémoire managé.
Rust est plus résistant aux buffer overflow que la plupart des langages des script, pourtant sa gestion mémoire est manuel. La différence c'est qu'il a été désigné avec la sécurité en tête comme priorité. Il en va de même pour Swift d'Apple.
Ce que tu constates, c'est que le C est unsafe. Et Oui il l'est.
Il l'est par design dù avec son arithmétique des pointeurs, pas à cause de sa gestion des allocations / desallocations ou parceque tu peux faire des memory pool.
Tu peux d'ailleurs faire un buffer overflow ou créer une faille de sécurité en C sans même faire une seule allocation dynamique.
l'arithmétique des pointeurs en C te permet de te promener partout en mémoire, pratiquement sans restriction… forcement ça a un cout en terme de sécurité, même si c'est extrêmement puissant
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3. Dernière modification le 10 mai 2016 à 16:34.
On doit pas connaitre les même société de Fast-Trading alors.
Au passage… "Jane Street Capital" est une société de Trading, pas de "Fast Trading".
Les vrai sociétés de Fast trading que je connais ( comme Jump Trading aux USA ) vont jusqu'à recoder leur propre driver InfiniBand qu'ils pour gagner quelques nano-secondes sur leur opérations.
Toute leur stack logiciel est en C/C++, ils disposent de leur propre supercomputer et sont présent chaque année dans les plus grosses conférences du monde HPC (SC ou ISC) juste pour tenter comment gagner un petit poil de latence sur leur transactions.
Ces gens là te rigoleront à la figure dés que tu commenceras à leur parler de Garbage Collector ou d'OCaml. Et sincérement, ils auront raison.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Dans le cas général, tu laisses la RAII et malloc() gérer ça. Dans le cas où tu utilises un home-made Allocator pour faire des (millions) d'allocations en chaine de petit objets, c'est déja un cas qui tuerait 90% des GC.
Généralement en C/C++, tout bon allocator est une chaine d'allocator. Tu fais une estimation pour une première pool X, si elle se remplit tu alloues une deuxième pool Y, si elle se remplit, tu te rabas sur malloc() ou similaire.
Il y a un trés bon talk à la dernière CPPcon sur le sujet si certaines personnes sont interessées.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 4. Dernière modification le 10 mai 2016 à 09:16.
On peut jouer avec les mots, mais ce n'est pas un garbage collector classique mark & sweep ou generationel et ça n'en a pas les propriétés. Ça n'a ni les problemes de lifetime associés au GC GC classiques, ni les problemes de surconsommation memoires ( meme si ca en a d'autres ) . Ce qui le rend par ailleurs beaucoup plus facile a interfacer avec du C/C++ que du Java… entre autres…
C'est plutot bien detaillé ici par ailleurs ( http://effbot.org/pyfaq/how-does-python-manage-memory.htm )
Pour reprendre ton pattern.
Non. Une gestion manuelle bien fait sera toujours plus performante et plus facile à profiler. Un GC peut savouer un poil plus performant qu'une gestion manuelle naive dans certains cas précis. Le cas que tu cites se résoud avec une simple Memory Pool local au life time de ton graphe.
Non. Ça c'est ce au'on nous annonce depuis 10 ans environ. Fait est qu'en pratique, même Android malgrés les sommes colossales investi par Google dans Dalvik, continue d'avoir des problèmes de latence associés á son GC.
Non. Ça c'est la théorie. En pratique tu ne peux pas éviter d'avoir des allocations même dans la partie critique. Ce que en C/C++ tu compenseras par un pool allocator, un stack allocator ou par l'utilisation de jemalloc, tcmalloc ou le tbbmalloc si ton problème vient d'un haut niveau de concurrence. Toutes ces strategies sont communément deployé dans des apps que vous utilisez tous les jours ( jeux video, database, server web, etc, etc )
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à -3.
Le monde académique bien Français, bien universitaire
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6. Dernière modification le 09 mai 2016 à 21:36.
Python n'utilise pas de garbage collector mais un compteur de référence, tout comme Swift et PHP. PHP a une fonction "GC", mais que de nom, c'est en réalité un simple détecteur de référence cyclique.
Ceci dit, je suis entièrement d'accord avec toi. Les languages à GC sont populaires, ils tendent à rendre le memory model des applications grand publique plus simple et plus safe et, j'ai envie de dire, c'est tant mieux !
Ce qui tend par contre à m'énerver, c'est cette légende populaire (largement véhiculé par le monde académique d'ailleurs) qui prétend que les garbages collectors ont un coût en terme de performance nulle, qu'ils sont une solution parfaite et sans effet de bords… et qu'ils vont tôt ou tard conquérir le monde et remplacer tous les langages à memory management fine grain, C inclu.
Je ne compte même plus le nombre de petit boutonneux sortis de l'école qui m'ont débalé ce genre d’âneries.
Non, tous les langages qui supporte un memory management sans GC ( C, C++, Rust, Ada, Swift, Python ) n'ont pas été inventé par des imbéciles. Il y a des raisons à un memory management manuel ou à un ref counter: un GC a un coût, en terme de performance, en terme de ressources ( 2x à 8x la quantité de mémoire ), en terme de déterminisme, en terme de latence.
Si ce coût est acceptable pour des services de petite et moyenne taille, il l'est beaucoup moins quand on parle de jeux videos, de 3D, d'application système lourde, de calcul scientifique ou simplement de systèmes embarqués.
Je pense qu'il serait bon d’arrêter l’hypocrisie et d'enseigner la programmation un poil plus pragmatiquement. Spécialement en ce qui concerne certains aspects comme le memory management ou le multi-theading.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3. Dernière modification le 09 mai 2016 à 12:44.
Dépend de ta définition de "proche".
Si tu prends les benchs du shoutaut que j'ai mis en lien plus haut et que je considère comme une réference en terme d'optimisation. Java est généralement entre 10% et 20% plus lent que C/C++. OCaml est encore plus loin derrière.
L'écart tend même à se creuser sur dés que l'on commence à travailler avec un grand nombre d'objets, à parler multi-threading ou NUMA. Il y a une plétoire de publications à ce sujet ( genre là, là ou là ).
Si un bon nombre de DB NoSQL en Java comme Druid ont fait le choix de ré-implémenter leur propre mémory allocator, c'est pas juste pour décorer et histoire d'être unsafe.
Allez, juste pour le plaisir du troll et parce que c'est Lundi. Une petite dédicace venant de la FAQ de cassandra:
"In most cases, the capability of Java to gracefully handle garbage collection above 8GB quickly diminishes."
.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2. Dernière modification le 09 mai 2016 à 13:31.
Sans parler que c'est aussi s'imposer une limite concernant les performances…. Ce qui peut être un problème pour un langage qui se veut "avec des performances proches du C".
Un langage avec GC fait le choix de troquer de l'usabilité contre le déterminisme et la gestion fine de la mémoire. Et ça a un impact en terme de performance qui d'ailleurs s'illustre assez bien sur le Computer Language Benchmarks Game.
Dans le meilleur des cas, Crystal pourra rivaliser avec Go ou Java… mais pas avec C, C++ ou Rust.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Firwen (site web personnel) . En réponse au journal Comment être un développeur désirable. Évalué à 0.
Merde -1 pour un truc aussi gros. Le trollage du Vendredi sur DLFP n'est plus ce qu'il était.
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par Firwen (site web personnel) . En réponse au journal Comment être un développeur désirable. Évalué à 1.
Tout va bien donc, ce n'était pas réellement un programme.
Visual Basic étant à la programmation, ce que McDonald est à la cuisine
[^] # Re: Cherchez l'erreur
Posté par Firwen (site web personnel) . En réponse au journal Tesla, pas un poisson d'avril. Évalué à 10.
Ton point de vue est intéressant. Mais tu loupes à mon sens un aspect essentiel: la localité.
Ce que je reprocherai le plus au parc automobile ( specialement diesel), c'est la localité, pas la quantité. La pollution automobile est indissociable de la ville elle-meme et ça c'est un problême
Même si il est terriblement polluant, ton porte containers ne crache pas sa merde sous tes fenêtres à Paris, ne re peint pas tous les monuments de ta ville en couleur goudron en moins de 5 ans, et ne cause pas de crises d'ashme par un fog omnipresent aux gamins qui respire ca en permanence.
Ton porte container est sale, mais il est en mer. Son principal problème c'est ses emissions CO2. A l'opposé le principal problème de l'automobile, c'est tout le reste.
La voiture électrique peut être une solution à ces problèmes, bien plus qu'a celui du CO2
[^] # Re: C'est bien dommage
Posté par Firwen (site web personnel) . En réponse au journal C++17 est sur les rails. Évalué à 2. Dernière modification le 15 mars 2016 à 10:54.
Si c'était si simple, le problème aurait été réglé depuis longtemps.
La généricité des templates en C++ est bien plus puissante et poussée que les demi-generics dans des languages comme Java par exemple.
Ça empêche tout type d'instanciation / compilation tant que les types dont ils dépendent n'ont pas été spécifiés. Forcer leur implémentation dans des fichiers séparés ne changeraient rien au problème, il faudrait toujours les parser à chaque spécification.
[^] # Re: cppfix ?
Posté par Firwen (site web personnel) . En réponse au journal C++17 est sur les rails. Évalué à 3.
Il s'est bien amélioré depuis qu'ils utilisent un backend LLVM, et pas qu'un petit peu.
Sur le "The Computer Language Benchmarks Game" de Debian, Rust arrive à faire jeu égale avec C/C++ sur certains benchmarks.
http://benchmarksgame.alioth.debian.org/u64q/rust.html
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=rust&id=1
[^] # Re: C'est bien dommage
Posté par Firwen (site web personnel) . En réponse au journal C++17 est sur les rails. Évalué à 4. Dernière modification le 14 mars 2016 à 20:38.
Ça rends les choses "moins pire" on va dire. #ifndef t'empechera de parser 25 fois le même header pour compiler le même fichier source.cpp mais il te fera quand même parser 100 fois le même header si tu l'inclues 100 fois depuis différents fichiers.
Ça reste acceptable si tes headers sont de simple déclarations et des forwards comme en C. Ça l'est malheureusement beaucoup moins quand les headers contiennent du code templaté comme en C++.
Le gros soucis avec le "#include header" c'est que c'est stateful. Le résultat de ton include varie suivant les déclarations ou pre-processor précédent ton include…. Et ça c'est un cauchemar à optimiser / pre-compiler pour un compiler.
[^] # Re: C'est bien dommage
Posté par Firwen (site web personnel) . En réponse au journal C++17 est sur les rails. Évalué à 2.
Je dirais que c'est pas tellement un problème de préprocesseur. Le fond du problème est que le systeme d'include est a la fois trop bas niveau pour être simple d'utilisation et trop primitif pour être efficace.
Trop bas niveau car contrairement aux "import X" des autres languages, les includes C/C++ force encore à gérer manuellement la séparation déclarations / implémentations, les forwards, les guards, etc, etc
Trop primitif car les temps de compilation affreusement long du C++ viennent principalement du fait que par design, les headers doivent etre re-parsé a chaque inclusion.
[^] # Re: Boulette
Posté par Firwen (site web personnel) . En réponse au journal rm -rf tue votre bios UEFI. Évalué à 0.
Si tu avais pris la peine de lire le lien Phoronix, tu aurais vu qu'on peut faire la même chose sous Windows avec 20 lignes de code.
J'attends le jour où on verra apparaître un "popup.exe" vérolé, téléchargé par Madame Michu, et qui va lui formater en règle son UEFI.
[^] # Re: Gauchistes/Sarkozistes même combat
Posté par Firwen (site web personnel) . En réponse au journal Sortir de l'état d'urgence. Évalué à 10.
La déchéance de nationalité est une grosse connerie, et tout le monde le sait.
Rien d'autre qu'une belle opération de populisme pour plaire aux électeurs de la droite dure et faire du jeu de jambes aux électeurs du FN ( et occuper l'espace médiatique au passage ).
Il y a une personne saine d'esprit qui pense qu'une personne prêt à se faire exploser en public va y réfléchir à deux fois parce qu'il risque de perdre son passeport ? Sérieusement ?
Sans parler du fait que la place de tout individu dangereux ayant commis un tel acte est en taule, sous contrôle, et pas dans son pays d'origine en liberté, si il en a un.
Ce genre de loi ne peut que finir détournée, ou servant de prétexte pour foutre dehors un individu X ou Y pour ses activités politiques, ou pour son journalisme un peu trop poussé, comme ça se fait très bien dans certains
paysdictatures.J'ai surtout l'impression que ce magnifique amont de bullshit sert à renforcer le sentiment que "le terrorisme, c'est les autres, les étrangers, les immigrés".
Nan les gars, je désolé pour vous, mais toutes les tragédies récentes en France, ce sont des bon français bien nationaux qui les ont faites.
[^] # Re: Belle tentative de spéculation
Posté par Firwen (site web personnel) . En réponse au journal Bitcoin va très mal ?. Évalué à 2. Dernière modification le 19 janvier 2016 à 17:37.
Non. Tu parles juste sans savoir.
Et ça a déjà été expliqué sur DLFP il y a quelques temps au passage.
Le temps d'attente moyen "original" d'une génération de bloc est de 10 min, et tu n'attends pas non plus 10 min pour acheter une baquette.
Il n'y a nullement besoin d'attendre qu'une transaction soit inscrite dans la block-chain pour considérer qu'elle soit valide. La plupart des clients considère une transaction comme "valide" si elle a été propagé sur une majorité des nœuds du réseau sans refus.
Pour faire un parallèle avec le système bancaire :
La validation par un nombre de noeud "X", c'est comme le paiement par Carte Bancaire. Tu reçois l'argent, mais il y a toujours une possibilité de refus plus tard si la carte qui t'a payé a été volé.
L'inscription dans la block-chain, c'est le virement bancaire, avec confirmation écrite de la banque. C'est définitif et indélébile.
La plupart des solutions de paiement Bitcoin, Bitpay entre autres, n'attendent bien évidemment pas 10min pour confirmer que le paiement est effectif. Il considère la transaction comme valide après une propagation sur une profondeurs de 6-8 noeuds ( quelques secondes suffisent ).
[^] # Re: Belle tentative de spéculation
Posté par Firwen (site web personnel) . En réponse au journal Bitcoin va très mal ?. Évalué à 4. Dernière modification le 18 janvier 2016 à 11:16.
Et ça ne change rien.
Même avec 25%, 50%, 75% de réussir une modification ne signifie pas pouvoir tricher. Une transaction "malhonnète" sera tout de même refusée par le restant des noeuds "honnêtes", et la block-chain forkera, rendant la triche visible aux yeux de tous.
Ceci dit oui, je suis d'accord avec toi sur le fait que les grosses pools sont un problème. Mais là encore, rien de nouveau.
C'est un filtre de Bloom backé par un arbre de Merkel pour être parfaitement exacte. Et non l'élagage ne résout pas tout: il est toujours nécessaire de stocké clé + valeur de tous les acomptes ayant un seuil positif, ça prends de la place, et ce n'est pas compressible.
Sans parler que le concept d'élaguage et de check points a d'autre problèmes, comme la perte potentiel de l'historique du réseau, ou la perte des méta-data associées aux transactions ( commentaires, indexing par ID ). Ce n'est pas aussi simple que ça en a l'air.
C'est justement mon point.
Ce qui est fallacieux, c'est de présenter des faits qui sont là depuis longtemps comme "la fin de Bitcoin" juste pour créer le buzz et la spéculation qui va avec.
Mais là encore, rien de nouveau… Les mouvements de paniques ne se compte même plus dans l'histoire de Bitcoin…
Et comme je l'ai dit plus haut, si il y a une chose à mon humble opinion qui risque de tuer Bitcoin, c'est son instabilité permanente et son utilisation comme pure produit de spéculation, pas ses défauts techniques.
[^] # Re: Belle tentative de spéculation
Posté par Firwen (site web personnel) . En réponse au journal Bitcoin va très mal ?. Évalué à 6.
Ça je ne te le fais pas dire. Et c'est justement un point que l'auteur loupe complétement.
Le plus gros échec de Bitcoin à mon humble opinion n'est pas technique: c'est son incapacité d'avoir résister à la spéculation et son échec de s’être développé comme réel medium d'échange.
Bitcoin n'est maintenant que relayé et utilisé comme un produit spéculatif parmi d'autres.
[^] # Re: Belle tentative de spéculation
Posté par Firwen (site web personnel) . En réponse au journal Bitcoin va très mal ?. Évalué à 0.
Je ne pense pas être un expert de l'historique de Bitcoin, mais ce n'est à ma connaissance ni la première fois ni la dernière fois que ça arrive. De mémoire, ça c'était déja produit lors de l'introduction des ASIC avec la pool "asicminer". La pool s'était disloqué progressivement aprés l'annonce, comme celle là risque de le faire.
Ce qui serait inquiétant, c'est si une pool avait essayé d'effectivement généré de la faussé monnaie.
Ça doit faire maintenant plus d'un an que je ne suis plus le developpement de Bitcoin, et pourtant il y a un an il y avait déjà des discussions qui pullulaient sur le forum officiel sur la taille des blocks et l'interet de l'augmenter ou pas.
Certains y voyait une nécessité pour des transactions rapide, d'autre y voyait une barrière a ne pas franchir car ça augmenterait drastiquement la taille de la blockchain au point de rendre impossible son utilisation sur des configurations modeste. Rien de critique la dedans.
Bref, rien de nouveau sous le soleil.
Donc oui pour moi ça sent le FUD assez fortement.
# Belle tentative de spéculation
Posté par Firwen (site web personnel) . En réponse au journal Bitcoin va très mal ?. Évalué à -1. Dernière modification le 17 janvier 2016 à 21:56.
Certains des arguments qu'il avance sont fondés, comme la taille des blocs et les limitations que ça imposent en terme de transactions par seconde, mais la plupart est pure FUD sur des détails connus depuis longtemps comme les pools de Hong Kong.
Son action a surtout l'air d'une bonne grosse opération de spéculation. Le type revend tous ses bitcoins et prêche l'apocalypse, fait baisser massivement le cours et disparait juste après… Ou miraculeusement le cours remonte, juste après la tempête médiatique.
[^] # Re: Budget
Posté par Firwen (site web personnel) . En réponse au journal La fin de Firefox OS. Évalué à 10.
Et tu as parfaitement raison, je réagissais uniquement à la remarque de rewind sur "motivation vs salaire".
De manière générale, j'aurai tendance à dire que des différences de salaire de plus de 10x (20x max) entre le bas de l’échelle et le haut de l’échelle d'une société est déjà très discutable.
Mais dans le cadre d'une associations à but non lucratif qui fait des appels de dons, et à une telle échelle de salaire, c'est assez honteux oui.
[^] # Re: Budget
Posté par Firwen (site web personnel) . En réponse au journal La fin de Firefox OS. Évalué à 5. Dernière modification le 09 décembre 2015 à 11:42.
Oui, le petit étudiant sur-doué qui acceptera peut être de bosser pour des guenilles pendant deux ans.
Et après il fera comme les autres, il ira voir ailleurs où on doublera son salaire.
C'est pas pour rien que les salaires d'ingénieurs de Google, Intel, Facebook and co sont si élevés.