C'est ce dont je parlais dans un autre commentaire. Si tu prends la définition classique d'un "modèle", tu as un diagramme de classe, avec des "références" et des "liens de contenance" qui gère aussi le "lifetime". Dans un modèle objet classique, tous les objets sont créé dans les racines et se référencent entre eux. Dans un modèle, il y a une hiérarchie et une contenance d'objet explicite. Il y a de l'information pour beaucoup simplifier un GC.
Tu peux donc imaginer un système qui alloue toutes la mémoire très tôt, et qui n'alloue plus rien ensuite, en fonction de la taille des entrées.
Tu prends un hello world de chacun pour une application web http et tu utilises "ab".
J'avais fais un crash test, que je prenais pour la vitesse maximum absolu pour faire un server de web application.
Test sur mon portable sur un “hello wolrd” avec “ab -n 1000 -c 100”
- 1300 req/s en ocsigen
- 20 000 req/s avec go
- 15 000 req/s en pure apache
- 1900 re/s avec 2 ocsgen + haproxy
Et puis, un jour, ils vont se rendre compte que le taux de disponibilité de ce genre de chose est faible.
Un PC est moins fiable, mais faire tomber 10 000 PC en même temps est impossible, ce qui n'est pas le cas avec le client/server. J'ai encore les souvenirs de serveurs de fichiers SUN en rade, et la demi-journée perdu qui va avec, tous les 3 mois.
"Il n'existe aucune méthode 100% fiable scientifiquement pour garantir ces conditions."
Il existe un moyen, c'est la blockchain. Il doit être possible d'injecter les données comptables dans le système ethereum.org. Mais c'est en gros 80€/Mo d'écriture.
"C'est vrai. Mais c'est quelque chose d'assez dure à mesurer, les I/O font toujours parti des aspects les plus dure à benchmarker d'un programme car elles sont très sensibles au effets de bords ( cache du kernel, utilisation de la mémoire, block size, … ) "
C'est toujours pareil. Tu ne peux mesurer l'effet d'un seul chose, que toute chose étant égal par ailleurs. C'est vrai dans tout bench.
"La même chose concernant le taux de request par seconde sur un seul et même socket: le classique C10K problem."
C'est vieux :) Un "hello world" de 5 ligne en Go, te livre 20 000 req/s.
Mesurer l'I/O c'est principalement mesurer l'OS, ça a très peu d’intérêt pour un bench qui veut évaluer un langage.
Ce n'est pas si vrai que ça. C'est surtout un bench du sous système IO de la lib du langage. Et cela peut être très mal fait.
Il suffit de voir la variété énorme d'appel système sous Linux, qui selon le cas d'usage ne sont pas les plus performant (mmap qui bouffe la mémoire, et ne peut agrandir un fichier; le read/write qui bufferise et donc ajoute une copie, mais permet de diminuer drastiquement la latence dû au noyau; splice() qui permet de partager un buffer noyau interne; la gestion d'un thread par disque augmente aussi les performances; les ios asynchrones masquent les latences mais peuvent être un cauchemar à utiliser)
Disons que cela pourrait être un bon benchmark en soi. Devoir lire une grande quantité de fichier (10 000 ?) de taille moyenne (1 Mo ?) dans une arborescence, et d'écrire autant de fichiers (avec un checksum bidon dedans par exemple).
C'est une charge hautement parallélisable, mais qui est complètement "IO bound".
SCADE est un outil top pour n'importe quel code embarqué. Peu de bug, facile à modifier. Et le code généré est rapide (code C "propre").
Mais comme le compilateur est certifié comme peut l'être un code aéronautique, il coute une blinde. Les clients ont du mal à justifier son cout par rapport à un GCC gratuit. Mais on a une boite brésilienne qui a préféré acheter du SCADE, car il ne trouvait de codeur en techno classique pour faire des petits drones. Et en équipe réduite, il refait son code beaucoup plus rapidement.
Dans l'automobile, c'est sans doute le cas. Dans l'aéronautique, les contrôleurs ont fait jeter des codes complets pour mauvaises traçabilités (par exemple, le 1er fadec de l'A400M, de mémoire).
"Je ne connaissais pas le principe, l'idée est intéressante ça mérite réflexion. L'idée est de déterminer « statiquement » les besoins en mémoire, non à la compilation, mais le plus tôt possible à l'exécution et ne plus faire d'allocations par la suite ?"
Oui, c'est l'idée. Cela peut s'appliquer souvent. Je crois que haproxy fonctionne ainsi. Tu as un modèle de mémoire qui ne se croit pas infini. Il faut donc en demander au début une certaine quantité, et ne plus en bouger. En plus, cela évite les problèmes de fragmentation.
"Ce que tu décris sur la gestion des objets, n'est-ce pas justement le principe du RAII ?"
Cela y ressemble un peu. Mais tu peux imaginer des cas supplémentaires qui détruisent une arborescence d'objet en dehors du RAII. Et il faut gérer en plus les pointeurs qui ciblent un objet détruit.
Dans le domaine, dans l'embarqué, c'est quand même du C ou du C++, et la bite et le couteau avec des tests unitaire à taux de couverture MCDC. SCADE est vu souvent comme un canon pour écraser une mouche(sauf DO178 niveau A, évidement).
Ariane 5, c'est surtout un handler d'exception sur dépassement de capacité d'une variable qui ne servait à rien, qui lance un code d'autotest, le problème. J'imagine que c'est pour cela qu'il y a une chasse au code "mort" depuis.
L'outil génère un "metafichier" par fichier dans le répertoire ./list/ ce fichier contient la taille et un path vers le fichier réel. Si un fichier meta n'est pas dans ./list/ le binaire va tenter de le replacer par son fichier d'origine et va ajouter son path dans le fichier meta de ./list/.
Il faut voir. Les listes sont ridicules dans 99% des cas. Il y a 1 ou 2 éléments. Pour des tailles inférieurs à 100, c'est très rares d'avoir un container qui bas une liste. Les surcouts statiques sont souvent très couteux (la constante derrière, le O(1))
Il existe un paradigme que je n'ai quasiment jamais vu utiliser. SCADE s'interdit toute allocation et utilise de gros buffer statique, et cela marche très bien pour 99% du code embarqué.
Le problème d'absence d'allocation se pose si la taille des entrées n'est pas connu. C'est le cas dans la norme ARINC 661 qui est un serveur graphique dont les widgets sont connu à l'init déclaré dans un fichier de définition.
Je pense que l'allocation à l'init permet de gérer pas mal de cas, ou au moins, à un temps précis, ce qui permet de gérer l'erreur le plus tôt possible. Un système à gestion automatique de mémoire, pourrait calculer les besoins mémoire au démarrage (selon la taille d'un fichier par exemple) et ensuite ne plus faire d'allocation du tout.
Une autre vois serait de mieux gérer l'appartenance des objets. Dans un système classique, un objet est créé en vrac et on fait des références dessus. Dans l'ingénierie des modèles, si on définit un diagramme de classe, on a clairement une notion d'appartenance à un arbre, et "des" références. Mais cela veut clairement dire que la destruction de la racine de l'arbre entraine toutes les feuilles. Je ne connais pas non plus de gestion de mémoire automatique qui utilise cette propriété.
"Les domaines pour lesquels un GC est inenvisageable à l'heure actuelle ne risque pas de diminuer parce que, pour la plupart, ce sont des domaines où les performances et/ou la latence sont primordiales et donc, on en revient à ce qu'on disait au début."
Typiquement tout ce qui est "safety critical" ne supporte pas l'allocation mémoire, alors un GC… (le SC, c'est pour les avions, les trains, l'industriel, le ferroviaire, la voiture…)
Et ce genre de code a tendance à vouloir enfler à très grande vitesse. Il y a une énorme différence entre la taille de code embarqué d'il y a 10 ans, et le code de maintenant.
C'est gentil, j'aurais été curieux de voir le résultat. Le logiciel est en version stable, mais n'a pas d'utilisateur :) Le code est plutôt très rapide (optimisation des appels noyaux), il scanne en profondeur les répertoires de façon très efficace.
J'ai voulu faire un système d'échange simple de la main à la main avec un système de fichier qui en représente de plus gros. L'interface a une seul action, mais peu de monde comprend le fonctionnement (cf la doc). J'avais posté ici, sans grand succès.
Si un jour, je suis motivé, je couperais le programme en 2, avec un binaire pour générer les petits fichiers, et un binaire pour lancer la copie. Cela pourra être utile si on veut réorganiser une arborescence complète, sans attendre la fin de chaque copie (on fait l'arborescence à la main avec les petits fichiers, puis une seul commande les remplacerait avec les vrais).
Si je me rappelles bien, j'ai un répertoire demo avec un script qui lance le binaire.
GNU avait une licence spécifique de documentation, qui empêche la modification de morceau de document, l'idée est que l'on doit pouvoir faire modifier la documentation elle-même, mais pas l'explication sur les motivation de la FSF.
Les licences CC qui arrivent ensuite, démontre que ce genre de précaution n'est pas forcément nécessaire. Très peu de licence CC sont réellement libres, c'est moins gênant pour l'utilisateur que pour un logiciel. C'est sans doute pour cela que c'est moins répandu que le logiciel libre.
L'idée est de dire qu'un logiciel est un outil qui n'est jamais fini par définition. Une œuvre d'art est terminé, même si elle pourrait servir pour en créer d'autre.
Cela voudrait dire que l'option "BY" permet de retrouver l'auteur original, mais les créateurs de la GPL ont toujours vu cette clause comment étant très difficile à mettre en œuvre en pratique.
(raison pour laquelle le logiciel libre qu'est un Firefox modifié ne s'appellait pas Firefox dans Debian)
C'est surtout parce que "Firefox" est une marque déposée.
Disons qu'un système comme celui de Nice mais en open data, cela permet à google map, waze et autre GPS d'inclure l'information dans leur système. Avoir encore une application pour ça, c'est très peu efficace.
Cela me rappelle un pattern tout con, que je n'arrivais pas à faire en ocaml. Je lisais une grande série de petit fichiers. En C, le réflexe est d'utiliser et réutiliser toujours le même buffer de taille "suffisante". Or c'est impossible en Ocaml car les string ne sont pas mutable. Les buffers le sont, mais il n'existe pas vraiment de fonction de parsing utilisant des buffers, à la place des string. Donc, il fallait paramétrer le gc pour ne pas qu'il se lance, résultat : 30% de perf en plus, mais explosion de l'usage de la mémoire.
Souvent les mainteneurs de logiciel disposent de leur propre boite. Et tu peux faire un don sous forme de maintenance. L'état Allemand paye le mainteneur de gpg de cette façon, il me semble.
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
C'est ce dont je parlais dans un autre commentaire. Si tu prends la définition classique d'un "modèle", tu as un diagramme de classe, avec des "références" et des "liens de contenance" qui gère aussi le "lifetime". Dans un modèle objet classique, tous les objets sont créé dans les racines et se référencent entre eux. Dans un modèle, il y a une hiérarchie et une contenance d'objet explicite. Il y a de l'information pour beaucoup simplifier un GC.
Tu peux donc imaginer un système qui alloue toutes la mémoire très tôt, et qui n'alloue plus rien ensuite, en fonction de la taille des entrées.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Tu prends un hello world de chacun pour une application web http et tu utilises "ab".
J'avais fais un crash test, que je prenais pour la vitesse maximum absolu pour faire un server de web application.
Test sur mon portable sur un “hello wolrd” avec “ab -n 1000 -c 100”
- 1300 req/s en ocsigen
- 20 000 req/s avec go
- 15 000 req/s en pure apache
- 1900 re/s avec 2 ocsgen + haproxy
"La première sécurité est la liberté"
# dispo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à -2.
Et puis, un jour, ils vont se rendre compte que le taux de disponibilité de ce genre de chose est faible.
Un PC est moins fiable, mais faire tomber 10 000 PC en même temps est impossible, ce qui n'est pas le cas avec le client/server. J'ai encore les souvenirs de serveurs de fichiers SUN en rade, et la demi-journée perdu qui va avec, tous les 3 mois.
"La première sécurité est la liberté"
# blockchain
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Point d'étape sur loi française de finances 2016 (article 88) et les logiciels libres de caisse. Évalué à 0.
Il existe un moyen, c'est la blockchain. Il doit être possible d'injecter les données comptables dans le système ethereum.org. Mais c'est en gros 80€/Mo d'écriture.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
C'est toujours pareil. Tu ne peux mesurer l'effet d'un seul chose, que toute chose étant égal par ailleurs. C'est vrai dans tout bench.
C'est vieux :) Un "hello world" de 5 ligne en Go, te livre 20 000 req/s.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Ce n'est pas si vrai que ça. C'est surtout un bench du sous système IO de la lib du langage. Et cela peut être très mal fait.
Il suffit de voir la variété énorme d'appel système sous Linux, qui selon le cas d'usage ne sont pas les plus performant (mmap qui bouffe la mémoire, et ne peut agrandir un fichier; le read/write qui bufferise et donc ajoute une copie, mais permet de diminuer drastiquement la latence dû au noyau; splice() qui permet de partager un buffer noyau interne; la gestion d'un thread par disque augmente aussi les performances; les ios asynchrones masquent les latences mais peuvent être un cauchemar à utiliser)
Disons que cela pourrait être un bon benchmark en soi. Devoir lire une grande quantité de fichier (10 000 ?) de taille moyenne (1 Mo ?) dans une arborescence, et d'écrire autant de fichiers (avec un checksum bidon dedans par exemple).
C'est une charge hautement parallélisable, mais qui est complètement "IO bound".
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
SCADE est un outil top pour n'importe quel code embarqué. Peu de bug, facile à modifier. Et le code généré est rapide (code C "propre").
Mais comme le compilateur est certifié comme peut l'être un code aéronautique, il coute une blinde. Les clients ont du mal à justifier son cout par rapport à un GCC gratuit. Mais on a une boite brésilienne qui a préféré acheter du SCADE, car il ne trouvait de codeur en techno classique pour faire des petits drones. Et en équipe réduite, il refait son code beaucoup plus rapidement.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
On peut aussi parler de Rust, le langage de Mozilla, qui offre le choix concernant la gestion de mémoire (GC ou pas GC, utilisation de pile, etc…).
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Dans l'automobile, c'est sans doute le cas. Dans l'aéronautique, les contrôleurs ont fait jeter des codes complets pour mauvaises traçabilités (par exemple, le 1er fadec de l'A400M, de mémoire).
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Oui, c'est l'idée. Cela peut s'appliquer souvent. Je crois que haproxy fonctionne ainsi. Tu as un modèle de mémoire qui ne se croit pas infini. Il faut donc en demander au début une certaine quantité, et ne plus en bouger. En plus, cela évite les problèmes de fragmentation.
Cela y ressemble un peu. Mais tu peux imaginer des cas supplémentaires qui détruisent une arborescence d'objet en dehors du RAII. Et il faut gérer en plus les pointeurs qui ciblent un objet détruit.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Dans le domaine, dans l'embarqué, c'est quand même du C ou du C++, et la bite et le couteau avec des tests unitaire à taux de couverture MCDC. SCADE est vu souvent comme un canon pour écraser une mouche(sauf DO178 niveau A, évidement).
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
Ariane 5, c'est surtout un handler d'exception sur dépassement de capacité d'une variable qui ne servait à rien, qui lance un code d'autotest, le problème. J'imagine que c'est pour cela qu'il y a une chasse au code "mort" depuis.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
L'outil génère un "metafichier" par fichier dans le répertoire ./list/ ce fichier contient la taille et un path vers le fichier réel. Si un fichier meta n'est pas dans ./list/ le binaire va tenter de le replacer par son fichier d'origine et va ajouter son path dans le fichier meta de ./list/.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Il faut voir. Les listes sont ridicules dans 99% des cas. Il y a 1 ou 2 éléments. Pour des tailles inférieurs à 100, c'est très rares d'avoir un container qui bas une liste. Les surcouts statiques sont souvent très couteux (la constante derrière, le O(1))
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 5.
Je ne suis pas sûr.
Il existe un paradigme que je n'ai quasiment jamais vu utiliser. SCADE s'interdit toute allocation et utilise de gros buffer statique, et cela marche très bien pour 99% du code embarqué.
Le problème d'absence d'allocation se pose si la taille des entrées n'est pas connu. C'est le cas dans la norme ARINC 661 qui est un serveur graphique dont les widgets sont connu à l'init déclaré dans un fichier de définition.
Je pense que l'allocation à l'init permet de gérer pas mal de cas, ou au moins, à un temps précis, ce qui permet de gérer l'erreur le plus tôt possible. Un système à gestion automatique de mémoire, pourrait calculer les besoins mémoire au démarrage (selon la taille d'un fichier par exemple) et ensuite ne plus faire d'allocation du tout.
Une autre vois serait de mieux gérer l'appartenance des objets. Dans un système classique, un objet est créé en vrac et on fait des références dessus. Dans l'ingénierie des modèles, si on définit un diagramme de classe, on a clairement une notion d'appartenance à un arbre, et "des" références. Mais cela veut clairement dire que la destruction de la racine de l'arbre entraine toutes les feuilles. Je ne connais pas non plus de gestion de mémoire automatique qui utilise cette propriété.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 6.
Typiquement tout ce qui est "safety critical" ne supporte pas l'allocation mémoire, alors un GC… (le SC, c'est pour les avions, les trains, l'industriel, le ferroviaire, la voiture…)
Et ce genre de code a tendance à vouloir enfler à très grande vitesse. Il y a une énorme différence entre la taille de code embarqué d'il y a 10 ans, et le code de maintenant.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
C'est gentil, j'aurais été curieux de voir le résultat. Le logiciel est en version stable, mais n'a pas d'utilisateur :) Le code est plutôt très rapide (optimisation des appels noyaux), il scanne en profondeur les répertoires de façon très efficace.
J'ai voulu faire un système d'échange simple de la main à la main avec un système de fichier qui en représente de plus gros. L'interface a une seul action, mais peu de monde comprend le fonctionnement (cf la doc). J'avais posté ici, sans grand succès.
Si un jour, je suis motivé, je couperais le programme en 2, avec un binaire pour générer les petits fichiers, et un binaire pour lancer la copie. Cela pourra être utile si on veut réorganiser une arborescence complète, sans attendre la fin de chaque copie (on fait l'arborescence à la main avec les petits fichiers, puis une seul commande les remplacerait avec les vrais).
Si je me rappelles bien, j'ai un répertoire demo avec un script qui lance le binaire.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Je ne retrouve plus le problème précisément. Le code est là :
https://github.com/nicolasboulay/index2share/blob/master/src/meta.ml
La fonction read peut être appelé des dizaines de milliers de fois. Je lis le fichier et je le convertis dans une petite structure de donné.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Je vais retrouver le pattern, si tu veux. C'est un code un peu ancien.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Le problème est là, tu alloues plein de mémoire à ce moment-là. Ce ne sont pas des "slices".
"La première sécurité est la liberté"
[^] # Re: Pas d’accord, mais on s’en fout un peu
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi l'art libre est aussi important que le logiciel libre. Évalué à 3.
GNU avait une licence spécifique de documentation, qui empêche la modification de morceau de document, l'idée est que l'on doit pouvoir faire modifier la documentation elle-même, mais pas l'explication sur les motivation de la FSF.
Les licences CC qui arrivent ensuite, démontre que ce genre de précaution n'est pas forcément nécessaire. Très peu de licence CC sont réellement libres, c'est moins gênant pour l'utilisateur que pour un logiciel. C'est sans doute pour cela que c'est moins répandu que le logiciel libre.
L'idée est de dire qu'un logiciel est un outil qui n'est jamais fini par définition. Une œuvre d'art est terminé, même si elle pourrait servir pour en créer d'autre.
Cela voudrait dire que l'option "BY" permet de retrouver l'auteur original, mais les créateurs de la GPL ont toujours vu cette clause comment étant très difficile à mettre en œuvre en pratique.
C'est surtout parce que "Firefox" est une marque déposée.
"La première sécurité est la liberté"
[^] # Re: "Alors, la smart city est-elle vouée à l'échec ?"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Les chroniques du progrès : à bégayer ou à dégager ?. Évalué à 3.
Disons qu'un système comme celui de Nice mais en open data, cela permet à google map, waze et autre GPS d'inclure l'information dans leur système. Avoir encore une application pour ça, c'est très peu efficace.
"La première sécurité est la liberté"
[^] # Re: Destructeurs
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 7.
Cela me rappelle un pattern tout con, que je n'arrivais pas à faire en ocaml. Je lisais une grande série de petit fichiers. En C, le réflexe est d'utiliser et réutiliser toujours le même buffer de taille "suffisante". Or c'est impossible en Ocaml car les string ne sont pas mutable. Les buffers le sont, mais il n'existe pas vraiment de fonction de parsing utilisant des buffers, à la place des string. Donc, il fallait paramétrer le gc pour ne pas qu'il se lance, résultat : 30% de perf en plus, mais explosion de l'usage de la mémoire.
"La première sécurité est la liberté"
[^] # Re: Classement différent : limiter la taille du code, pour limiter le temps à y consacrer
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Smash The Code, concours d'intelligence artificielle, démarre le 30 avril 2016. Évalué à 3.
Bon, le gars a du pipoter.
N’empêche que cela ne change rien à la proposition de faire des catégories de logiciel par leur taille.
Le plus simple est de jouer sur le même plan que le benchmark suivant : https://benchmarksgame.alioth.debian.org/how-programs-are-measured.html un gzip du code sans les commentaires.
"La première sécurité est la liberté"
[^] # Re: en entreprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Libre ne veut pas dire gratuit : une présentation. Évalué à 4.
Souvent les mainteneurs de logiciel disposent de leur propre boite. Et tu peux faire un don sous forme de maintenance. L'état Allemand paye le mainteneur de gpg de cette façon, il me semble.
"La première sécurité est la liberté"