lasher a écrit 2732 commentaires

J'ai plussé, mais en même temps j'avais envie de dire « ouais, y'a le maoïsme aussi ! »

Pardon, pardon, je sors…

Je pense qu'en France, ça n'est pas forcément un amalgame : il existe bien sûr des musulmans qui ne sont pas arabes et des arabes qui ne sont pas musulmans, mais d'un point de vue "communauté" (quoi que ça puisse signifier dans un État qui ne reconnait pas les communautés), c'est globalement superposé.

La présupposition est sans doute fausse. En Algérie, la population réellement arabe ethniquement parlant, comparée à la population berbère (dont kabyles) est en réalité à peine majoritaire (il y a ~40% de berbères en Algérie, dont ~10-12% de kabyles). Au Maroc les Berbères sont 10-12 millions, soit ~30% de la population. En France, d'après Wikipedia, Les Berbères représentent 28% des immigrés d'origine algérienne, et 21,5% d'origine marocaine.

Bref, parler « d'Arabes » pour englober les populations d'Afrique du Nord est aussi maladroit que de parler de « noirs » pour parler de populations subsahariennes (même en excluant l'Afrique du Sud) : la population berbère/kabyle d'Algérie est ± aussi nombreuse que la population tunisienne dans son ensemble (qui, elle, est à 98% arabe). Mais en plus en France, cette population est au moins à 30% berbère, et donc avec une culture pas forcément si similaire…

(je rattrape mon retard de lecture de journaux sur LinuxFR, désolé :P )

J'étais vert d'envie envers mes potes au CPC et mes potes au PC1512. Par contre, un cousin avait fini par me filer une console TI99A, qui était « meilleure » qu'un MO5 ou TO7, mais qui n'avait pas de lecteur 3"½.

Perso, après avoir appris la mort de Framboisier, j'ai repris deux fois des moules.

Tu as des preuves ? Parce que Open Access, c'est juste un mode de publication où tu (le ou les auteurs) paies pour pouvoir donner accès gratuitement aux lecteurs, car tu estimes que ta recherche devrait être rendue publique¹. Bref d'un côté tu as les publications « fermées », où tu dois abandonner ton copyright et laisser l'éditeur gagner des sous en vendant des copies des actes de la conférence/du journal, ou du papier à l'unité. De l'autre tu as l'éditeur qui gagne des sous car les auteurs sont prêts à payer pour que la publication ne soit pas séquestrée derrière un « paywall ».

Le fait qu'une publication soit Open Access ou pas n'a absolument aucune incidence sur la qualité de la publication. Le fait qu'il y ait un comité de lecture est le minimum pour garantir un minimum de sérieux, mais évidemment il faut espérer qu'il n'y ait pas de copinage. Et là, il n'y a aucune garantie, sauf pour les plus grosses conférences et journaux qui ont accumulés un tel prestige qu'il serait dommageable pour leur image de publier quelque chose de médiocre. Encore une fois, je ne vois pas ce que le fait d'être Open Access ou pas change à ça.

Par contre, mon expérience en tant qu'auteur et relecteur est que (au moins dans mon domaine), il n'y a que rarement complaisance pour un papier. J'ai déjà vu un papier médiocre accepté de justesse, pas à cause de la qualité du papier (qui était fortement améliorable, même s'il y avait déjà des résultats reproductibles), mais que parce que le chef du comité de relecture pensait que le sujet était important et pas assez abordé dans le domaine (voire pas du tout). J'ai aussi vu le cas contraire : un papier qui proposait une recherche très intéressante, avec théorèmes prouvés, résultats expérimentaux, etc., mais que le chef de comité a refusé car l'article ne faisait aucun effort pour être tourné de façon à ce qu'il respecte le thème de la conférence.

Euh en maths, physique, et info c'est carrément la norme (même si souvent un modèle Word est aussi proposé). Les styles IEEE et ACM sont clairement faits pour LaTeX en premier. Je connais aussi beaucoup de thésards en économie qui utilisent LyX ou LaTeX, et je ne pense pas que ce soit rare. Tout dépend d'à quel point tu as besoin d'utiliser des formules mathématiques et des symboles bizarres je pense.

