Reserfs4 dispose d'un grand nombre de fonctionnalité contreversé. Il fait avancé les choses et permet la compététition avec winFS mais les FS sont le dommaines le plus sensible d'un OS. Les données sont fait pour durer des années avec des versions différentes de Linux. Cf le text sur le sujet sur kerneltrap.
Le système de plugin est sympa mais si elle rend les reiserfs4 imcompatible entre eux, cela va être un bordel sans nom. Il y aura reserfs4 vanilla, reserfs4+compression, reiserfs4+compressionv2, reiserfs4+compression+schedulerbdd, reiserfs4+compression+schedulerbigfile, etc...
Bref, un beau merdier. Imagines tu upgrades ton linux et ta partition devient illisible...
Le VFS permet d'avoir une interface standard entre le fs et le reste du noyau. Cela permet d'avoir du code commun et surtout de (correctement) gérer les concurences d'acces, ce qui peut être très complexe. reiserfs4 bouleverse ça et rajoute une autre interface qui peut effectivement foutre la merde...
Au vue des commentaires, notament sur le writeout code, on comprends que la solution serait d'étendre un peu VFS et de communalisé le code reiserfs4 avec les autres systèmes de fichiers (un module de compression devrait pouvoir bénéficier à tout le monde !).
L'autre problème de base conceptuel est dans le fait que tous les fichiers sont des directory pour gérer les metadonnés, ce qui pose un énorme problème pour la gestion des liens pour les applications (en gros imaginez un "find" qui part en boucle...).
Bref, les problèmes posés sont interrescants et mérite d'être corrigé. Mais c'est des gros problèmes conceptuels de design du noyau pas des questions politiques.
Imagine qu'une ville française se prenne 100 rockets de 50 kilos d'explosif sur la tête tous les jours, je ne pense pas que l'on reste sans rien faire...
Non justement. C'est le cas depuis la "révolte" de troupe de l'onu en bosnie, des français il me semble d'ailleurs. Depuis, on ne leur donne plus de mandat débile ou ils ont juste le droit de compter les morts (cf le film de télé de la BBC "warriors").
Pas de bol, la FINUL(E?) date d'avant la bosnie et a toujours ce mandat débile. Si les états avaient des couilles, ils auraient du avoir tout pouvoir pour démilitarisé la zone de la frontière, quitte à devoir tirer sur les libanais, le hezbolha ou Israel.
"Faux : c'était considéré comme de la copie privée [1]"
Non, cela a été très discuté et beaucoup de jugement de ce style on été cassé. La notion de cercle familial s'étant aux amis mais pas au inconnu !
C'est sois une violation de copyirght soit du recel de contrefaçon (contrefaçon fait par la personne qui upload). Si on a déjà le CD, cela devient marrant car il ne reste que le recel or pour avoir recel il faut prouver la contrefaçon (en effet rien interdit d'avoir enregister la radio ou ripper un CD que l'on a perdu, ça c'est la copie privé)
interdit depuis toujours, c'est du recel de contrefaçon.
"l'échange de logiciels libres via P2P"
Cela risque d'être interdit, car les logiciels "manifestement" dédier à l'échange de fichier illégaux deviennent eux-même illégaux. (bref, vendeur de couteau et de pistolet : tous en taule !)
"l'échange de logiciels non-libres via P2P"
pareil que le 1). Contrefaçon.
"tout logiciel de P2P"
Oui, c'est le manifestement qui décide ce qui est illégal de ce qu'il ne l'est pas. Un juge prendra sans doute le principe d'intériorité pour décider. le ftp sera ok. Mais emule ne le sera pas. Vient ensuite le problème de bittorrent...
"le protocole P2P"
Quasiement toute nouvelle implémentation de nouveau protocole peut devenir illégal à cause du manifestement (amendement vivendi-universal)
L'article du point de vue temps réel n'est pas top.
Comment dire que linux assure du 20 µs de latence quand certain drivers peuvent prendre la main pour des millisecondes.
Pour qu' un système sois temps réel, il faut _aussi_ que les drivers soient prévus avec une latence maximum faible, le soft dispose bien d'entrée-sortie sinon il ne sert à rien...
J'avais entendu parler de ça sous le terme "puit canadien".
En gros, le tuyau d'air de la VMC passe dans la terre sous la maison avant d'entrer dedans. Cela permet de refroidir l'air en été et la réchauffer en hiver.
un proc rescent peut faire 5 instructions en parralèle le tout sur un long pipeline. Tu as typiquement 2 additionneur et 1 multiplieur. Ta version implique beaucoup de variables temporaires qui sont réutilisés, le calcul ne peut pas se faire en parrallèle.
En fait, je veux tester un layout particulier tirant parti des lignes de caches.
En gros, une ligne de cache fait 32 ou 64 octets selon le modèle de processeur. Donc, je pense que cela serait super interrescant d'avoir les voisins dans cette ligne de cache. Par exemple, si tu découpes ton images en cube de 4*4*4, tu as tous les voisins 4*4 dans la même ligne de cache ou presque. C'est du tailing, cela permet d'augmenter la localité d'acces aux donnés.
Je cherche pas à faire des animations mais du traitement temps réel :)
C'est pour ça que je parlais de gain théorique. Je ne crois pas qu'il existe des astuces en c++ qui permète d'induire un choix de layout mémoire selon l'utilisation qu'il en est fait. Si cela existait l'utilisateur n'aurait pas à s'en soucier.
J'ai continué à torturer la bète. J'ai utiliser ./nlmeans pour bencher rapidement la chose.
La fonction offset() est très utilisé forcément. En la modifiant par :
Le but est de réduire le nombre de dépendance read-after-write qui tue le parralèlisme.
J'obtient 10% de perf en plus sur le test sur processeur athlon. Par contre, cela ne change rien sur une machine pentium.
Les 3 tests qui sont dans CImg_demo qui rendent des fps sont en fait très dépendant de la vitesse d'affichage donc non représentatif pour les calculs.
J'ai essayé de modifier offset() pour que v sois la 1er dimension et non la dernière. Telle que c'est codé ici, on a 3 plans de couleur, un vert, un rouge, un bleu. Avec v en première dimension, on a R,V,B,R,V,B,R,V,B,... Cela dépend beaucoup des calculs mais je pense qu'en général, quand on utilise une couleur d'un pixel on a beaucoup de chance d'immédiatement utiliser les autres couleurs. Dans le "rangement" RVB, les 3 couleurs sont dans la même ligne de cache, donc en théorie, les acces devrait être plus rapide.
A prioris d'autre macro utilise le layout mémoire sous -entendu donc il faudrait modifier plus de chose que offset() pour faire le test.
Les standards de programmation s'apprennent rarement à l'école. Mais se trouve dans plein de papiers.
Il faut savoir sortir des sentiers battus de temps en temps, sinon on coderait encore tout en basic.
Cela n'a pas de rapport en l'occurence... Je ne considère pas le fait de tout mettre dans un seul fichier comme ayant un seul avantage sur celui d'avoir quelques fichiers. L'utilisation d'opérateur ternaire est une vrai avancé.
Avec un IDE qui retrouve les tags, cela peut se faire mais bon...
Sinon avec des header précompilé, je gagne plus de 60% du temps de compilation cela devient accèptable.
J'ai essayé l'option de compilation -ftree-vectorize, cela change très peu les temps d'execution, je suis un peu déçu.
C'est quand même plus simple et moins lourd d'avoir plusieurs fichiers. Regardes boost ou autre.
J'ai bricolé avec hier soir. Le plus chiant c'est vraiment les temps de compilations. Plusieurs minutes sur un pc pas trop vieux pour un seul fichier ! (gcc 4.0.1) C'est d'autant plus énervant sur un bi-cpu avec le 2ième cpu idle (car il n'y a qu'un fichier à compiler).
je séparerais aussi le code de traitement d'image proprement dit du code d'affichage. C'est plus propre si la lib est utilisé avec kde ou wxwidget par exemple.
La structuration classique est au minimum de séparer ce qui est portable de ce qui ne l'est pas. Donc, cela ferait un cimg.h et des unix.h et windows.h, l'interet de facilité la vie d'un mec qui ferais le portage pour une autre archi. Idem pour les fonctions bas niveau qui sont ressponsable des performances. Il peut y avoir 50 versions (en C++, en mmx, sse, sse2, sse3, avec de la génération de code en ligne, en utilisant les shaders d'une carte graphique, etc...). Typiquement aussi, c'est un objet par fichier, le fichier ayant le même nom que l'objet.
Pour la vitesse de compilation, si ton code est découpé, sous unix, le include <cimg_windows.h> ne sera pas executé, et les lignes correspondante non parsé, c'est peut-être negligable, j'en sais trop rien. Mais je trouve que le temps de compile des exemples est long.
Pour le nouveau entrant qui s'interesserait à la bibliothèque en elle-même, je pense même que c'est plus facile de faire un 'Search' du nom de la fonction dans un seul fichier plutot qu'un grep pour savoir deja dans quel fichier se trouve la fonction, puis un search.
Si ton code est correctement structuré, tu sais tout de suite quel fichier ouvrir pas besoin de grep.
Eviter l'effet masse, c'est aussi un moyen d'avoir plus de codeurs.
Découpé le code en différent .h permet de mieux séparer physiquement le code en module et permet de rentrer plus facilement dedans. Cela peut aussi permètre de gagner en temps de compilation en allegeant le preprocesseurs.
Cela permet au nouveau entrant de savoir tout de suite ou aller chercher les fonctions à modifier. Cela évite de connaitre tout le code avant de commencer une modif.
J'imagine que bouger un .h est plus simple qu'une arboressence, mais cela revient en fait au même.
J'ai franchement du mal à lire. Moi qui croyait que les templates évitaient d'utiliser les macro...
// Create two display window, one for the image, the other for the color profile.
CImgDisplay
main_disp(image,"Color image (Try to move mouse pointer over)",0),
draw_disp(500,400,"Color profile of the X-axis",0);
cimg_mapXYZV(dest,x,y,z,k) {
const double X = ((double)x/img1.dimx()-0.5)*ca + ((double)y/img1.dimy()-0.5)*sa;
if (X+0.5<pmin) alpha=0; else {
if (X+0.5>pmax) alpha=1; else alpha=(X+0.5-pmin)/(pmax-pmin);
}
dest(x,y,z,k) = (unsigned char)((1-alpha)*img1(x,y,z,k) + alpha*img2(x,y,z,k));
}
Le code précédent qui ressemble à une fonction est en fait dans le corps de main. Certe il y a peu de ligne de code, mais j'avoue avoir du mal à le comprendre ce code. A quoi sert de faire du c++, si c'est aussi facile à lire que du perl.
[^] # Re: Hum...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et Reiser4 nous apprend comment fonctionne la communauté. Évalué à 4.
Le système de plugin est sympa mais si elle rend les reiserfs4 imcompatible entre eux, cela va être un bordel sans nom. Il y aura reserfs4 vanilla, reserfs4+compression, reiserfs4+compressionv2, reiserfs4+compression+schedulerbdd, reiserfs4+compression+schedulerbigfile, etc...
Bref, un beau merdier. Imagines tu upgrades ton linux et ta partition devient illisible...
Le VFS permet d'avoir une interface standard entre le fs et le reste du noyau. Cela permet d'avoir du code commun et surtout de (correctement) gérer les concurences d'acces, ce qui peut être très complexe. reiserfs4 bouleverse ça et rajoute une autre interface qui peut effectivement foutre la merde...
Au vue des commentaires, notament sur le writeout code, on comprends que la solution serait d'étendre un peu VFS et de communalisé le code reiserfs4 avec les autres systèmes de fichiers (un module de compression devrait pouvoir bénéficier à tout le monde !).
L'autre problème de base conceptuel est dans le fait que tous les fichiers sont des directory pour gérer les metadonnés, ce qui pose un énorme problème pour la gestion des liens pour les applications (en gros imaginez un "find" qui part en boucle...).
Bref, les problèmes posés sont interrescants et mérite d'être corrigé. Mais c'est des gros problèmes conceptuels de design du noyau pas des questions politiques.
"La première sécurité est la liberté"
[^] # Re: Vive la braderie, vive linux.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Stand des Logiciels Libres à la braderie de Lille. Évalué à 3.
En fonction des tes compétences, tu testes, remontes des bugs de façon pertinente, participe au dévélopement sinon tu peux aussi leur donner des sous.
"La première sécurité est la liberté"
[^] # Re: Je suis pas certain du truc
Posté par Nicolas Boulay (site web personnel) . En réponse au journal PHP is dying. Évalué à 5.
Imagine qu'une ville française se prenne 100 rockets de 50 kilos d'explosif sur la tête tous les jours, je ne pense pas que l'on reste sans rien faire...
"La première sécurité est la liberté"
[^] # Re: Je suis pas certain du truc
Posté par Nicolas Boulay (site web personnel) . En réponse au journal PHP is dying. Évalué à 2.
Pas de bol, la FINUL(E?) date d'avant la bosnie et a toujours ce mandat débile. Si les états avaient des couilles, ils auraient du avoir tout pouvoir pour démilitarisé la zone de la frontière, quitte à devoir tirer sur les libanais, le hezbolha ou Israel.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal DAVSI = rien compris. Évalué à 3.
Non, cela a été très discuté et beaucoup de jugement de ce style on été cassé. La notion de cercle familial s'étant aux amis mais pas au inconnu !
C'est sois une violation de copyirght soit du recel de contrefaçon (contrefaçon fait par la personne qui upload). Si on a déjà le CD, cela devient marrant car il ne reste que le recel or pour avoir recel il faut prouver la contrefaçon (en effet rien interdit d'avoir enregister la radio ou ripper un CD que l'on a perdu, ça c'est la copie privé)
"La première sécurité est la liberté"
[^] # Re: Sommet Linux 2006
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kernel Summit et Linux Symposium. Évalué à 2.
"La première sécurité est la liberté"
# ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal DAVSI = rien compris. Évalué à 2.
interdit depuis toujours, c'est du recel de contrefaçon.
"l'échange de logiciels libres via P2P"
Cela risque d'être interdit, car les logiciels "manifestement" dédier à l'échange de fichier illégaux deviennent eux-même illégaux. (bref, vendeur de couteau et de pistolet : tous en taule !)
"l'échange de logiciels non-libres via P2P"
pareil que le 1). Contrefaçon.
"tout logiciel de P2P"
Oui, c'est le manifestement qui décide ce qui est illégal de ce qu'il ne l'est pas. Un juge prendra sans doute le principe d'intériorité pour décider. le ftp sera ok. Mais emule ne le sera pas. Vient ensuite le problème de bittorrent...
"le protocole P2P"
Quasiement toute nouvelle implémentation de nouveau protocole peut devenir illégal à cause du manifestement (amendement vivendi-universal)
"La première sécurité est la liberté"
[^] # Re: Sommet Linux 2006
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kernel Summit et Linux Symposium. Évalué à 2.
Comment dire que linux assure du 20 µs de latence quand certain drivers peuvent prendre la main pour des millisecondes.
Pour qu' un système sois temps réel, il faut _aussi_ que les drivers soient prévus avec une latence maximum faible, le soft dispose bien d'entrée-sortie sinon il ne sert à rien...
"La première sécurité est la liberté"
[^] # Re: un de ces quatre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ah ! Les femmes .... Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: un de ces quatre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ah ! Les femmes .... Évalué à 3.
En gros, le tuyau d'air de la VMC passe dans la terre sous la maison avant d'entrer dedans. Cela permet de refroidir l'air en été et la réchauffer en hiver.
"La première sécurité est la liberté"
[^] # Re: un de ces quatre
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ah ! Les femmes .... Évalué à 1.
A part perdre de l'eau, je ne voix pas bien l'interet de se désabillé quand il fait chaud... (à par pour les filles quand on est un mec)
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
En gros, une ligne de cache fait 32 ou 64 octets selon le modèle de processeur. Donc, je pense que cela serait super interrescant d'avoir les voisins dans cette ligne de cache. Par exemple, si tu découpes ton images en cube de 4*4*4, tu as tous les voisins 4*4 dans la même ligne de cache ou presque. C'est du tailing, cela permet d'augmenter la localité d'acces aux donnés.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
Tu as pu vérifier l'augmentation de performance avec la modification de offset () ?
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
C'est pour ça que je parlais de gain théorique. Je ne crois pas qu'il existe des astuces en c++ qui permète d'induire un choix de layout mémoire selon l'utilisation qu'il en est fait. Si cela existait l'utilisateur n'aurait pas à s'en soucier.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 4.
La fonction offset() est très utilisé forcément. En la modifiant par :
return (x+width*y)+(width*height*z+width*height*depth*v);
Le but est de réduire le nombre de dépendance read-after-write qui tue le parralèlisme.
J'obtient 10% de perf en plus sur le test sur processeur athlon. Par contre, cela ne change rien sur une machine pentium.
Les 3 tests qui sont dans CImg_demo qui rendent des fps sont en fait très dépendant de la vitesse d'affichage donc non représentatif pour les calculs.
J'ai essayé de modifier offset() pour que v sois la 1er dimension et non la dernière. Telle que c'est codé ici, on a 3 plans de couleur, un vert, un rouge, un bleu. Avec v en première dimension, on a R,V,B,R,V,B,R,V,B,... Cela dépend beaucoup des calculs mais je pense qu'en général, quand on utilise une couleur d'un pixel on a beaucoup de chance d'immédiatement utiliser les autres couleurs. Dans le "rangement" RVB, les 3 couleurs sont dans la même ligne de cache, donc en théorie, les acces devrait être plus rapide.
A prioris d'autre macro utilise le layout mémoire sous -entendu donc il faudrait modifier plus de chose que offset() pour faire le test.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 1.
Il faut savoir sortir des sentiers battus de temps en temps, sinon on coderait encore tout en basic.
Cela n'a pas de rapport en l'occurence... Je ne considère pas le fait de tout mettre dans un seul fichier comme ayant un seul avantage sur celui d'avoir quelques fichiers. L'utilisation d'opérateur ternaire est une vrai avancé.
Avec un IDE qui retrouve les tags, cela peut se faire mais bon...
Sinon avec des header précompilé, je gagne plus de 60% du temps de compilation cela devient accèptable.
J'ai essayé l'option de compilation -ftree-vectorize, cela change très peu les temps d'execution, je suis un peu déçu.
"La première sécurité est la liberté"
[^] # Re: il faut ensuite replacer firefox comme User Agent
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Indignation : Ebay et Linux. Évalué à 9.
ok je ->[]
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
J'ai bricolé avec hier soir. Le plus chiant c'est vraiment les temps de compilations. Plusieurs minutes sur un pc pas trop vieux pour un seul fichier ! (gcc 4.0.1) C'est d'autant plus énervant sur un bi-cpu avec le 2ième cpu idle (car il n'y a qu'un fichier à compiler).
Sinon, cela a l'air simple d'emplois.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 4.
Pour la vitesse de compilation, si ton code est découpé, sous unix, le include <cimg_windows.h> ne sera pas executé, et les lignes correspondante non parsé, c'est peut-être negligable, j'en sais trop rien. Mais je trouve que le temps de compile des exemples est long.
Pour le nouveau entrant qui s'interesserait à la bibliothèque en elle-même, je pense même que c'est plus facile de faire un 'Search' du nom de la fonction dans un seul fichier plutot qu'un grep pour savoir deja dans quel fichier se trouve la fonction, puis un search.
Si ton code est correctement structuré, tu sais tout de suite quel fichier ouvrir pas besoin de grep.
Eviter l'effet masse, c'est aussi un moyen d'avoir plus de codeurs.
"La première sécurité est la liberté"
[^] # Re: Apu updates ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 1.
Cela permet au nouveau entrant de savoir tout de suite ou aller chercher les fonctions à modifier. Cela évite de connaitre tout le code avant de commencer une modif.
J'imagine que bouger un .h est plus simple qu'une arboressence, mais cela revient en fait au même.
"La première sécurité est la liberté"
[^] # Re: oups un seul fichier...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
"La première sécurité est la liberté"
[^] # du c++ ?!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de CImg 1.1.5. Évalué à 2.
// Create two display window, one for the image, the other for the color profile.
CImgDisplay
main_disp(image,"Color image (Try to move mouse pointer over)",0),
draw_disp(500,400,"Color profile of the X-axis",0);
cimg_mapXYZV(dest,x,y,z,k) {
const double X = ((double)x/img1.dimx()-0.5)*ca + ((double)y/img1.dimy()-0.5)*sa;
if (X+0.5<pmin) alpha=0; else {
if (X+0.5>pmax) alpha=1; else alpha=(X+0.5-pmin)/(pmax-pmin);
}
dest(x,y,z,k) = (unsigned char)((1-alpha)*img1(x,y,z,k) + alpha*img2(x,y,z,k));
}
Le code précédent qui ressemble à une fonction est en fait dans le corps de main. Certe il y a peu de ligne de code, mais j'avoue avoir du mal à le comprendre ce code. A quoi sert de faire du c++, si c'est aussi facile à lire que du perl.
"La première sécurité est la liberté"