Les 4 points sont présent, si tu regarde bien, mais sans doute pas, comme tu le souhaiterais. Et si je n'ai pas mis de capture d'écran, j'ai mis des "consoles shot" dans le même but. Mais il manque les "$ ls" pour comprendre.
Tu as des remarques concernant la sortie du logiciel ou autres choses ? Je ferais une beta 2, avec toutes les remarques des commentaires.
Tu peux décrire ce qui te trouble plus précisément ?
L'idée est d'avoir un minimum "d'état". si il remplaçait le contenu de la liste, ou est-ce que je pourrais mettre les .idx ? Il faut aussi faire en sorte que lancer 2 fois de suite l'outil, ne change rien à l'état du système. si cela n'est pas stable, c'est compliqué de comprendre ce qui peux se passer.
./list est là où sont stocker les idx, qui est maintenu à jour.
"Ça n'empêche qu'il pourrait m'indiquer la taille correspondant à tous les ".idx" même si il trouve les fichiers sources."
Oui, l'un n’empêche pas l'autre.
L'outil ne regarde pas le contenu de ./list/. C'est plus simple si tu réfléchis avec des supports amovibles.
Bob a donné des fichiers .idx à Alice qui les copient dans le ./list/ de son disque usb. Celle-ci a ensuite transférer les .idx qui l'intéresse, de ./list/ à la racine (n'importe où ailleurs que ./list/). Ensuite, elle passe son disque à bob. Bob lance index à la racine du disque mobile, les fichiers .idx en dehors de ./list sont remplacé par les fichiers d'origines.
"générer l'arborescence idx, calculer la taille cible, réaliser la copie. Dans mon cas, il ne fait que le premier et toujours le premier."
Il détecte les .idx en dehors de ./list/, et tente de les remplacer par les fichiers d'origine.
Si il ne trouve les fichiers, ils additionnent leur taille. Si il les trouve, il les copie.
C'est le problème des moyennes : cela ne veut rien dire. Un OS n'a pas de code flottant, mais un os tout seul ne sert à rien. J'imagine qu'un jeu doit utiliser majoritaire des flottants 32 bits vectorisé, un code scientifique des nombre flottants 64 bits, un IDE ou un compilateur, un serveur web, une base de donné n'utilise que des entiers.
Le problème est que la taille est calculée uniquement pour les fichiers qu'il ne trouve pas. Pour ne pas avoir les copies qui se lancent, il faut renommer, par exemple, le répertoire de base pour qu'il ne puisse pas trouver les fichiers d'origine. Le cas "normal" est de faire un trie, quand les fichiers ne sont pas présent.
Je pourrais mettre une option pour désactivé la copie, et calculer uniquement la taille.
"Comment l'outil sait si il faut génerer une copie, calculer la taille ou copier les fichiers, ça reste à définir mais c'est du détail."
C'est simple, il le fait à chaque fois dans l'ordre : mettre à jour la liste, détecter les fichiers d'index en dehors de la liste, essayer de faire une copie, donner la taille des fichiers qu'il n'arrive pas à copier.
Ce qui me fait très peur, c'est que cette démarche est expliquer en détail dans le journal, et encore une fois dans le readme.txt. Et cela n'a pas l'air d'être évident du tout.
"Reste une chose, lui trouver un nom."
Si cela gène tellement, je peux utiliser indexFile c'est le mot magique dans les fichiers d'index.
"Et puis merci pour ce genre de remarque constructive, c'est toujours agréable."
C'est toi qui a commencé sur ce ton, pourquoi tu t'étonnes que je continue ? (tu parlais de roue, je parle de porte)
1/ tu n'es pas la cible, ce n'est pas parce qu'un logiciel est expliqué sur linuxfr qu'il n'est utile qu'au gourou
2/ J'aimerais voir Alice avec un tableur quand il s'agit de gérer plein de série, au lieu de prendre un répertoire. Et puis, je ne comprends pas cette manie d'utiliser un tableur pour faire tout et n'importe quoi, comme de la gestion de base de donné.
3/ Mes 19 paragraphes étaient pour expliquer le processus de développement du logiciel et pas seulement le logiciel lui-même. Tu fais juste de la mauvaise fois.
"Fais mieux."
Pourquoi faire ?
Créer la liste :
$ ./index
Pour faire les copies ?
$ ./index
Pour vérifier la taille de la futur copie ?
$ ./index
Pour se faire son choix de fichier ?
$ cp …. # ou un navigateur de fichier
Disons que le principe du thread de cpu reste le même, on partage un cpu avec un peu plus de ressources. D'ailleurs, je pense que commercialement AMD en aurait plus vendu, si l'image d'un seul core n'était pas aussi faible.
Il ne faut pas oublier que l'on parle de doublement à prix constant. Un power7 a un die énorme, même par rapport à un core i7. Je ne pense pas que le 4004 coutait plusieurs milliers d'euro pièce.
Pas la peine d'essayer de me prouver que l'on peut faire les choses autrement, c'est enfoncer une porte ouverte.
Mais une ligne de commande comme :
find /path/to/my/collection -type f -name "*.avi" -or -name "*.mp?" -printf "%p\t%k\n" > /tmp/collection.csv
Ne fait pas parti de ce que j'appelle une interface simple.
"J'ai l'impression que c'est un peu le cas nominal "
Non, ce n'est pas le cas nominal. En général, tu as un paquet de cas ou tu ne te pointes pas chez les gens pour faire une copie. Ensuite, selon la taille des fichiers, on peut lancer tout en parallèle, et cela rallonge le temps global de copie, ou attendre entre chaque copie, ce qui est casse-pied.
Le phread était à propos d'avoir des chiffres de ralentissement par rapport à l’agressivité de l'inlining, et non des généralités sur l'inline.
"One of the benefits of inlining, aside from eliminating the call/return, is that it opens new optimization opportunities by optimizing across the caller/callee boundary. In effect, it allows the called function to be specialized for the context from which it was called. For instance, one of the operands to a function might be a flag that enables/disables some feature controlled by the function. If that flag is a constant in the call, entire codepaths from the callee might become dead code. " commentaire sur lwm de 2004 (il y a presque 10 ans, une éternité pour l'informatique).
Ce n'est pas parce que tu pointes des papiers qui parlent d'inline, que cela un rapport avec le thread.
"évite de nous parler d'obscurs projets que toi seul connais,"
Pourtant, on en a parlé souvent sur linuxfr (si tu parles de Lisaac, parce que si tu ne connais pas Texas Instrument, personne ne peux rien pour toi)! Tu dois être trop jeune sans doute.
"ou encore de papiers qui n'ont rien à voir avec le schmilblic"
Tu n'as pas du le lire, il y est question d'inline, même si cela n'est pas son sujet unique.
"culture confiture comme on dit."
On doit toujours être le vieux con de quelqu'un, j'imagine. Et toi, qu'est-ce que tu as fait de tellement exceptionnel pour te permettre de juger les gens ?
"En conclusion, la réduction de la taille du code n'est pas pertinente pour « arrêter d'inliner ». C'est la perte de localité le facteur déterminant d'arrêt de l'inlining."
On est d'accord :) Disons que c'est évident pour un code donné.
Dans le cas d'une heuristique pour un compilo, avoir le code qui ré-augmente de taille permet de savoir quand arrêter d'inliner, même si cela n'est pas optimal (comme tu le dis le L1 change selon les CPU, l'optimum dépend donc de chaque cpu, ce qui a peu d’intérêt pour un binaire à distribué).
Cette vision des brevets n'est valable, que si un objet n'est couvert que par un seul d'entre eux. Dans la réalité, beaucoup sont concernés par des centaines de brevets.
Les boites sortent des séries de brevet pour allonger le maximum la durée de protection : pour les médicaments, il s'agit de la molécule, puis du process de fabrication.
De plus, beaucoup de brevet ne sont que des champs de mines à opposer aux concurrents, et non pour protéger un produit en particuliers. Il suffit de voir les barrières à l'entrée de la fabrication de lecteur DVD, ou du mpeg4.
" personne n'a jamais montré cette augmentation. "
En fait, c'est même pire que ça. Parce que l'augmentation de la taille de code n'implique pas forcément un code plus lent. D'ailleurs à cause du parallélisme des cpus actuels, un code plus gros, peut être plus rapide (ex: déroulage de boucle).
Tu n'aimes peut être pas mon style, alenvers est sans doute très compétant, mais cela n'enlève pas mes compétence non plus.
Par exemple, dans le projet Lisaac, il a été fait un test sur le compilateur (50 kloc) pour voir l'effet, incrément par incrément, de l'inlining, et la diminution puis l'augmentation de la taille du code était très visible. ET le pourquoi aussi.
L'équation fournis plus haut, formalise simplement le fait que l'on va plus vite en évitant un appel de fonction, et les aller-retour dans les registres que cela implique. Ce genre de code va en effet plus vite, mais, comme je l'ai déjà dit les compilo font bien plus que ça. Dés que l'on parle d'inline, on entend toujours quelqu'un dire "attention cela va pourri les caches avec l'augmentation de la taille du code", sauf que personne n'a jamais montré cette augmentation.
Et de mes propres expériences, j'ai remarqué une diminution. Cette croyance va si loin, que j'ai déjà vu des gens découpés un projet en différent .c pour empêcher l'inline automatique du compilateur, car il croit mieux faire le compilo : le code est finalement plus lent et plus gros. C'est une croyance tenace pour les gros code, alors que c'est justement ceux qui ont le plus tendance à réduire.
J'ai aussi codé un firmeware fondu dans un chip TI pour la gestion d'énergie des SOC de téléphone, le genre de truc où tu comptes les octets. Au final, tu te retrouves avec l'équivalent d'un gros fichier avec plein de fonctions static (sinon le code est inliné mais une fonction existe toujours en cas d'appel externe dans le code objet), ce qui correspond au code généré le plus petit. Je dis "l'équivalent d'un gros fichier" car c'est tout de même plus propre de découper et d'utiliser des "#includes".
Il ne faut pas oublier non plus le début du thread : "il y a le fait que ça augmente la taille du code et met donc plus de pressions sur le(s) cache(s) et au final peut ralentir l'exécution d'un programme complexe (ce qui ne se verra pas forcément dans un micro benchmark)." pour que cela soit vrai, la fonction doit être énorme, et ne pas se recombiner avec le code alentour, ce qui est rarement le cas.
Si j'ai bien compris on a 46% du pib pris par les prélèvements obligatoires, et 54% de dépense. La différence est prise par la dette.
Certain économise pense qu'il y a une point d'équilibre vers 60% de prélèvement obligatoires. Par contre, cela veut dire que l'état prendre en charge encore plus de chose ? (flexi sécurié aussi pour les entreprises ? Guichet unique ? formation tout au long de la vie ? financement des syndicats comme pour les partis politiques ? rapprochement des contrats de travail public/privé ? etc…)
Je pense que c'est un projet en soi. Cela peut être un tutorial, un script si cela devient complexe, voir un nouveau projet de module pour serveur, si vraiment une politique correct de sécurité devient une usine à gaz avec les outils actuels (on peut imaginer que le site web met tout seul à jour le DNSSEC par exemple).
[^] # Re: Facteur d'augmentation annuelle et temps de doublement
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 1.
Je pensais à la 2ième loi évoqué dans le wikipedia français
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
Les 4 points sont présent, si tu regarde bien, mais sans doute pas, comme tu le souhaiterais. Et si je n'ai pas mis de capture d'écran, j'ai mis des "consoles shot" dans le même but. Mais il manque les "$ ls" pour comprendre.
Tu as des remarques concernant la sortie du logiciel ou autres choses ? Je ferais une beta 2, avec toutes les remarques des commentaires.
"La première sécurité est la liberté"
[^] # Re: Quelques remarques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
tu en as trouver d'autre de ce genre de problème .
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
Je me disais que j'aurais dû ajouter des "$ ls -R" dans mon exemple.
Tu as lu aussi le readme.txt dans le git ? Et pas seulement le readme.md ?
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
Tu peux décrire ce qui te trouble plus précisément ?
L'idée est d'avoir un minimum "d'état". si il remplaçait le contenu de la liste, ou est-ce que je pourrais mettre les .idx ? Il faut aussi faire en sorte que lancer 2 fois de suite l'outil, ne change rien à l'état du système. si cela n'est pas stable, c'est compliqué de comprendre ce qui peux se passer.
./list est là où sont stocker les idx, qui est maintenu à jour.
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
"Ça n'empêche qu'il pourrait m'indiquer la taille correspondant à tous les ".idx" même si il trouve les fichiers sources."
Oui, l'un n’empêche pas l'autre.
L'outil ne regarde pas le contenu de ./list/. C'est plus simple si tu réfléchis avec des supports amovibles.
Bob a donné des fichiers .idx à Alice qui les copient dans le ./list/ de son disque usb. Celle-ci a ensuite transférer les .idx qui l'intéresse, de ./list/ à la racine (n'importe où ailleurs que ./list/). Ensuite, elle passe son disque à bob. Bob lance index à la racine du disque mobile, les fichiers .idx en dehors de ./list sont remplacé par les fichiers d'origines.
"générer l'arborescence idx, calculer la taille cible, réaliser la copie. Dans mon cas, il ne fait que le premier et toujours le premier."
Il détecte les .idx en dehors de ./list/, et tente de les remplacer par les fichiers d'origine.
Si il ne trouve les fichiers, ils additionnent leur taille. Si il les trouve, il les copie.
"La première sécurité est la liberté"
# iotop
Posté par Nicolas Boulay (site web personnel) . En réponse au journal cv, un petit outil pour surveiller vos copies. Évalué à 2.
Pour faire un suivi de copie, j'utilise iotop.
Si il y a plein de truc à copié, "index" marche pas trop mal, il a une routine de copie optimisé ( https://github.com/nicolasboulay/index/ ).
"La première sécurité est la liberté"
[^] # Re: Facteur d'augmentation annuelle et temps de doublement
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 2.
Il me semble que 2 ans correspond à la dernière des 3 lois de Moore.
"La première sécurité est la liberté"
[^] # Re: À propos d'opterons
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 4.
C'est le problème des moyennes : cela ne veut rien dire. Un OS n'a pas de code flottant, mais un os tout seul ne sert à rien. J'imagine qu'un jeu doit utiliser majoritaire des flottants 32 bits vectorisé, un code scientifique des nombre flottants 64 bits, un IDE ou un compilateur, un serveur web, une base de donné n'utilise que des entiers.
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
Super un utilisateur :)
Le problème est que la taille est calculée uniquement pour les fichiers qu'il ne trouve pas. Pour ne pas avoir les copies qui se lancent, il faut renommer, par exemple, le répertoire de base pour qu'il ne puisse pas trouver les fichiers d'origine. Le cas "normal" est de faire un trie, quand les fichiers ne sont pas présent.
Je pourrais mettre une option pour désactivé la copie, et calculer uniquement la taille.
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 3. Dernière modification le 28 novembre 2013 à 17:33.
"Comment l'outil sait si il faut génerer une copie, calculer la taille ou copier les fichiers, ça reste à définir mais c'est du détail."
C'est simple, il le fait à chaque fois dans l'ordre : mettre à jour la liste, détecter les fichiers d'index en dehors de la liste, essayer de faire une copie, donner la taille des fichiers qu'il n'arrive pas à copier.
Ce qui me fait très peur, c'est que cette démarche est expliquer en détail dans le journal, et encore une fois dans le readme.txt. Et cela n'a pas l'air d'être évident du tout.
"Reste une chose, lui trouver un nom."
Si cela gène tellement, je peux utiliser indexFile c'est le mot magique dans les fichiers d'index.
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à -1.
"Et puis merci pour ce genre de remarque constructive, c'est toujours agréable."
C'est toi qui a commencé sur ce ton, pourquoi tu t'étonnes que je continue ? (tu parlais de roue, je parle de porte)
1/ tu n'es pas la cible, ce n'est pas parce qu'un logiciel est expliqué sur linuxfr qu'il n'est utile qu'au gourou
2/ J'aimerais voir Alice avec un tableur quand il s'agit de gérer plein de série, au lieu de prendre un répertoire. Et puis, je ne comprends pas cette manie d'utiliser un tableur pour faire tout et n'importe quoi, comme de la gestion de base de donné.
3/ Mes 19 paragraphes étaient pour expliquer le processus de développement du logiciel et pas seulement le logiciel lui-même. Tu fais juste de la mauvaise fois.
"Fais mieux."
Pourquoi faire ?
Créer la liste :
$ ./index
Pour faire les copies ?
$ ./index
Pour vérifier la taille de la futur copie ?
$ ./index
Pour se faire son choix de fichier ?
$ cp …. # ou un navigateur de fichier
Cela te suffit ?
"La première sécurité est la liberté"
[^] # Re: À propos d'opterons
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 1.
Disons que le principe du thread de cpu reste le même, on partage un cpu avec un peu plus de ressources. D'ailleurs, je pense que commercialement AMD en aurait plus vendu, si l'image d'un seul core n'était pas aussi faible.
"La première sécurité est la liberté"
[^] # Re: Facteur d'augmentation annuelle et temps de doublement
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2013. Évalué à 2.
Il ne faut pas oublier que l'on parle de doublement à prix constant. Un power7 a un die énorme, même par rapport à un core i7. Je ne pense pas que le 4004 coutait plusieurs milliers d'euro pièce.
"La première sécurité est la liberté"
[^] # Re: la roue ça servait à quoi déjà ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 3.
Pas la peine d'essayer de me prouver que l'on peut faire les choses autrement, c'est enfoncer une porte ouverte.
Mais une ligne de commande comme :
find /path/to/my/collection -type f -name "*.avi" -or -name "*.mp?" -printf "%p\t%k\n" > /tmp/collection.csv
Ne fait pas parti de ce que j'appelle une interface simple.
"J'ai l'impression que c'est un peu le cas nominal "
Non, ce n'est pas le cas nominal. En général, tu as un paquet de cas ou tu ne te pointes pas chez les gens pour faire une copie. Ensuite, selon la taille des fichiers, on peut lancer tout en parallèle, et cela rallonge le temps global de copie, ou attendre entre chaque copie, ce qui est casse-pied.
"La première sécurité est la liberté"
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 3.
Le phread était à propos d'avoir des chiffres de ralentissement par rapport à l’agressivité de l'inlining, et non des généralités sur l'inline.
"One of the benefits of inlining, aside from eliminating the call/return, is that it opens new optimization opportunities by optimizing across the caller/callee boundary. In effect, it allows the called function to be specialized for the context from which it was called. For instance, one of the operands to a function might be a flag that enables/disables some feature controlled by the function. If that flag is a constant in the call, entire codepaths from the callee might become dead code. " commentaire sur lwm de 2004 (il y a presque 10 ans, une éternité pour l'informatique).
"La première sécurité est la liberté"
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 1.
Ce n'est pas parce que tu pointes des papiers qui parlent d'inline, que cela un rapport avec le thread.
"évite de nous parler d'obscurs projets que toi seul connais,"
Pourtant, on en a parlé souvent sur linuxfr (si tu parles de Lisaac, parce que si tu ne connais pas Texas Instrument, personne ne peux rien pour toi)! Tu dois être trop jeune sans doute.
"ou encore de papiers qui n'ont rien à voir avec le schmilblic"
Tu n'as pas du le lire, il y est question d'inline, même si cela n'est pas son sujet unique.
"culture confiture comme on dit."
On doit toujours être le vieux con de quelqu'un, j'imagine. Et toi, qu'est-ce que tu as fait de tellement exceptionnel pour te permettre de juger les gens ?
"La première sécurité est la liberté"
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 2.
"En conclusion, la réduction de la taille du code n'est pas pertinente pour « arrêter d'inliner ». C'est la perte de localité le facteur déterminant d'arrêt de l'inlining."
On est d'accord :) Disons que c'est évident pour un code donné.
Dans le cas d'une heuristique pour un compilo, avoir le code qui ré-augmente de taille permet de savoir quand arrêter d'inliner, même si cela n'est pas optimal (comme tu le dis le L1 change selon les CPU, l'optimum dépend donc de chaque cpu, ce qui a peu d’intérêt pour un binaire à distribué).
"La première sécurité est la liberté"
[^] # Re: Quelques remarques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à -2.
J'avoue que je n'ai pas compris l’intérêt humoristique de la blague.
"La première sécurité est la liberté"
[^] # Re: Quelques remarques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal “indexer, choisir et copier des fichiers” version Beta. Évalué à 2.
Je parle plus du processus de création que du logiciel lui-même, un peu plus haut victor semble avoir très bien compris l'usage.
"La première sécurité est la liberté"
[^] # Re: C'est discutable
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Dons, réductions d'impôts et brevets. Évalué à 10.
On dirait que tu répètes le discours de l'INPI.
Cette vision des brevets n'est valable, que si un objet n'est couvert que par un seul d'entre eux. Dans la réalité, beaucoup sont concernés par des centaines de brevets.
Les boites sortent des séries de brevet pour allonger le maximum la durée de protection : pour les médicaments, il s'agit de la molécule, puis du process de fabrication.
De plus, beaucoup de brevet ne sont que des champs de mines à opposer aux concurrents, et non pour protéger un produit en particuliers. Il suffit de voir les barrières à l'entrée de la fabrication de lecteur DVD, ou du mpeg4.
"La première sécurité est la liberté"
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 4.
" personne n'a jamais montré cette augmentation. "
En fait, c'est même pire que ça. Parce que l'augmentation de la taille de code n'implique pas forcément un code plus lent. D'ailleurs à cause du parallélisme des cpus actuels, un code plus gros, peut être plus rapide (ex: déroulage de boucle).
cf http://users.polytech.unice.fr/~dedale/cours/unix_et_linux/divers/GNULinux_France_Magazine_archives/lm32/C_Hack.html (cela date de 2001, écrit par moi-même, dans cette version il manque les images par contre)
"La première sécurité est la liberté"
[^] # Re: la performance par l'inlining
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Si si, le C++ peut parfois être plus rapide que le C. Évalué à 4.
Tu n'aimes peut être pas mon style, alenvers est sans doute très compétant, mais cela n'enlève pas mes compétence non plus.
Par exemple, dans le projet Lisaac, il a été fait un test sur le compilateur (50 kloc) pour voir l'effet, incrément par incrément, de l'inlining, et la diminution puis l'augmentation de la taille du code était très visible. ET le pourquoi aussi.
L'équation fournis plus haut, formalise simplement le fait que l'on va plus vite en évitant un appel de fonction, et les aller-retour dans les registres que cela implique. Ce genre de code va en effet plus vite, mais, comme je l'ai déjà dit les compilo font bien plus que ça. Dés que l'on parle d'inline, on entend toujours quelqu'un dire "attention cela va pourri les caches avec l'augmentation de la taille du code", sauf que personne n'a jamais montré cette augmentation.
Et de mes propres expériences, j'ai remarqué une diminution. Cette croyance va si loin, que j'ai déjà vu des gens découpés un projet en différent .c pour empêcher l'inline automatique du compilateur, car il croit mieux faire le compilo : le code est finalement plus lent et plus gros. C'est une croyance tenace pour les gros code, alors que c'est justement ceux qui ont le plus tendance à réduire.
J'ai aussi codé un firmeware fondu dans un chip TI pour la gestion d'énergie des SOC de téléphone, le genre de truc où tu comptes les octets. Au final, tu te retrouves avec l'équivalent d'un gros fichier avec plein de fonctions static (sinon le code est inliné mais une fonction existe toujours en cas d'appel externe dans le code objet), ce qui correspond au code généré le plus petit. Je dis "l'équivalent d'un gros fichier" car c'est tout de même plus propre de découper et d'utiliser des "#includes".
Il ne faut pas oublier non plus le début du thread : "il y a le fait que ça augmente la taille du code et met donc plus de pressions sur le(s) cache(s) et au final peut ralentir l'exécution d'un programme complexe (ce qui ne se verra pas forcément dans un micro benchmark)." pour que cela soit vrai, la fonction doit être énorme, et ne pas se recombiner avec le code alentour, ce qui est rarement le cas.
"La première sécurité est la liberté"
[^] # Re: qui sait
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 2.
Si j'ai bien compris on a 46% du pib pris par les prélèvements obligatoires, et 54% de dépense. La différence est prise par la dette.
Certain économise pense qu'il y a une point d'équilibre vers 60% de prélèvement obligatoires. Par contre, cela veut dire que l'état prendre en charge encore plus de chose ? (flexi sécurié aussi pour les entreprises ? Guichet unique ? formation tout au long de la vie ? financement des syndicats comme pour les partis politiques ? rapprochement des contrats de travail public/privé ? etc…)
"La première sécurité est la liberté"
[^] # Re: Pas tout compris mais du coup...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 3.
Je pense que c'est un projet en soi. Cela peut être un tutorial, un script si cela devient complexe, voir un nouveau projet de module pour serveur, si vraiment une politique correct de sécurité devient une usine à gaz avec les outils actuels (on peut imaginer que le site web met tout seul à jour le DNSSEC par exemple).
"La première sécurité est la liberté"