Dans l'absolu je suis d'accord avec toi. Mais au risque de répéter ce que j'ai dit il y a longtemps dans un autre journal, le problème est qu'on enseigne aux gens le langage (qu'on parle de C ou C++) avec des versions désuètes des normes :

• On m'a appris C89, même si C99 était sorti depuis pas loin de 2 ans, et surtout, les profs qui enseignaient le C à leurs étudiants dans les facs où j'ai mis les pieds ensuite continuaient à le faire en C89.
• Je doute fortement que les profs qui enseignent le C++ à la fac le fassent avec C++11/C++14 (même s'ils devraient, vu que ça simplifie énormément le code et donc réduit les risques d'erreur)
• Il y a un tas de code écrit en C++98 qui s'est accumulé, et il n'est pas dit du tout que les formes du C++1x soient acceptées dans ces projets lorsqu'on parle de maintenance : (1) il peut y avoir des restrictions sur quels compilateurs on peut utiliser, et (2) un certain style a été défini au début du projet, et pour des raisons de cohérence, on veut le garder¹.

tu sais pas ce qu'un compilo / une VM malins peuvent faire !

Mouais, c'est quelque chose que l'on entend répété ad nauseam depuis des années, mais en pratique il est rare qu'ils produisent un code plus performant qu'un premier jet bêtement codé à la main.

Chic, chic, un troll ! Donc euh, mon boulot a été, pendant un moment, d'optimiser des codes scientifiques (qui souvent sont bien plus faciles à optimiser pour un compilateur que des codes plus traditionnels). Je n'ai presque jamais eu à recourir à l'écriture en ASM, mais par contre savoir le lire était important :

1. Il fallait pouvoir reconnaître un code peu optimisé par le compilateur (alors qu'on pouvait faire mieux)
2. Il fallait quand même pouvoir écrire 2-3 trucs à la main dans certains cas précis
3. La plupart des cas où j'avais besoin de faire du fine tuning, je passais par les intrinsics de gcc/llvm/icc (par exemple, si on veut utiliser les instructions MMX/SSE/AVX sur x86/x64), ce qui était quand même 'achement plus simple pour obtenir des diagnostics d'erreur quand je me plantais.
4. La plupart du temps, le compilateur est bien plus malin que le programmeur.

Concernant mon dernier point : au final, plutôt qu'écrire en ASM, je finissais par savoir comment exprimer mes programmes sous une forme que le compilateur savait optimiser. Souvent, ça passe par la « débilisation » du code : si on essaie d'être trop intelligent, le compilateur voit un tas de code compliqué, et laisse tomber. Si au contraire on écrit le code de la façon la plus simple possible, souvent le compilo comprend l'idiome, et trouve des choses intelligentes à faire. Il y a bien entendu des exceptions :

• Si on essaie d'optimiser pour les caches, il faut souvent recourir à des techniques de « blocking » ou « tiling », mais là encore on peut s'arranger pour ne pas se mettre en travers du compilateur (par exemple, on met la partie à optimiser du code dans une fonction à part, et ainsi on l'isole du nid de boucle qui l'entoure).
• Il y a des fois où le compilateur se plante réellement dans la génération du code, mais là encore, faire de « l'assembleur en C » permet le plus souvent de le remettre dans le droit chemin.

Sur certaines architectures c'est relativement faux : par exemple sur Itanium, tout un tas de mécanismes super cool concernant la prédication des branches, la spéculation de contrôle ou de données, etc., n'étaient tout simplement pas accessible à moins de faire de l'assembleur (gcc est dans les choux niveau optim sur ia64, et icc interdit l'utilisation d'assembleur inline — mais il y a des intrinsics pour certains trucs).

Bref. J'en profite pour lier vers ce blog qui propose un quiz à propos de différentes optimisations que le compilateur peut effectuer.

Et de toutes manières, vu qu'en général on passe son temps à appeler des fonctions assez génériques qui ne sont donc pas optimisées pour le cas que l'on utilise, il n'y a pas grand chose d'optimisable par le compilateur…

Ça par contre je suis relativement d'accord. Je n'ai pas été regarder, mais j'aimerais bien savoir s'il existe des fonctions de la libc qui ont des variantes, du genre (code non testé, y'a sans doute des bugs) :

#ifdef __HAS_AVX__ 
#define memcpyAVX memcpy
#elif __HAS_SSE2__
#define memcpySSE2 memcpy
#elif //...
//...
#endif

void *memcpySSE2(void *restrict s1, const void *restrict s2, size_t n) {
    if (n < sizeof(_m128d)) { // size to copy is less than 8 chars
        char *dst = (char*) s1, *src = (char*) s2;
        while ( n-- )
            *dst++ = *src++;
    } else if ( is_aligned16(s1) && is_aligned16(s2) ) { // aligned on 16B
        _m128d src; // or _m128i with _mm_load_si128/_mm_store_si128, doesn't really matter here...
        size_t i;
        for (i = 0; i < n-8; i += 8) {
            src = _mm_load_ps ( s2 + i );
            _mm_store_ps ( s1 + i, src ); // copy, 8 chars at a time
        }
        for (; i < n; ++i)  // epilogue
            *((char*)s1+i) = *((char*)s2+i);
    } else { // unaligned accesses
        _m128d src; // or _m128i with _mm_loadu_si128/_mm_storeu_si128, doesn't really matter here...
        size_t i;
        for (i = 0; i < n-8; i += 8) {
            src = _mm_loadu_ps ( s2 + i );
            _mm_storeu_ps ( s1 + i, src ); // copy, 8 chars at a time
        }
        for (; i < n; ++i)  // epilogue
            *((char*)s1+i) = *((char*)s2+i);
    }
}

NB: avec icc (et en supposant que mon code ne soit pas complètement rempli de bugs, ce qui est très possible), les boucles vont être déroulées, entre 2 et 6 fois, pour tirer avantage des 16 registres SSE. Pour tirer avantage des cas intermédiaires, icc va générer des variantes qui vont complètement dérouler les cas du genre N=8, N=16, N=32, etc. Je ne crois pas que gcc fasse cela aussi systématiquement, mais il commence aussi à être bon pour ce qui est de la vectorisation.

Au moins ça change des annonces de la mort des *BSD. :-)

Dans mes souvenirs, en moyenne trois cinquièmes de la consommation électrique est du fait du calculateur lui-même, et le reste concerne le système de refroidissement.

Je peux comprendre que gérer des flux monétaires est complexe et demande de la rigueur, maintenant JE trouve que bloquer de l'argent sur un compte en demandant tout plein de papier est juste dégueulasse.

Pour être honnête, lorsque j'ai brièvement travaillé dans une banque il y a un bout de temps, n'importe qui demandant à déposer ou retirer plus de 50 000FF à l'époque devait prévenir à l'avance la banque (ne serait-ce que pour des raisons de sécurité), signer un formulaire en arrivant, etc.

Et une bonne raison pour laquelle on n'avait pas besoin de demander 10 000 papiers, c'était aussi qu'on demandait sa CNI au monsieur, dont on recopiait soigneusement le numéro sur le bordereau.

C'est la première fois que je le fais dans ce sens mais …

Tu torts

Mince, pour une fois, c'est un cas « tords-du ». :( Donc: « tu tords »

Oui c'est assez naïf, car de toute manière, les vraies machines utilisées pour faire exactement ce dont tu as peur ne sont généralement pas l'objet d'une telle publicité. C'est comme les machines du top500 : on parle de clusters « publics », pas de machines qui sont utilisées pour des tâches bien spécifiques (comme par exemple traverser les graphes de réseaux sociaux pour trouver les maychants terroristes).

Hum, l'agence à trois lettre qu'on ne peut nommer et qui fait partie du DoD commissionne des machines spécifiques, pour des applications spécifiques, et très souvent avec des OS spécifiques. De plus, s'il y a certes des rivalités entre départements au sein du DoD, globalement si une certaine agence décidait d'aller voir le code source de leur(s) OS, ou le contenu de certaines données, elle n'aurait qu'à demander (ou presque).

D'après l'article, il s'agit d'un choix d'OS pour un super-ordinateur. Il me semble que SUSE a toujours eu une longueur d'avance dans ce segment sur son concurrent.

Pas vraiment, non. RHEL est très souvent utilisée comme base pour des variantes HPC (Scientific Linux, mais aussi des distribs maisons de chez Bull, etc.).

Ubuntu le fait par exemple.

Oui, j'ai lu le post original après ma réponse. Et tout revient autour de la même chose : ils ne comprennent pas suffisamment le code pour garantir la sûreté du programme et sa maintenance. C'est complètement OK selon moi. Mais un code ne peut pas être « trop » optimisé, dans le sens où une optimisation qui provoque des résultats incorrects n'en est pas une, par définition.

Hum, un code « trop optimisé » ça fait bizarre. Le style je peux comprendre. Mais du moment que le code est sûr, je ne vois pas en quoi être optimisé est un mal… (je vais lire le lien histoire de voir si je suis d'accord avec ton résumé ;-)).

[…] Le langage naturel existe déjà pour cela, autant créer des outils pour apprendre facilement mais correctement.

Le langage naturel ne peut pas être analysé efficacement. :) Il est important de proposer un langage un peu formel pour habituer l'élève à raisonner et exprimer ses idées d'algo « formellement ». Le vrai code de « vie réelle » ressemble de toute façon rarement à celui montré en cours par le prof ou même à celui que les élèves produisent pour leurs projets. Pour l'apprentissage de l'algorithmique, la syntaxe importe peu, du moment qu'elle est simple et cohérente. L'intérêt d'avoir un langage précis pour l'apprentissage de l'algo, c'est que tu peux facilement prévenir des comportements déviants (plus qu'avec un « vrai » langage généraliste). En collège ou lycée, il est plus important de donner de bonnes bases que de chercher absolument à faire apprendre la programmation en utilisant de vrais outils. Mon premier contact avec un langage de programmation, c'était Logo, en primaire. Lorsque j'ai essayé d'apprendre Pascal par moi-même quelques années plus tard, autant te dire que ce n'était pas la fête. Entre les mots en anglais à retenir, la syntaxe, etc., j'ai assez vite jeté l'éponge. J'ai eu mon premier contact avec l'assembleur au lycée sur un processeur 6809, et pas sur du x86, et c'est tant mieux.

Je pense que tout dépend de ce qu'on entend par « étudiant ». Si on parle de niveau fac, je suis assez d'accord. Si on parle en-dessous, je trouve pas forcément débile de se concentrer sur l'enseignement de l'algorithmique d'abord, en oubliant « la vie réelle », puis ensuite il sera toujours temps d'apprendre les quelques mots de vocabulaire en Anglais qui sont nécessaires.

Résumé: void* est un type générique qui sert (dans un langage faiblement typé) à passer des zones mémoire d'un bout du programme à un autre. Il a été explicitement créé pour être transtypé dans un sens ou dans l'autre. Le transtypage silencieux d'un type pointeur à void* (ou le contraire) est donc logique.
En règle générale, je préfère le typage fort du C++ dès qu'on parle de manipulation un tant soit peu de haut niveau, mais dès qu'il s'agit de programmation réellement bas-niveau, je trouve que le typage force une écriture plus lourde qu'en C.

En règle générale, tout transtypage d'un type pointeur vers un type « intégral » (virgule flottante ou entier) fera que le compilateur te gueulera dessus.

Transtypage depuis void*:

void* ptr est le type générique du C. Du coup, comme tu ne peux pas écrire *ptr (qui n'a strictement aucun sens), tu sais que tu es en train de manipuler un objet qui va finir par être transtypé en quelque chose d'autre. Comme le typage est faible, alors évidemment, tu dois indiquer (dans la doc de ta fonction, dans le nom de ta variable, etc.) à quel type on se réfère (puisque le transtypage implicite fonctionne). Je trouve qu'au moins dans ce cas, on sait qu'on doit faire gaffe.

Transtypage vers void*:

Tout type « intégral » (entier ou double) lèvera un warning ou une erreur. Pour les autres, il s'agit de généraliser le type d'un pointeur, ce qui est exactement ce pour quoi void* a été créé. Gueuler contre ça, c'est (selon moi) équivalent à gueuler contre Java qui permet de transtyper un objet vers le type Object (après, nous sommes d'accord, dans l'autre sens si tu transtypes mal ça coincera en Java, alors que C te laissera faire).

De toute manière de ce que j'ai pu voir en C++, dès qu'on commence à parler de manipuler des octets et des notions bas-niveau, on retombe sur des tableaux de char exactement comme en C. Sauf qu'en plus maintenant on se traîne le typage fort de C++ lorsqu'on passe de char[] à void* etc pour effectuer certaines manipulations, ce qui alourdit le code (je trouve).

Ce que je voulais dire, c'est que le compilateur m'empêche d'obtenir mon binaire dans tous les cas. Donc il ne gueule pas contre le transtypage, mais contre une variable non utilisée (et comme j'utilise -Werror ben …). Je ne cherchais pas à dire que c'était lié. :)

True. En même temps, gcc gueule avec ton code car:

szuckerm@evans201g:~/Programming/sigsegv$ gcc -std=c99 -Wall -Wextra -pedantic -Werror -o fail fail.c
fail.c: In function ‘main’:
fail.c:6:13: error: unused variable ‘small’ [-Werror=unused-variable]
     int32_t small = big;
             ^
cc1: all warnings being treated as errors

Bon je chipote, il suffit de renvoyer small depuis main() et avec ma config gcc est content. ;-)
Le compilateur d'Intel avec les mêmes options est aussi muet que clang et gcc.

Avec clang, -Weverything m'économisera plein de frappes au clavier…

Le moment où tu fais un transtypage explicite, c'est le moment où tu dis au compilateur « ta gueule, je sais ce que je fais »

Ha ha…

Ca peut être aussi "le client veut 0 warning dans sa config du compilo, ben on va lui faire plaisir".
Bon, certes, ce n'est pas complètement contre ton "ta gueule, je sais ce que je fais", mais ça veut dire plutôt "ce que je fais est faire plaisir au client" que "ce que je fais, je connais son impact sur le code" qui est plutôt sous-entendu, me trompe-je?

En fait, oui. :) Je n'ai jamais dit que j'avais systématiquement raison lorsque je transtypais. :) Par contre, oui, si j'active tous les warnings et que je les convertis en erreur, alors je dois gérer les « unsigned compared with unsigned », les « pointer assigned to integer », etc., et donc je me dois de réfléchir sur le coup à ce que je suis en train de faire. Si c'est pas évident, c'est le bon moment de laisser une trace sous forme de commentaire pour expliquer pourquoi je dois faire un truc « contre nature » (genre uint64_t v = (uint64_t)ptr). Très souvent, les transtypages « crades » sont faits dans l'urgence, « parce que ça va plus vite », mais aussi très souvent, on peut faire un compromis en utilisant des unions, etc., ce qui force le programmeur à penser le nom des champs de l'union, à explicitement dire quelle « point de vue » d'une variable il veut utiliser, etc.

Hum, le fait que tu doives transtyper en utilisant un truc du genre (type)var c'est quand même parce qu'un compilateur C bien configuré (genre -Wall -Wextra -pedantic -Werror) va te jeter si tu transtypes n'importe comment. Le moment où tu fais un transtypage explicite, c'est le moment où tu dis au compilateur « ta gueule, je sais ce que je fais ». On te donne une corde, tu peux t'en servir pour t'empêcher de tomber du haut de la falaise, mais si tu te sers de ton cou pour t'accrocher, forcément tu vas avoir des surprises.

Après je suis bien d'accord pour dire que le typage fort du C++ et ses méthodes alternatives de transtypage sont quand même plus sûres — mais reinterpret_cast ou static_cast ne sont pas non plus la panacée.