"Tout cela est diffile a réaliser avec des script qui font du hashage brutal de tous les fichiers d'un répertoire."
J'aurais tenté avec une lecture de l'arborescence complète, puis comparaison byte à byte en cas de collision nom/taille. Faudrait que je tente le coup avec des morceaux d'un ancien code.
En fait, il faudrait un répertoire de référence, et des copies, si un fichier est corrompu dans le répertoire de référence, on le remplace par une copie (même nom, même taille, voir même path relatif).
Je parlais de performance à haut niveau. Souvent, les personnes veulent du C++ pour aller vite, alors que c'est leur architecture de message pourri réseau (round trip) qui pose problème, ou des appels systèmes trop nombreux, ou un nombre de refresh pas du tout maitrisé, etc…
C'est toujours le même problème : avec un code de "hack", on peut aller 10x plus vite, avec le bon algo 1000x.
Je répondais surtout à une personne qui voulait faire du "beau code", et un logiciel rapide sera toujours plus apprécié qu'un logiciel lent.
Non la complexité cyclomatique simplifie trop le problème. Elle compte juste le nombre de branche dans une fonction, or le contenu de chaque test peut être indépendant. La différence, c'est entre n tests et 2n.
Elle ne permet pas non plus de calculer les dépendances entre fonction (couverture d'instance). Typiquement une fonction qui en appel une autre. C'est le nombre total de chemin de l'executable qui compte pas vraiment, la somme des chemins de l'ensemble de chaque fonction sans tenir compte des appels.
Ensuite, c'est surtout les "états" différents qui importent, plus encore que les chemins pour y arriver (même si c'est lié). Dans une machine d'état, c'est le nombre d'état qui compte, plus que la complexité des conditions de transition.
Est-ce qu'il y a une détection des fichiers en erreur ?
Mon cas d'usage est celui de copies multiples de répertoire contenant mes archives photos (sauvegardes sur différent support faites au cours du temps). Parfois des images sont corrompues. Comment faire pour "remerger" toutes ces copies en un seul répertoire propre de référence.
J'ai compris qu'un beau code n'est pas un code ultra générique, mais un code qui se lit comme une histoire. J'ai compris ça en lisant du code de hocwp, je ne sais pas si il est encore sur le site. C'était juste limpide. Un code comme ça, peut vivre longtemps.
En informatique, ce n'est pas le code l'important, mais la fonction a réaliser, la maintenabilité, l'absence de bug, la vitesse d’exécution.
J'ai vu une fois du beau code bien générique d'un code "professionnel". Il s'agissait de faire des filtres numériques (type O = I(n)a + I(n-1)*b +I(n+2)*c…), c'était généralisé avec une gestion de liste et des fonctions utilitaire. Or la plus part des filtres était d'ordre 2, ce qui aurait du faire des équations du genre "return ab+c*d;"…
Pour arriver un peu à la même chose, je raisonne en cas de testes. Dans un monde rêvé, où tous les cas seraient testés, combien de tests cela fait ? Cela détermine le nombre d'état possible du code, et autant de problèmes potentiels, surtout après modification (non régression plus complexe).
Cela permet de se rendre compte de la qualité d'un code "stateless", ce qui évite une grande quantité de teste finalement inutile. Cela permet de séparer très clairement les données du logiciel, des données temporaires inutiles. Cela permet d'identifier des "états stables" qui permet d'y retourner en cas de plantage ou d'exception non prévu, voir d'avoir un "reset()" propre, qui évite de recréer toujours le même objet. Cela permet de limiter les données du logiciel aux stricts nécessaire aux traitements, ce qui évite de trainer toutes les entrées et ne plus savoir ce qui est valide ou non, modifier ou non, etc… Pour faire cela, cela impose de gérer les erreurs avant le traitement, cela simplifie le traitement qui considère les entrées juste, et cela permet de faire de très joli message d'erreur, car on est très proche de l'entrée de pipeline de traitement (on dispose de tous les fichiers et leur numéro de ligne).
Surtout que la plus part du temps, c'est plus simple de réécrire le code que de jongler avec la "souplesse" de l'architecture complexe, qui de toute façon ne serait jamais assez souple pour les besoins futurs.
Tu opposes un remote desktop dans le cloud et un PC. Si internet tombe, 99% de tes taches peuvent continuer sur PC. Et je vais t'apprendre un truc dingue, la sauvegarde existe aussi pour certain document sur PC. Le mail est coincé, mais tu peux toujours trouver une connexion 3G ou freewifi, au cas ou.
Je ne sais pas d'ou tu sors, mais la plus part des tâches ne nécessite pas forcément internet.
Ton archi est tout à fait comparable à la machine à papi Sun et tu ne t'en rend même pas compte. La seul chose que tu proposes est la duplication de serveur.
Mais tu oublis tout les autres spof : comme la liaison internet, la configuration réseau, les éléments type firewall ou switch managé,… Il y un tas de raisons que le truc tombe en panne. Beaucoup plus que pour un simple PC.
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.
[^] # Re: Et les Panama Papers, alors ?!?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 6.
Ils sont loin d'être condamné.
"La première sécurité est la liberté"
[^] # Re: Gérer les fichiers
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 2.
J'aurais tenté avec une lecture de l'arborescence complète, puis comparaison byte à byte en cas de collision nom/taille. Faudrait que je tente le coup avec des morceaux d'un ancien code.
"La première sécurité est la liberté"
[^] # Re: fichier en erreur ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 2.
En fait, il faudrait un répertoire de référence, et des copies, si un fichier est corrompu dans le répertoire de référence, on le remplace par une copie (même nom, même taille, voir même path relatif).
"La première sécurité est la liberté"
[^] # Re: Un chouia simpliste ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
Je parlais de performance à haut niveau. Souvent, les personnes veulent du C++ pour aller vite, alors que c'est leur architecture de message pourri réseau (round trip) qui pose problème, ou des appels systèmes trop nombreux, ou un nombre de refresh pas du tout maitrisé, etc…
C'est toujours le même problème : avec un code de "hack", on peut aller 10x plus vite, avec le bon algo 1000x.
Je répondais surtout à une personne qui voulait faire du "beau code", et un logiciel rapide sera toujours plus apprécié qu'un logiciel lent.
"La première sécurité est la liberté"
[^] # Re: chi va piano va sano
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 2.
Non la complexité cyclomatique simplifie trop le problème. Elle compte juste le nombre de branche dans une fonction, or le contenu de chaque test peut être indépendant. La différence, c'est entre n tests et 2n.
Elle ne permet pas non plus de calculer les dépendances entre fonction (couverture d'instance). Typiquement une fonction qui en appel une autre. C'est le nombre total de chemin de l'executable qui compte pas vraiment, la somme des chemins de l'ensemble de chaque fonction sans tenir compte des appels.
Ensuite, c'est surtout les "états" différents qui importent, plus encore que les chemins pour y arriver (même si c'est lié). Dans une machine d'état, c'est le nombre d'état qui compte, plus que la complexité des conditions de transition.
"La première sécurité est la liberté"
# fichier en erreur ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Focus sur les performances avec Fim 1.2.0. Évalué à 8.
Est-ce qu'il y a une détection des fichiers en erreur ?
Mon cas d'usage est celui de copies multiples de répertoire contenant mes archives photos (sauvegardes sur différent support faites au cours du temps). Parfois des images sont corrompues. Comment faire pour "remerger" toutes ces copies en un seul répertoire propre de référence.
"La première sécurité est la liberté"
[^] # Re: Moi aussi !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 2.
Oui, mais à la fin, tu dois avoir moins de code, et ne pas le garder juste parce que tu t'es fait chier à l'écrire.
"La première sécurité est la liberté"
[^] # Re: Un chouia simpliste ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 4.
J'ai compris qu'un beau code n'est pas un code ultra générique, mais un code qui se lit comme une histoire. J'ai compris ça en lisant du code de hocwp, je ne sais pas si il est encore sur le site. C'était juste limpide. Un code comme ça, peut vivre longtemps.
En informatique, ce n'est pas le code l'important, mais la fonction a réaliser, la maintenabilité, l'absence de bug, la vitesse d’exécution.
J'ai vu une fois du beau code bien générique d'un code "professionnel". Il s'agissait de faire des filtres numériques (type O = I(n)a + I(n-1)*b +I(n+2)*c…), c'était généralisé avec une gestion de liste et des fonctions utilitaire. Or la plus part des filtres était d'ordre 2, ce qui aurait du faire des équations du genre "return ab+c*d;"…
"La première sécurité est la liberté"
[^] # Re: chi va piano va sano
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
Pour arriver un peu à la même chose, je raisonne en cas de testes. Dans un monde rêvé, où tous les cas seraient testés, combien de tests cela fait ? Cela détermine le nombre d'état possible du code, et autant de problèmes potentiels, surtout après modification (non régression plus complexe).
Cela permet de se rendre compte de la qualité d'un code "stateless", ce qui évite une grande quantité de teste finalement inutile. Cela permet de séparer très clairement les données du logiciel, des données temporaires inutiles. Cela permet d'identifier des "états stables" qui permet d'y retourner en cas de plantage ou d'exception non prévu, voir d'avoir un "reset()" propre, qui évite de recréer toujours le même objet. Cela permet de limiter les données du logiciel aux stricts nécessaire aux traitements, ce qui évite de trainer toutes les entrées et ne plus savoir ce qui est valide ou non, modifier ou non, etc… Pour faire cela, cela impose de gérer les erreurs avant le traitement, cela simplifie le traitement qui considère les entrées juste, et cela permet de faire de très joli message d'erreur, car on est très proche de l'entrée de pipeline de traitement (on dispose de tous les fichiers et leur numéro de ligne).
"La première sécurité est la liberté"
[^] # Re: Moi aussi !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 4.
Quand tu commences à écrire du code en plus, au lieu d'en effacer, tu va dans le mauvais sens. C'est un peu le principe de la factorisation.
"La première sécurité est la liberté"
[^] # Re: Un chouia simpliste ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 7.
Surtout que la plus part du temps, c'est plus simple de réécrire le code que de jongler avec la "souplesse" de l'architecture complexe, qui de toute façon ne serait jamais assez souple pour les besoins futurs.
"La première sécurité est la liberté"
[^] # Re: 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é à 2.
La loi a changé, si un vendeur de machine est pris, il est solidaire des fraudes faites avec… Je ne suis pas sûr que cela en vaut la peine.
"La première sécurité est la liberté"
[^] # Re: C'est merveilleux l'informatique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 3.
En France.
Au USA, on rémunère mieux les "makers" que les "sellers". Sinon, ils n'existeraient pas de salaires à 100k$ pour les ingénieurs.
"La première sécurité est la liberté"
[^] # Re: dispo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 5.
Tu lis un peu ce à quoi tu réponds ?
Tu opposes un remote desktop dans le cloud et un PC. Si internet tombe, 99% de tes taches peuvent continuer sur PC. Et je vais t'apprendre un truc dingue, la sauvegarde existe aussi pour certain document sur PC. Le mail est coincé, mais tu peux toujours trouver une connexion 3G ou freewifi, au cas ou.
Je ne sais pas d'ou tu sors, mais la plus part des tâches ne nécessite pas forcément internet.
"La première sécurité est la liberté"
[^] # Re: dispo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 1.
Ton archi est tout à fait comparable à la machine à papi Sun et tu ne t'en rend même pas compte. La seul chose que tu proposes est la duplication de serveur.
Mais tu oublis tout les autres spof : comme la liaison internet, la configuration réseau, les éléments type firewall ou switch managé,… Il y un tas de raisons que le truc tombe en panne. Beaucoup plus que pour un simple PC.
"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 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é"