J'ai commencé à 12 ans avec du BASIC-A. Puis, Pascal, ASM, le C à la FAC, puis Clisp, prolog (est-ce un langage ?)
Pour mon fils, je me demande entre du logo, un basic, il y avait linotte ou scratch aussi. J'aime bien le principe de scratch, c'est de l'algo visuel, mais je ne suis pas certains de la pertinence de ne pas taper réellement le code, de devoir faire de l'animation, etc.
C'est justement un des points forts de KDE, car les process kioslave accède aux disques, mais tous les processus KDE utilisene les mêmes, ce qui donne une meilleure empreinte en RAM, etc. si tu utilises beaucoup de processus KDE.
Ce qu'il faudrait peut-être ajouter, c'est un suicide de ces process si plus personne ne les utilise depuis un certain temps (0 pouvant être acceptable). Une nouvelle feature à proposer pour KDE ?
Tu as raison sur le principe, pour éviter le padding d'une structure on ordonne les champs dans l'ordre de taille décroissante. Mais tu ne choisi pas forcément le codage d'une trame BUS que tu reçois par exemple.
Sinon, il y a une petite erreur sur ton premier exemple :
structtoto_s{uint8_tf1;uint32_tf2;uint16_tf3;uint64_tf4;uint8_tf5;};// Avec paddingstructtoto_s{uint8_tf1;// offset 0charpadding1[3];//offset 1uint32_tf2;// offset 4 : Aligné sur 32bitsuint16_tf3;// offset 8 : Aligné sur 16charpadding2[6];// offset 10uint64_tf4;// offset 16 : Aligné sur 64uint8_tf5;// offset 24 : Aligné sur 1 ;-)};
Un simple sizeof entre une structure bien rangé et une autre est vraiment parlant. C'est utile quand la RAM peut manquer, sinon, je trouve plus clair de mettre des champs qui ont des affinités ensembles.
En effet, les patrons de fonctions été compilé localement dans chaque fichier cpp sans exporter les symbols. Du coup les binaires grossissais pas mal. Mais il y avait un hack :
Tu compilais avec une option pour pas générer les template.
Plein d'erreur d'édition des liens.
Avec les erreurs de l'édition de lien tu activais les template juste une fois.
Je n'aurais pas été jusqu'à ne garantissent rien du tout mais c'est un peu ça. Les compilateurs se comporte globalement de la même façon. Dans l'embarqué, tu connais généralement l'ensemble donc les structures sont plus esthétiques à mon sens et plus lisible. L'avantage des macros, c'est que tu n'as que l'endianess à gérer. C'est plus simple de faire du code portable. Par contre, même punition que les structure, les macro doivent être cantonnées à l'accès avec l'extérieur et recopier les données dans une structure interne propre.
Le padding dépend effectivement des deux, même si la principale contrainte vient du CPU. Sur le Power PC par exemple, il ne sait pas faire d'accès mémoire non aligné. Donc si tu force le compilo à ne pas aligner, pour chaque mot, il a 3 chances sur 4 de faire 2 accès mémoires (la deuxième en cache) plus de la recombinaison des données.
avec les champs de bits C, incertitude sur le padding ?
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut packed à la structure par exemple, sous visual c'est un #pragma
avec les champs de bits C, incertitude sur l'ordre des champs, des bits, des octets, des mots ?
Là encore, c'est connue mais dépend de l'endianness… Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'int ne fait pas 32 bits.
avec les champs de bits C, incertitude sur la taille du type crée ?
Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.
des projets en C n'ont absolument aucune raison d'être en C.
Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final, à choisir le langage avec le meilleurs paradigme et pour chaque paradigme, avoir une vision suffisamment clairvoyante pour analyser en avance de phase lequel des langages sera le plus adapté. Je n'en suis hélas pas capable. :'( Par défaut et comme beaucoup, je code avec ce que je connais. Je me fais des TPs pour tester de nouveaux langages (j'ai tenté haskell dernièrement), mais de là à démarrer un projet pouvant devenir gros… je préfère rester en terrain connu en connaissance de cause et sachant à l'avance les problèmes que je risque de rencontrer.
De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.
Je ne crois pas. Après, je n'ai pas essayé avec gparted. Je tenterai sur une clé usb pour voir la réaction de gparted sur un disque sans table de partitions.
Tu as une instruction de moins, la belle affaire si entre l'instruction deux et trois, tu dois attendre 20 cycles la valeur en RAM. Alors qu'avec tes quatre instructions, le compilateur en rajoute une cinquième à un endroit stratégique pour éviter ce temps d'attente.
En caricaturant, avec 4 instruction initialement tu utilises 5 cycles et avec tes 3 tu utilises 23 cycles… où est l'optimisation ?
Sur un int il n'y aura aucun1 impact. Les compilateurs moderne se débrouille très bien pour savoir quand le faire au mieux. Il y a peu être un impact avec une copie de registre si vraiment les deux valeurs sont utiles. Mais généralement, c'est du a++ dans un for, while sans besoin de la valeur initiale. On peut avoir b=a++ mais là, le compilo va d'abord copier puis incrémenter. Pareil pour les expression du type c=a + b++ où on va faire le add regA, regB (le résultat est stocké dans regA) puis inc regB. Le seul cas que je vois c'est c=a++ + b je ne sais pas si le compilateur fait jouer la commutativité pour gagner un cycle… je ne suis pas sûr de la pertinence de se genre d'optimisation.
enfin, vraiment mineur avec les compilateurs modernes. Si tu en es à gratter au cycle près, c'est qu'il y a un problème de conception générale du programme àmha. ↩
Parce que ça optimise quelque chose en termes de performances de passer à la version pre-increment ?
Oui, en c++.
Quand tu déclares en pré-incrément, tu n'a pas de copie.
// .hClasse&operator++();//.cppClasse&operator++(){// Code d'incrément (plus ou moins long)return*this;}
Ici, on retourne une référence sur l'objet incrémenté.
// .hClasseoperator++(int);// le paramètre signifie post incrément// .cppClasseoperator++(int){Classetmp=*this;// Copie de l'objet// Code d'incrément// On retourne une copie de l'objet avant l'incrément. Ce ne peut-être une réf, car il est sur la pile.returntmp;// Copie de l'objet}
Ici, on a deux copies, ce qui peut poser un problème si l'objet est gros. C'est pour ça, notamment sur les fonctions template où tu ne présuppose pas ce que tu as comme objet qu'il vaut mieux faire des pré-incrément en c++.
Je ne sais pas si c++11 permet avec le && d'écrire les post-incrément mieux ?
Un dev C aurait utilisé une arithmétique de pointeurs, un dev C++ des itérateurs.
Oui pour les itérateurs, mais pour les pointeurs, il faut faire attention. Si tu boucles avec des pointeurs, le compilateur ne présuppose plus rien. Alors qu'avec les indices, il est capable d'optimiser aussi bien que les pointeurs, voir mieux car comme il sait où il va, il peut faire du prefetch.
Comme disais Carmack : Ne supposez pas que ça va plus vite, vérifiez-le !
Le cache en CPU, fonctionne par ligne appelée ligne de cache. Celle-ci contient 4 ou plus mot de 32bits. Lorsque l'on lit une variable, le CPU demande à la RAM la valeur et en profite pour mettre dans la ligne de cache la RAM autour de la valeur demandée.
En C et C++, sur un tableau à deux dimensions, si on a un pointeur sur la ligne 3 et la colonne 4, un pointeur++ pour voir le mot suivant en RAM donnera la valeur de la ligne 3 colonne 5 ou dans le cas de 4 colonnes, la ligne 4 colonne 1.
En complément, pour optimiser de manière simple, on peut mettre ensemble (côte à côte) des valeurs d'une structure souvent accédée ensemble, comme ça, on a de bonne chance qu'elle soit sur la même ligne de cache et que une fois le premier champ accédé, les autres soient déjà dans le cache.
[^] # Re: Pour initier un enfant
Posté par Anthony Jaguenaud . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.
Merci, je vais jeter un coup d’œil.
[^] # Re: feature linuxfr
Posté par Anthony Jaguenaud . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 5.
Mars 2013, il y a plus d'un an… quand même, quand tu n'aimes pas, tu deviens archéologue.
Qu'est-ce qui fait que tu restes ? Le syndrome de stockholme ?
[^] # Re: feature linuxfr
Posté par Anthony Jaguenaud . En réponse à la dépêche Améliorer la disponibilité de ses services. Évalué à 2.
J'ai raté des indisponibilité du site ? ou tu fais de la désinformation gratuite ?
# Pour initier un enfant
Posté par Anthony Jaguenaud . En réponse au journal Python comme premier langage de programmation ?. Évalué à 4.
J'ai commencé à 12 ans avec du BASIC-A. Puis, Pascal, ASM, le C à la FAC, puis Clisp, prolog (est-ce un langage ?)
Pour mon fils, je me demande entre du logo, un basic, il y avait linotte ou scratch aussi. J'aime bien le principe de scratch, c'est de l'algo visuel, mais je ne suis pas certains de la pertinence de ne pas taper réellement le code, de devoir faire de l'animation, etc.
[^] # Re: Sources de la carte
Posté par Anthony Jaguenaud . En réponse au journal Le Cycle de Shaedra. Évalué à 2.
En fait, ma question est où puis-je télécharger les sources ? Où puis-je t’indiquer les modifications que je peux te proposer…
L’idéal étant du LaTeX, c’est d’avoir un dépôt git ou svn.
[^] # Re: Sources de la carte
Posté par Anthony Jaguenaud . En réponse au journal Le Cycle de Shaedra. Évalué à 2.
Il y a un accès en lecture pour la gestion de conf ? Je n'ai pas trouvé sur tuxfamlily.
[^] # Re: La version Android ne fonctionne pas sur Nexus 5
Posté par Anthony Jaguenaud . En réponse à la dépêche Ned et les maki 0.3. Évalué à 3.
Ne démarre pas non plus sur Nexus 4 :-(
Y-a-t-il des log ou quelques chose de récupérable pour vous aider ?
[^] # Re: Côté utilisateur et processus induits
Posté par Anthony Jaguenaud . En réponse à la dépêche Sortie de KDE Frameworks 5. Évalué à 7.
C'est justement un des points forts de KDE, car les process kioslave accède aux disques, mais tous les processus KDE utilisene les mêmes, ce qui donne une meilleure empreinte en RAM, etc. si tu utilises beaucoup de processus KDE.
Ce qu'il faudrait peut-être ajouter, c'est un suicide de ces process si plus personne ne les utilise depuis un certain temps (0 pouvant être acceptable). Une nouvelle feature à proposer pour KDE ?
[^] # Re: RC1
Posté par Anthony Jaguenaud . En réponse au journal Sortie de Guake 0.5.0. Évalué à 2.
Oui, c'est normal.
Est-il possible de mettre un ou deux screenshot ?
[^] # Re: Pas de conclusion hâtive
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 3.
Tu as aussi la prédiction de branchement que j'ai également observé se mettre en place.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Tu as raison sur le principe, pour éviter le padding d'une structure on ordonne les champs dans l'ordre de taille décroissante. Mais tu ne choisi pas forcément le codage d'une trame BUS que tu reçois par exemple.
Sinon, il y a une petite erreur sur ton premier exemple :
Un simple
sizeofentre une structure bien rangé et une autre est vraiment parlant. C'est utile quand la RAM peut manquer, sinon, je trouve plus clair de mettre des champs qui ont des affinités ensembles.[^] # Re: Et les nouveaux langages de programmation...
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
En effet, les patrons de fonctions été compilé localement dans chaque fichier cpp sans exporter les symbols. Du coup les binaires grossissais pas mal. Mais il y avait un hack :
[^] # Re: Mount
Posté par Anthony Jaguenaud . En réponse au message Slax ne voit pas DD externe. Évalué à 2.
Mon système graphique me détecte quand même la clé. Et la monte automatiquement.
Quand gparted, il m’affiche une partition
/dev/sdc1qui n’est pas modifiable…Voila pour info.
[^] # Re: Ready for the desktop, pas encore pour le bureau.
Posté par Anthony Jaguenaud . En réponse au journal Windows est il prêt pour le Desktop ? . Évalué à 3.
Driver latin 9, et si tu es fou
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Je n'aurais pas été jusqu'à ne garantissent rien du tout mais c'est un peu ça. Les compilateurs se comporte globalement de la même façon. Dans l'embarqué, tu connais généralement l'ensemble donc les structures sont plus esthétiques à mon sens et plus lisible. L'avantage des macros, c'est que tu n'as que l'endianess à gérer. C'est plus simple de faire du code portable. Par contre, même punition que les structure, les macro doivent être cantonnées à l'accès avec l'extérieur et recopier les données dans une structure interne propre.
Le padding dépend effectivement des deux, même si la principale contrainte vient du CPU. Sur le Power PC par exemple, il ne sait pas faire d'accès mémoire non aligné. Donc si tu force le compilo à ne pas aligner, pour chaque mot, il a 3 chances sur 4 de faire 2 accès mémoires (la deuxième en cache) plus de la recombinaison des données.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut
packedà la structure par exemple, sous visual c'est un#pragmaLà encore, c'est connue mais dépend de l'endianness… Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'
intne fait pas 32 bits.Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Qu'est-ce qui te permet de juger qu'ils ne devraient pas être en C ? Tu es sans doute un des rares à pouvoir choisir au début d'un développement qu'elle sera la complexité du logiciel au final, à choisir le langage avec le meilleurs paradigme et pour chaque paradigme, avoir une vision suffisamment clairvoyante pour analyser en avance de phase lequel des langages sera le plus adapté. Je n'en suis hélas pas capable. :'( Par défaut et comme beaucoup, je code avec ce que je connais. Je me fais des TPs pour tester de nouveaux langages (j'ai tenté haskell dernièrement), mais de là à démarrer un projet pouvant devenir gros… je préfère rester en terrain connu en connaissance de cause et sachant à l'avance les problèmes que je risque de rencontrer.
De toute façon, la langage ne fait pas l'optimisation. C'est l'algorithme qui fait ça.
[^] # Re: Mount
Posté par Anthony Jaguenaud . En réponse au message Slax ne voit pas DD externe. Évalué à 2.
Je ne crois pas. Après, je n'ai pas essayé avec gparted. Je tenterai sur une clé usb pour voir la réaction de gparted sur un disque sans table de partitions.
# Mount
Posté par Anthony Jaguenaud . En réponse au message Slax ne voit pas DD externe. Évalué à 3.
Salut,
J'ai lu les autres commentaires, le fait qu'il n'y ait pas de partition n'est pas forcément grave, même si c'est rare.
Essaye de taper :
Si mount ne retourne pas d'erreur, tu devrais trouver les fichiers dans le sous-répertoire
MonDisque.Par contre, je ne suis pas certain que tu sois en mesure de lire les fichiers car souvent se genre d'enregistreur les chiffre.
[^] # Re: La différence entre une secte et une religion ?
Posté par Anthony Jaguenaud . En réponse au journal Manu se lance dans une croisade numérique contre les terroristes intégristes musulmans. Évalué à 3.
J’ai ri : (je me suis permis de graisser un mot)
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 7.
Tu as une instruction de moins, la belle affaire si entre l'instruction deux et trois, tu dois attendre 20 cycles la valeur en RAM. Alors qu'avec tes quatre instructions, le compilateur en rajoute une cinquième à un endroit stratégique pour éviter ce temps d'attente.
En caricaturant, avec 4 instruction initialement tu utilises 5 cycles et avec tes 3 tu utilises 23 cycles… où est l'optimisation ?
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 4.
Sur un
intil n'y aura aucun 1 impact. Les compilateurs moderne se débrouille très bien pour savoir quand le faire au mieux. Il y a peu être un impact avec une copie de registre si vraiment les deux valeurs sont utiles. Mais généralement, c'est dua++dans unfor,whilesans besoin de la valeur initiale. On peut avoirb=a++mais là, le compilo va d'abord copier puis incrémenter. Pareil pour les expression du typec=a + b++où on va faire leadd regA, regB(le résultat est stocké dans regA) puisinc regB. Le seul cas que je vois c'estc=a++ + bje ne sais pas si le compilateur fait jouer la commutativité pour gagner un cycle… je ne suis pas sûr de la pertinence de se genre d'optimisation.enfin, vraiment mineur avec les compilateurs modernes. Si tu en es à gratter au cycle près, c'est qu'il y a un problème de conception générale du programme àmha. ↩
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 2. Dernière modification le 27 juin 2014 à 14:46.
Oui, en c++.
Quand tu déclares en pré-incrément, tu n'a pas de copie.
Ici, on retourne une référence sur l'objet incrémenté.
Ici, on a deux copies, ce qui peut poser un problème si l'objet est gros. C'est pour ça, notamment sur les fonctions template où tu ne présuppose pas ce que tu as comme objet qu'il vaut mieux faire des pré-incrément en c++.
Je ne sais pas si c++11 permet avec le
&&d'écrire les post-incrément mieux ?[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 7.
Oui pour les itérateurs, mais pour les pointeurs, il faut faire attention. Si tu boucles avec des pointeurs, le compilateur ne présuppose plus rien. Alors qu'avec les indices, il est capable d'optimiser aussi bien que les pointeurs, voir mieux car comme il sait où il va, il peut faire du prefetch.
Comme disais Carmack : Ne supposez pas que ça va plus vite, vérifiez-le !
[^] # Re: et avec pypy ?
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 8.
Le cache en CPU, fonctionne par ligne appelée ligne de cache. Celle-ci contient 4 ou plus mot de 32bits. Lorsque l'on lit une variable, le CPU demande à la RAM la valeur et en profite pour mettre dans la ligne de cache la RAM autour de la valeur demandée.
En C et C++, sur un tableau à deux dimensions, si on a un pointeur sur la ligne 3 et la colonne 4, un pointeur++ pour voir le mot suivant en RAM donnera la valeur de la ligne 3 colonne 5 ou dans le cas de 4 colonnes, la ligne 4 colonne 1.
En complément, pour optimiser de manière simple, on peut mettre ensemble (côte à côte) des valeurs d'une structure souvent accédée ensemble, comme ça, on a de bonne chance qu'elle soit sur la même ligne de cache et que une fois le premier champ accédé, les autres soient déjà dans le cache.