lasher a écrit 2753 commentaires

Tu m'expliques le rapport ?

La différence avec la France étant que le prix d'un train équivalent au Corail ici serait pour un TGV en France. Donc au moins avec le TGV tu te tapes 1h de train pour aller à Lille. Ici, 2h30 alors qu'en train rapide en 1h ce serait plié…

Bon par contre, même la 2è classe est super spacieuse avec wifi etc. (mes souvenirs de 2è classe dans un TGV étaient que t'étais quand même à l'étroit).

Hum, si les rares personnes qui font la critique de JV sous Linux se permettent non seulement de critiquer le jeu (en soi, c'est leur boulot, et pointer les erreurs en fait partie), mais aussi insulter les gens qui les font, et que c'est systématique, alors oui, je comprends qu'à la fin on jette l'éponge. Surtout si personne ne vient contrebalancer ça pour défendre la personne injuriée.

Dire que c'est « pour si peu », c'est réellement manquer d'empathie. On ne parle pas d'un cas isolé, mais d'invectives systématiques si j'ai bien compris. Si tous les matins, à chaque fois que tu allais au boulot, quelqu'un dans la rue, derrière un vitre pare-balles te disait « Connard ! » au moment où tu rentre au bureau, et qu'en en sortant, un autre (lui aussi protégé derrière un écran^Wune vitre pare-balles) te disait « enculé¹ ! » et en revenant de déjeuner, l'un des deux, ou même un troisième continuait ainsi, comment réagirais-tu ? La défense du « pour si peu » ne tient que si l'insulte est ponctuelle. C'est celle qui souvent est utilisée par les gens qui font une remarque sexiste ou raciste pour dire « non mais on rigole, un peu d'humour, quoi ! » ou bien quand une femme dit qu'elle est constamment harcelée dans la rue qu'elle exagère sans doute (même quand elle nous montre une série de vidéos qui montrent qu'elle abordée dans la rue), etc.

Notes bien que je ne blames pas le compilo hein, c'est gdb et les IDEs qui l'utilisent qui sont le probleme de mon point de vue.

Je comprends bien. Apparemment, le compilo d'Intel (idb) ne fait rien pour OpenMP. Celui de SunOracle permet d'insérer un break point à l'entrée d'une région parallèle, mais sans réellement permettre de décider quel thread on veut surveiller (le premier thread arrivé est celui qu'on surveille), du coup je trouve ça assez limité aussi… Du coup le manuel propose plutôt d'utiliser les stack traces (voir ici par ex). XL/C (le compilo d'IBM) ne semble pas avoir de support du tout, etc.

[À propos des USA] C'est juste qu'ils ont une énorme résistance au changement

Ça m'a fait sourire, étant donné la franche résistance au changement en France concernant tellement de sujets (culture, tout ce qui a trait au numérique en fait, etc.).

(c'est culturel, aux USA, on prend son pickup pour aller chercher son burger à 100m, on ne marche pas au supermarché, on utilise un chariot motorisé etc.).

Ça c'est un cliché. Tout dépend vraiment de l'état et même de la ville où l'on vit. Si on parle de l'état de Washington par exemple : à Seattle, il y a un support système de transport public (bus, métro, taxis, etc.), alors qu'à 3h de voiture de là, dans ce qu'on appelle la région des Tri-Cities, passer d'un coffee shop à un autre nécessite de voyager 10 minutes… en voiture.

De la même manière : là où je vis (une ville universitaire dont la moitié de la population est estudiantine), plein de gens utilisent leur vélo pour aller acheter des trucs au supermarché. Par contre, le faire à pied demande une certaine volonté : presque tout est à 25-30 minutes à pied. Et comme les transports en public sont pourris, on est très vite obligé de passer par la voiture si on veut une certaine indépendance. Par contre, on peut prendre un bus pour quelques dollars (10$ en moyenne) pour aller à New York (~2h30 de transport), Philadelphie (~1h de transport), Washington DC (~2h30), etc. Le train étant cher, ça reste un luxe.

Pas que. Malheureusement des trucs genre 7/8 de pouce pour des longueur de vis etc., ça existe toujours (domaine info/électronique/etc.). Ça fait rager presque tous mes collègues/potes qui sont habitués à un système cohérent. Je ne parle pas des trucs pour la cuisine (pas de notion de litre avec des préfixes normés, non non, on va utiliser des trucs genre « cup », onces, livre, etc., qui n'ont aucune cohérence entre elles).

De manière tout à fait symétrique, t’entendra souvent un américain parler de “L’Europe”. Une fois que t’a compris ça, t’as tout compris.

Ils sont pas plus capable de placer les États européens sur une carte que nous autres de placer leurs États sur une carte.

Comme si c'était propre aux Américains. Tu sais placer les différents états sur la carte Suisse ? Tu sais placer les états au bon endroit dans les Balkans ? Au Moyen-Orient ? Aux USA ? Si oui, tu es bon en géographie. Je sais que moi, je peux pas. J'ai toujours été une tanche en géo, et depuis que je vis aux USA, ma géographie s'est améliorée (ça aide de voyager pas mal), mais je suis toujours plutôt approximatif (à base de « côte ouest / côte est / midwest »).

Oui, oui. Je sais surtout que vous venez de maladroitement comparerplaquer le concept de nation française à celui de la nation américaine.

Oui. Car il y a autant de différences culturelles entre un californien vivant à San Francisco et un habitant du Tennessee vivant à Nashville, qu'entre un Parisien et un Lillois : suffisamment pour bien voir de quelle région géographique chacun vient, mais pas assez pour se dire qu'ils vivent dans un pays différent.

Y’a un truc que vous avez pas pigé dans l’histoire, c’est que les USA sont bien plus décentralisés que ne l’est l’UE.

Je n'ai jamais dit le contraire. En fait, avec le territoire qu'ils se paient, c'est un peu normal, non ? Et que dire du Canada alors ? Ils ont ~35 millions d'habitant pour un territoire énorme, et ça reste une sorte de fédération de provinces (donc une sorte d'état fédéral). Et en fait, je ne vois pas vraiment ce que le degré de décentralisation change. En France, nous avons les régions, les départements, les cantons, etc., et de plus en plus on nous bassine avec l'autonomie des régions qui doivent avoir leur budget propre (je me sens incompétent pour savoir si la décentralisation en question serait une bonne ou mauvaise chose).

De plus, contrairement à l'UE, le Canada, comme les USA, ont un président/premier ministre/bla qui décide non seulement économiquement, mais aussi politiquement la direction à prendre pour le pays.

Pour en revenir au contexte économique : que je sache, lorsque je paye mes impôts en France, je ne paie que pour la France. Que cette dernière décide ensuite de contribuer au pot commun de l'UE, c'est un autre problème. Aux USA, je paye mes impôts au niveau fédéral et au niveau de l'état (la plus grosse majorité va à l'état fédéral d'ailleurs). Comme le soulignait Zenitram ailleurs, l'UE n'a pas de monnaie unique contrairement aux vrais états fédéraux. Du coup s'il est utile de considérer le PIB de l'UE en tant que « coalition » de nations, et du poids potentiel qu'elles peuvent avoir sur l'économie mondiale, je pense qu'il est parfaitement normal de vouloir comparer le PIB de la France et des USA ou de l'Allemagne et des USA au cas par cas et considérer que la comparaison est juste. On peut bien entendu toujours considérer le PIB d'un état US avec celui de la France (par exemple Californie vs. France), mais justement, ce serait complètement biaisé : 30% du PIB US est apporté par trois états (Californie, Texas, New York). Les 30% suivants sont complétés par les ~10 états suivants. Bref, 60% du PIB des USA est apporté par ⅓ de ses états. Un peu comme en France il y a 1/6 de la population qui vit en région parisienne (avec un PIB qui va avec) et très peu de PIB est issu de la Creuse en comparaison. Il n'est pas logique de vouloir séparer la Creuse de l'Ile de France, car malgré la différence économique évidente, l'état fédéral, grâce à l'impôt, garantit que malgré tout une partie non-négligeable de la richesse produite par ces états arrive bien jusqu'aux citoyens des états moins favorisés¹.

Oui enfin ça, c'est pas un bon argument. Il n'y a pas de langue officielle aux USA, et si l'Anglais est la langue officielle de fait, il est déjà prévu que les populations d'origine sud-américaine et qui parlent donc en majorité l'Espagnol vont être l'une des plus fortes minorités (alors que les citoyens de type caucasien ne sont plus en majorité absolue) — je crois que c'est prévu pour l'horizon 2030. Bref, l'argument de la langue est relativement faible selon moi.

C'est bien sympa que gcc soit a la pointe avec openmp, mais si c'est impossible a utiliser car impossible a debugger, ca sert a rien… :/

En même temps, à ma connaissance, le compilo d'Intel ne fait pas mieux, et idem pour la plupart des concurrents Quelque part j'ai envie de dire « C'est bien beau de fournir un env. de debugging pour OpenMP 2.0, mais on n'est plus en 2004. » :-P

De plus, les gens qui bossent sur des applis avec plusieurs centaines ou milliers de threads OpenMP n'utilisent pas de debuggers parce que trop compliqué (à moins de te faire pousser quelques dizaines d'yeux, comment tu fais pour surveiller les cas chiants du type data race ?). Du coup la plupart des gens qui bossent sur des applis massivement multithreadées passent par des trucs du genre omp barrier ou omp taskwait + printf. En règle générale, dans le monde du HPC, il y a peu voire pas de vraie solution de debug pour le parallélisme massif. Et la réponse des gens à ce problème est en gros « utilise un langage qui limite les possibilités de data race, genre DSL, langages fonctionnels, ou quasi-fonctionnels (i.e. multi-paradigmes) ».

Pour ce genre d'applications (HPC), le debugger « idéal » serait sans doute un truc qui permet d'enregistrer une trace sur N cycles ou secondes, puis qui permette de « rejouer » la séquence et d'analyser les valeurs. Le problème est la taille de la trace résultante, et surtout les heisenbugs : même comme ça tu risques d'avoir des soucis pour trouver le bug en question.

Note que j'aime beaucoup le debugger de MSVC++, juste que le manque de fonctionnalités du compilo en fait quelque chose de pas très intéressant pour faire du dév OpenMP un peu poussé (il y a tout un tas d'applis de simulation numériques qui tirent fortement partie des tasks OpenMP pour la traversées de structures de graphe ou tableaux « creux »).

Les États-Unis d'Amérique sont un état fédéral. La Suisse, l'Allemagne sont des états fédéraux, et donc leur économie est considérée en tant que tout. L'UE n'est pas un état fédéral, mais un ensemble de nations avec un marché commun. C'est différent, et tu le sais.

Moui enfin, OpenMP est dans MVC++ mais seulement en v2.0, alors qu'on est passé à v2.5 puis 3.0, puis 3.1. Et tous les compilos — Intel cc, gcc, Sun cc, etc., implémentent le standard¹. Est-ce que MSVC++ permet de débugger les threads OpenMP ? (là encore, vraie question)

OpenMP c'est différent : ils utilisent un système de user threads au-dessus des pthreads. Du coup à moins de patcher gdb pour avoir les bons hooks vers les threads omp, tu pourras pas faire grand chose. Un de mes collègues au CEA avait pris un stagiaire juste pour rajouter les bons outils de debug dans gdb pour sa bibliothèque de threads mixtes (pthreads+user threads). Ça marchait très bien ensuite.

À ce sujet, je me posais la question de la meilleure façon d'implémenter une liste chaînée en C, et du coup je me disais que comme ça ça pourrait le faire :

#define cons(x,y) (struct llist[]){{x,y}}
struct llist *lst=cons(a1, cons(a2, co...ns(aN,NULL) ... )); // avec a1, a2, ..., aN, créés statiquement

Vous en pensez quoi ? :P

Pour les asserts qui doivent toujours échouer, tu ne peux pas bêtement faire ça ?

void une_fonction(...) {
  assert("MON MESSAGE D'ERREUR" && 0);
  /* Reste du code si besoin */
}

Est-ce que c'est aussi vrai pour debugger des programmes multithreadés ? (c'est une vraie question, mon expérience sous unix est que de toute manière comme j'écris mes propres bibliothèques de threads au-dessus des PThreads, je me retrouve à avoir des outils pour faire des traces, et je n'utilise que rarement la capacité de gdb à suivre les PThreads…)

À chaque fois que tu écris « saloperie de réalité » (ou une de ses variantes), tu décrédibilises l'intégralité de ton message, même quand il y a des bouts qui sont pertinents dedans. Genre le message auquel je réponds.

C'est quand la dernière fois que t'as eu une carte Ethernet qui ne fonctionnait pas directement (même en mode dégradé, genre mode compatibilité NE2000) sous Windows > XP?

Bon, j'admets c'est très anecdotique, mais nous avons des imprimantes HP laser monochrome au boulot, et si je télécharge le driver pour Windows ou Mac (parce que pour le coup, Windows ET OS X sont à l'ouest pour ce modèle d'imprimante spécifique), alors je suis forcé de manuellement appuyer sur le bouton de validation de l'imprimante pour la faire changer de bac de chargement. Sous Linux, le driver est dispo out-of-the-box (au moins sous Ubuntu), et je peux spécifier quel bac utiliser par défaut. Le driver officiel d'HP ne me le permet pas.

Ceci étant dit, je suis d'accord pour dire que depuis Windows Vista (en gros), la recherche et l'installation automatique de drivers est quand même globalement simple. Juste que, lorsque je mets une clef USB sur le PC, ou bien que je mets un dispositif Bluetooth pour avoir un pointeur/changeur de slides, j'aimerais que Windows ne mette pas 3 plombes à « chercher un driver » (c'est une putain de clef USB, de quel driver Windows a-t-il besoin ?)

Le compilateur d'Intel en -O2 déroule 2 à 8 fois automatiquement la plupart des boucles qu'il rencontre (sauf si le nombre d'instructions dépasse les limites, cas d'exception). Je n'ai pas vérifié pour le compilateur GNU, mais avec -O3 il y a des chances qu'il fasse pareil.

Tu « triches » dans le sens où tu mets le corps du while sur la même ligne. :) J'aurais pu faire pareil avec mon corps vide dans le for.

Ensuite, utiliser n /= 2 dans la post-condition n'est absolument pas un détournement, car il s'agit bien d'une façon d'itérer sur la boucle. Par exemple, écrire un truc comme ceci (en supposant une liste chaînée) :

link_t*
find(list_t* list, const void* data)
{
    link_t* cur = NULL;
    for (cur = list->head; cur != NULL && list->cmp(cur->data,data) != 0; cur = cur->next)
        ;
    return cur;
}

est parfaitement idiomatique, et clair. Tu pourrais bien sûr écrire quelque chose du genre :

link_t*
find(list_t* list, const void* data)
{
    for (link_t *cur = list->head; cur != NULL; cur = cur->next)
        if (list->cmp(cur->data,data) == 0) 
            return cur;

    return NULL;
}

Et ce serait (peut-être) plus clair pour un nouveau venu dans le monde du C, mais à mon avis ni plus ni moins pour quelqu'un qui connaît « raisonnablement bien » le langage (c'est-à-dire qui a plus de 6 mois d'expérience avec).

Utiliser une connaissance en maths, physique, …, bref une connaissance du domaine auquel s'applique la fonction qu'on écrit pour optimiser/simplifier le code, oui, c'est astucieux. Perso, je n'aurais jamais pensé au coup du n & (n-1). Il faut accepter le fait que l'informatique est l'enfant des maths et de l'électronique, et donc que tout « truc et astuce » tombera souvent dans un domaine ou l'autre. Et de temps en temps, utiliser les propriétés du langage utilisé sera une utilisation astucieuse du langage, et donc sera une « astuce de programmation ».

En résumé : si à chaque fois que quelqu'un utilise une astuce pour simplifier/optimiser du code, on contre en disant « mais c'est pas de l'info, c'est des maths », alors on peut dire la même chose de 90% des « astuces » utilisées dans les autres domaines (mécanique, électronique, etc.), car après tout, toute modèle passant par une science « dure » est exprimé en termes mathématiques…

Une astuce c'est un truc qui peut casser dès qu'on met à jour le compilateur et/ou le runtime ou dès qu'on change d'environnement.

Non. Par exemple si je veux savoir si un nombre est une puissance de 2, je peux écrire

_Bool
is_power_of_2_naive(unsigned long n)
{
    unsigned long remainder = 0;
    while (!remainder) {
        remainder  = n % 2;
        n         /= 2;
    }
    return remainder == 1 && n == 0;
}

Ça marche, c'est assez direct, et au pire j'aurai itérations (puisque je divise par 2 à chaque itération).

On peut quand même simplifier :

_Bool
is_power_of_2_naive(unsigned long n)
{
    if (n == 0) return false;
    while (n%2 == 0) 
        n /= 2;
    return n == 1;
}

On peut même rendre l'écriture plus compacte :

_Bool
is_power_of_2_naive(unsigned long n)
{
    if (n == 0)  return false;
    for (; n%2 == 0; n /= 2) 
        ;
    return n == 1;
}

Mais bon jusque là, « l'astuce » c'est juste connaître le langage, et savoir exprimer la même chose de différentes façon. Il s'agit donc purement de style.

Mais je peux être réellement astucieux, et répondre en temps constant :

_Bool
is_power_of_2(unsigned long n)
{
    return (n > 0) && ((n & (n-1)) == 0);
}

Un entier non-signé ne changera jamais ses propriétés, donc j'ai la garantie que ce code fonctionnera toujours en C/C++ (et en fait n'importe quel langage qui permet les opérations bit-à-bit sur des entiers).

J'ai oublié de répondre à ça : si le bouquin/poly/bla est meilleur que le prof, et qu'on parle bien d'un amphi, alors aller en cours ne sert à rien, et les étudiants ne devraient juste pas y aller. J'ai fait ça pour certains profs qui clairement ne savaient pas bien enseigner, et dont le poly était bien meilleur que le cours magistral. En fac, il n'y a aucune obligation d'assister aux cours, sauf TP et examens. Je veux bien croire qu'en première année on reste « scolaire » et qu'on aille à tous les cours parce qu'on vient du lycée, mais dès la deuxième année, je m'attends à ce que les étudiants qui estiment qu'il perdent leur temps (y compris en TD) ne viennent pas. Ce sont des adultes, on les traite comme tels.

Mince, je ma mémoire me joue des tours. :(
Bon ben, pan sur le bec alors.

"Si à cinquante ans, on n'a pas une Rolex, on a quand même raté sa vie."

Je ne sais pas pour les autres citations, mais celle de la Rolex a été complètement détournée. Si tu trouves la vidéo de l'interview initiale (ou une retranscription), tu verras que cette phrase est utilisée dans un contexte ironique.