Il y a des gens qui font des allocations de 8 octets ?!
Et oui…. hélas…, c'est plus fréquents que ce que l'on pense et même de 1 octet !!! Chose que j'ai appris en passant MALT sur certains code et lorsque je développais un allocateur mémoire en thèse.
D'où l'utilité de MALT pour les pointer et les régler s'il y en a trop (en général n'y en a qu'une 10e donc on s'en fiche, mais tout de même).
Souvent cela arrrive aux travers de templates mal employés par exemaple avec un bool dans un smart pointer pour citer un des travers du C++.
Content de savoir que vous avez testé l'outil, votre code est-il open source ? Si vous avez des problèmes et que ce n'est pas trop compilé à faire tourner je peux jeter un oeil.
Si les fonctions d'allocation sont toutes à l'initialisation c'est parfait, c'est ce qu'il faut idéalement, donc éviter d'en avoir (sauf impossibilité ou en tout cas de manière raisonné) tout au long au milieu des calculs. Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size) nuisant aux caches ou vérifier que l'application ne fragmente pas si une partie des allocations sont libérées (requested_memory décroissante alors que la mémoire virtuelle ne suis pas cette tendance dans les graphiques temporels).
Oui je suppose qu'il y a quelques limitations pour la détection des lignes avec -O3 si le compilo est trop agressif et notamment si vous faite du LTO qui je suppose perd la plupart des outils de debug (j'utilise l'outil addr2line pour faire la correspondance). Mais cela ne doit pas non plus trop souvent changer les résultats. Un run en O0/O1 devrait donner des résultats plus précis sans fausser tant que ça les résultats (biais uniquement sur les durées de vie des blocs, mais pas pour les autres métriques : tailles…..). De toute façon MALT a un overhead non nul donc les résultats temporels sont de toute façon entachés d'une erreur, je pense qu'il est bon de recommencer de tourner en O0/O1 sans LTO pour profiler avec MALT.
Concernant votre problème de source d'allocation sur une ligne qui je le suppose fait du calcul. Ne serait-ce pas une ligne utilisant des allocatable array ? J'ai constaté (avec surprise) en développant l'outil que Gfortran peut générer par lui même des allocations dans ce cas. Le compilo Intel (ifort) lui ne le fait qu'au-delà d'un seuil configurable (par défaut infini). Cela est décrit dans les docs des deux compilo, si cela vous intéresse je peux essayer de retrouver les liens.
Pour ma thèse c'était au CEA à Paris, MALT au laboratoire exascale computing lab (université de versailles, CEA, Intel) et pour NUMAPROF j'étais au CERN jusqu'au mois dernier.
C'est vrai pour des micros applications, mais lorsque les codes deviennent gros (millions de ligne de code) les problèmes de gestion s'accumule et il n'est pas rare de voir pointer les fonctions malloc/free dans la top liste des X fonctions les plus appelée et les plus coûteuse.
Le compilateur ne peux rien dès qu'il s'agit d'allocation dynamique et du placement dans le temps long de l'application, seul le programmeur a la vue globale. La question du NUMA elle est très difficile à ce niveau dans l'état des connaissance. La principale source d'erreur pour le programmeur au delà du besoin de vision globale est que le noyau essai de faire de son mieux de manière transparente, donc si on ne comprends pas bien ce qu'il fait on se plante sans s'en rendre compte (d'où NUMAPROF).
C'était justement le sujet de ma thèse, l'implémentation d'un allocateur mémoire NUMA aware ainsi que quelques travaux plus bas dans le noyau. Vous trouverez des pointeurs sur le site des outils si cela vous intéresse.
Sur n'importe quelle distibution, il reprends juste certains concepts de Gentoo et utilise la base d'archive source Gentoo comme référence de secours pour les paquets non explicitement gérés.
Sur le principe il doit aussi marcher sur MacOSX, mais avec du travail sur les paquets graphiques.
Another point, as a developper who need some deps, I don't want to go throuth a 10 pages tutorial to setup my prefix. With HomeLinux I try to let the configuration as minimal as possible (maybe I fail… but I try ;) ).
Chroot is limited to root users and maybe LXC too ? Or am I wrong ? My main use case is a user on a station without any root rights and without any kernel level virtual machine engine available. Otherwise yes you have plenty of available solutions, even using Gentoo in a chroot.
Je pense également à un point, à l'exception de portage (gentoo) et packman (arch), les gestionnaires de paquets sont plutôt conçus pour installer des paquets binaires déjà compilés.
Ce qui pourrait être intéressant c'est d'ajouter la détection de dépendance dans gentoo prefix. Et la on retrouve quelque chose similaire à ce que fait HomeLinux avec une base de paquet existante mais toujours incomplète. Le problème dans ce cas c'est que si le paquet n'est pas géré vous êtes coincés, ce qui n'est pas le cas avec HomeLinux.
Je ne connaissais pas, il faut que je regarde, merci pour le lien. Dans la même idée il y a EasyBuild (https://hpcugent.github.io/easybuild/) qui se base complètement sur module sauf erreur.
Mon but est un peu différent, je cherche à considérer la construction d'un prefix cohérent avec des versions à jour (considérant le cas par exemple de mon ancien labo ou je devais travailler sur de vieilles centos sur lesquels je n'avais pas la main….). Je gère aussi module mais pour un nombre restrains de paquets pour lesquels cela à du sens (eg. multiples version de GCC).
Cela pourrais être intéressant, la question est à creuser. Je crois qu'il y a de choses possible avec les SRPM pour builder pour un autre prefix (http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable.html). Le problème est comment faire fonctionner ces gestionnaires de paquet pour gérer autre chose que / ? Je ne suis pas sur que la réponse soit simple.
Un de mes souci est aussi la coupure des dépendances. Avec un gestionnaire de paquet apt par exemple cela ne marcherais qu'au dessus d'une debian ou dérivée. Apt ne pourrait en effet pas trouver les dépendances dans la BDD d'une centos. Dans mon cas il faut que je fournisse un fichier de compatibilité de noms mais tout est possible. (ou bien il est possible d'utiliser la même approche avec un peu de patchs….).
HomeLinux supporte aussi très facilement des paquets non reconnus en cherchant les sources sur le net, on peut donc l'utiliser pour ses propres projets qui ne sont pas gérés par les distributions. C'est un avantage non négligeable comparé à apt, rpm…..
La description des paquets est très minimaliste pour facilité la maintenance et la mise à jour des numéros de version le plus automatique possible. On peut donc très facilement avoir accès aux toutes dernières versions. Je ne cherche pas ici à parler de stable/instable. On peut donc considéré HomeLinux comme un bac à sable pour tester facilement le mix des versions les plus à jour d'un ensemble de paquet. On offre donc un outils pour les développeurs.
# Super idée
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Lighten Mailbox : archivez vos courriels. Évalué à 1.
Hello, super idée, j'ai un projet similaire pour archiver mes mails assez proche de ce que vous avez fait en moins propre.
The force is in doing, not trying.
[^] # Re: J’ai testé MALT
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 2.
Et oui…. hélas…, c'est plus fréquents que ce que l'on pense et même de 1 octet !!! Chose que j'ai appris en passant MALT sur certains code et lorsque je développais un allocateur mémoire en thèse.
D'où l'utilité de MALT pour les pointer et les régler s'il y en a trop (en général n'y en a qu'une 10e donc on s'en fiche, mais tout de même).
Souvent cela arrrive aux travers de templates mal employés par exemaple avec un bool dans un smart pointer pour citer un des travers du C++.
The force is in doing, not trying.
[^] # Re: ça à l'air sympa.
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 1.
Votre code est-il accessible quelque part que je cherche le bug ?
The force is in doing, not trying.
[^] # Re: Excellent
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 4.
Si vous voulez les pointeurs sur l'ensemble de mes travaux : https://svalat.github.io/
The force is in doing, not trying.
[^] # Re: J’ai testé MALT
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 5.
Content de savoir que vous avez testé l'outil, votre code est-il open source ? Si vous avez des problèmes et que ce n'est pas trop compilé à faire tourner je peux jeter un oeil.
Si les fonctions d'allocation sont toutes à l'initialisation c'est parfait, c'est ce qu'il faut idéalement, donc éviter d'en avoir (sauf impossibilité ou en tout cas de manière raisonné) tout au long au milieu des calculs. Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size) nuisant aux caches ou vérifier que l'application ne fragmente pas si une partie des allocations sont libérées (requested_memory décroissante alors que la mémoire virtuelle ne suis pas cette tendance dans les graphiques temporels).
Oui je suppose qu'il y a quelques limitations pour la détection des lignes avec -O3 si le compilo est trop agressif et notamment si vous faite du LTO qui je suppose perd la plupart des outils de debug (j'utilise l'outil addr2line pour faire la correspondance). Mais cela ne doit pas non plus trop souvent changer les résultats. Un run en O0/O1 devrait donner des résultats plus précis sans fausser tant que ça les résultats (biais uniquement sur les durées de vie des blocs, mais pas pour les autres métriques : tailles…..). De toute façon MALT a un overhead non nul donc les résultats temporels sont de toute façon entachés d'une erreur, je pense qu'il est bon de recommencer de tourner en O0/O1 sans LTO pour profiler avec MALT.
Concernant votre problème de source d'allocation sur une ligne qui je le suppose fait du calcul. Ne serait-ce pas une ligne utilisant des allocatable array ? J'ai constaté (avec surprise) en développant l'outil que Gfortran peut générer par lui même des allocations dans ce cas. Le compilo Intel (ifort) lui ne le fait qu'au-delà d'un seuil configurable (par défaut infini). Cela est décrit dans les docs des deux compilo, si cela vous intéresse je peux essayer de retrouver les liens.
The force is in doing, not trying.
[^] # Re: Excellent
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 2.
Pour ma thèse c'était au CEA à Paris, MALT au laboratoire exascale computing lab (université de versailles, CEA, Intel) et pour NUMAPROF j'étais au CERN jusqu'au mois dernier.
The force is in doing, not trying.
[^] # Re: Accès
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 3.
C'est vrai pour des micros applications, mais lorsque les codes deviennent gros (millions de ligne de code) les problèmes de gestion s'accumule et il n'est pas rare de voir pointer les fonctions malloc/free dans la top liste des X fonctions les plus appelée et les plus coûteuse.
The force is in doing, not trying.
[^] # Re: Accès
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 3.
Le compilateur ne peux rien dès qu'il s'agit d'allocation dynamique et du placement dans le temps long de l'application, seul le programmeur a la vue globale. La question du NUMA elle est très difficile à ce niveau dans l'état des connaissance. La principale source d'erreur pour le programmeur au delà du besoin de vision globale est que le noyau essai de faire de son mieux de manière transparente, donc si on ne comprends pas bien ce qu'il fait on se plante sans s'en rendre compte (d'où NUMAPROF).
The force is in doing, not trying.
[^] # Re: Excellent
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 2.
C'était justement le sujet de ma thèse, l'implémentation d'un allocateur mémoire NUMA aware ainsi que quelques travaux plus bas dans le noyau. Vous trouverez des pointeurs sur le site des outils si cela vous intéresse.
The force is in doing, not trying.
[^] # Re: Lié à Gentoo ?
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 3.
Sur n'importe quelle distibution, il reprends juste certains concepts de Gentoo et utilise la base d'archive source Gentoo comme référence de secours pour les paquets non explicitement gérés.
Sur le principe il doit aussi marcher sur MacOSX, mais avec du travail sur les paquets graphiques.
The force is in doing, not trying.
[^] # Re: intégration avec d'autres gestionnaires
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 1.
Another point, as a developper who need some deps, I don't want to go throuth a 10 pages tutorial to setup my prefix. With HomeLinux I try to let the configuration as minimal as possible (maybe I fail… but I try ;) ).
The force is in doing, not trying.
[^] # Re: intégration avec d'autres gestionnaires
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 1.
Chroot is limited to root users and maybe LXC too ? Or am I wrong ? My main use case is a user on a station without any root rights and without any kernel level virtual machine engine available. Otherwise yes you have plenty of available solutions, even using Gentoo in a chroot.
The force is in doing, not trying.
[^] # Re: intégration avec d'autres gestionnaires
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 1.
Je pense également à un point, à l'exception de portage (gentoo) et packman (arch), les gestionnaires de paquets sont plutôt conçus pour installer des paquets binaires déjà compilés.
Ce qui pourrait être intéressant c'est d'ajouter la détection de dépendance dans gentoo prefix. Et la on retrouve quelque chose similaire à ce que fait HomeLinux avec une base de paquet existante mais toujours incomplète. Le problème dans ce cas c'est que si le paquet n'est pas géré vous êtes coincés, ce qui n'est pas le cas avec HomeLinux.
The force is in doing, not trying.
[^] # Re: Nix ?
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 2.
Je ne connaissais pas, il faut que je regarde, merci pour le lien. Dans la même idée il y a EasyBuild (https://hpcugent.github.io/easybuild/) qui se base complètement sur module sauf erreur.
Mon but est un peu différent, je cherche à considérer la construction d'un prefix cohérent avec des versions à jour (considérant le cas par exemple de mon ancien labo ou je devais travailler sur de vieilles centos sur lesquels je n'avais pas la main….). Je gère aussi module mais pour un nombre restrains de paquets pour lesquels cela à du sens (eg. multiples version de GCC).
The force is in doing, not trying.
[^] # Re: intégration avec d'autres gestionnaires
Posté par Sébastien Valat (site web personnel) . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 3.
Cela pourrais être intéressant, la question est à creuser. Je crois qu'il y a de choses possible avec les SRPM pour builder pour un autre prefix (http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable.html). Le problème est comment faire fonctionner ces gestionnaires de paquet pour gérer autre chose que / ? Je ne suis pas sur que la réponse soit simple.
Un de mes souci est aussi la coupure des dépendances. Avec un gestionnaire de paquet apt par exemple cela ne marcherais qu'au dessus d'une debian ou dérivée. Apt ne pourrait en effet pas trouver les dépendances dans la BDD d'une centos. Dans mon cas il faut que je fournisse un fichier de compatibilité de noms mais tout est possible. (ou bien il est possible d'utiliser la même approche avec un peu de patchs….).
HomeLinux supporte aussi très facilement des paquets non reconnus en cherchant les sources sur le net, on peut donc l'utiliser pour ses propres projets qui ne sont pas gérés par les distributions. C'est un avantage non négligeable comparé à apt, rpm…..
La description des paquets est très minimaliste pour facilité la maintenance et la mise à jour des numéros de version le plus automatique possible. On peut donc très facilement avoir accès aux toutes dernières versions. Je ne cherche pas ici à parler de stable/instable. On peut donc considéré HomeLinux comme un bac à sable pour tester facilement le mix des versions les plus à jour d'un ensemble de paquet. On offre donc un outils pour les développeurs.
The force is in doing, not trying.