lasher a écrit 2738 commentaires

C'est pour ça que j'ai parlé de Ferrari ailleurs : le prix est très élevé en général, et comme tu dois acheter tout le matos kivabien autour généralement pour faire un nœud, il faut avoir un réel besoin pour la version haut de gamme. Par contre comme d'autres l'ont dit, il existe des versions 6 cœurs, à genre 3 GHz, et qui n'atteignent pas les bornes des limites (mais ça restera quand même vachement plus cher qu'un Xeon en moyenne).

Il y a une grosse différence avec l'Itanium : ce dernier était génial pour du calcul flottant, et pourri pour de l'entier. Si ton appli se repose sur un systeme de gestion de bases de données, alors l'Itanium ne sert juste à rien. Le cas du POWER est différent (et d'ailleurs c'est pour ça qu'on en est à la 8è génération…).

Voilà, élude plutôt que m'expliquer en quoi tu n'es pas d'accord avec moi. En fait je suis certain que tu me prêtes des opinions que je n'ai pas, et donc t'as décidé de me foutre dans une case sans avoir au préalable vérifié que tu avais raison…

Ce que je disais à propos de l'Espagne et la Grèce dans ma note de bas de page c'est justement que l'UE ne fait pas grand chose pour aider des pays qui en ont bien besoin, là où aux USA ça ne serait pas accepté.

Disclaimer : j'aime beaucoup les processeurs Intel. :-)

Voilà ce que je sais des processeurs Intel récents :

Xeon (Ivy Bridge récent) :
* L1 data = L1 instruction = 32 Kio chaque, privés, soit 16 Kio / thread
* L2 unifié = 256 Kio, privé, soit 128 Kio / thread
* L3 unifié = ~40 Mio max (partagé par 8 cœurs/16 threads), soit ~2,5 Mio / thread.

Tous les bus L1<->L2<->L3<-> sont de 8 octets, les lignes de 64 octets. Donc la latence est de 8 cycles entre 2 modules de cache. Comme il n'y a qu'un seul port d'écriture actif à la fois, si le L1 veut écrire dans le L2, et que le L3 veut faire de même, il y aura arbitrage et on doublera la latence de L1 ou L3.

L'horloge est cadencées à 3,2 GHz (avec l'option du turbo qui réduit la fréquence de tous les cœurs sauf un, qui monte jusqu'à 4 GHz).

POWER8:
* L1 data = L1 instruction = 64 Kio chaque, privés, soit 8 Kio / thread
* L2 unifié = 512 Kio, privé, soit 64 Kio de cache L2 / thread
* L3 unifié = 96 Mio, NUCA, partagé par tout le monde, soit 1 Mio / thread
* Apparemment: possibilité d'ajouter un niveau de cache L4 off-chip (mais j'ai pas vu de vraie descriptions pour ce cas)

Le processeur devrait tourner jusqu'à 4 GHz (soit 25% plus rapide que pour un chip à 3.2 GHz), mais je ne sais pas encore comment il va gérer l'énergie et la modulation automatique de tension/fréquence.

Le bus L2<->L1 est de 64 octets, ce qui permet de transférer une ligne de cache directement en un cycle. La bande-passante est donc au moins 8 fois plus importante que son équivalent sur puce Intel (là encore, pour L1/L2).

IBM annonce 4 Tio/s en bande-passante pour le L2 en crête (sans doute lorsque le banc de L3 que tu accèdes est local au cœur), et 3 Tio/s pour le L3. J'ai jamais vu ce genre de chiffres annoncés sur les chips Intel, même en crête. Ça me permet de commencer à répondre à tes remarques. :-)

Le problème est que tes 100 threads partagent une bande passante mémoire pas si énorme. Surtout si tu compares la bande passante dispo par thread, pour 16 threads d'un cpu intel.

Si ton appli est correctement optimisée, alors il y a des chances que traiter les ~100 Mio de données dispo sur le cache occupe le processeur « un bon moment ». Du coup, ~3 Tio pour 100 threads, ça me semble parfaitement raisonnable : ~30 Gio/s en moyenne par thread. En pratique, il y aura très certainement de nombreux échanges entre le L1 et le L2 (car 8 threads en concurrence, ça va forcément créer des conflits), mais ça tombe bien, le bus L1<->L2 est de 64 octets, donc transférer une ligne devrait donner une latence tout à fait correcte.

Depuis que les SSD existent, l'avantage des solutions "pro" de stockage tombent fortement.

Hum, on parle de peta-octets de données produits chaque jour dans le cas de big data. Même avec des SSD, tu veux des I/O qui poutrent. Le problème n'est d'ailleurs pas tant de générer les données (à la limite, un « array » de SSD pourrait faire l'affaire), mais aussi de faire de l'analyse au plus tôt dessus (après tout, c'est à ça que « Big Data » se réfère : le besoin de générer plein de données, mais aussi de les traiter dans des laps de temps de plus en plus courts).

[à propos des machines du DOD] Tu parles du HPC là, non ? Basé sur plein de powerPC (100k) et non du POWER il me semble.

Oui beaucoup sont à base de PowerPC. L'une d'entre elles par exemple, est très sommairement (et vaguement incorrectement) décrite là : http://en.wikipedia.org/wiki/Cyclops64

Le chip Cyclops-64 est sorti en 2007, et était produit en 90nm, avec 160 threads et 80 unités flottantes. Aucun cache, que des scratchpads, avec un total de ~4.2MiB on chip (pour 2007, c'était pas mal du tout) qui était divisée entre SRAM partagée et scratchpad privé (configurable au boot). Un truc important : il y avait un énôÔôÔôÔôÔôÔôrme cross-bar pour la SRAM qui garantissait un modèle mémoire « séquentiellement constant » (sequential consistency de Lamport), un jeu d'instructions atomiques qui utilisaient des PiM (processing in memory), etc. Bref, un petit bijou technologique (et impossible à programmer pour des trucs génériques, il faut bien avouer : ça ressemblait plus à un truc embarqué pour du HPC qu'à une machine généraliste).

---

Mais même pour des clusters ou centres de calculs donnés, il arrive quand même que l'état US dépense pas mal pour des POWER car ils sont gonflés de partout : le bus L2 → L1 qui fait 64B (et pas 64b a priori) c'est 8 fois plus que ce que propose Intel sur ses archis type Xeon. En gros, on a limite 1 cycle = 1 ligne de cache, ce qui est quand même super pour tout ce qui est accès aléatoire. 96Mio de cache L3, c'est quatre fois plus que la plupart des processeurs Intel haut de gamme (et je te parle pas des 6×512Kio pour le L2). Leurs chiffres pour la bande passante supposent 4GHz soutenus, ce qui est complètement faisable depuis au moins le POWER6, et 3 à 4Tio pour la BP sur la puce, c'est quand même largement au-dessus de ce que propose Intel sur ses processeurs. Si en plus tu rajoutes jusqu'à 8 bancs mémoire (sur les cartes-mère Xeon que j'ai pu manipuler, c'était 4 bancs maximum), ça commence à faire vraiment pas mal. Et puis dernière chose, ils ont continué à foutre de la logique supplémentaire directement au niveau du contrôleur mémoire plutôt que d'en rajouter sur le chip, et ça, c'est très bien. Si tu rajoutes la connexion directe aux périphs PCI, ça permet réellement d'économiser en latence.

Encore une fois, c'est SUPER cher ces trucs, et IBM va plutôt tenter de vendre des licences AIX avec plutôt que de mettre Linux dessus. Mais ça reste un monstre en termes de bande-passante et « throughput ».

Si tu lis les slides que j'ai mis en lien, tu peux voir que le POWER8 permet la virtualisation, etc. Et comme ils ont une quantité impressionnante de cache sur le chip et la carte-mère, il y a un potentiel pour permettre à des applications qui nécessitent de traiter de gros volumes de données efficacement de traiter ces dernières encore plus vite. Ça ne veut pas dire que tu ne peux pas créer un machin cloud-esque (au contraire, si tu as un petit cluster/data center basé sur ce genre de processeurs, tu peux mettre dans un tout petit espace tout plein de cœurs/threads qui accèdent en parallèle à tout plein d'I/O. Ce genre de machine peut parfaitement servir de colonne vertébrale à un truc plus hétérogène avec des machines moins chères et qui se remplacent plus facilement.

Enfin, tu oublies qu'il existe tout un tas de services qui nécessitent une haute performance que les solutions de virtualisation à base de réseau distribué ne comblent pas, et dont la disponibilité se mesure en nombre de minutes de pannes par an. Lorsqu'on en est à vouloir ce genre de choses, on ne lésine pas sur le hard : de toute manière les ingés et le soft qui va avec coûtera bien plus cher.

Note bien : il est clair que ce genre de processeur est principalement fait pour des machines très haut de gamme. Ce que les gens ont tendance à oublier, c'est qu'au département de la défense US, IBM a de gros contrats, et qu'elle les mérite (certaines machines/certains processeurs sont conçus uniquement pour le DOD par IBM par ex).

Bon en fait quand même, c'est un peu plus compliqué que ça. Le POWER8 est un processeur « high-end » : il n'est destiné qu'à de gros serveurs, car c'est une puce qui chauffe beaucoup (comme ses grandes sœurs). D'après cette présentation, IBM réutilise le SMT ce qui leur permet de clamer une capacité de « 8 dispatch » par cœur. Si en plus on rajoute la mémoire transactionnelle gérée en hard (depuis le POWER7 je crois bien), comme maintenant les mémoires transactionnelles sont gérées dans gcc, si jamais le code en tire parti, il y a de fortes possibilités d'accélération dans les codes parallèles et concurrents (si les régions critiques protégées par les mémoires transactionnelles ne présentent pas trop de contention, alors les programmes multithreadés tourneront à plein pot.

Sérieusement, ce processeur est une Ferrari à bien des égards, et si la charge est réellement importante, ça peut parfaitement être justifié : 6 à 12 cœurs par processeur, 8 threads hardware par cœur, ça fait presque 100 threads sur le processeur, ce qui est pas mal du tout, si la charge de travail s'y prête !

… Par contre, c'est pas donné : c'est comme n'importe quel truc très haut de gamme, il faut acheter le tout : processeur, mais aussi RAM, stockage, réseau, etc., sinon ça ne sert pas à grand chose. Il y a pas mal de machines pour la haute-performance qui utilisent ce genre de choses, car généralement ces processeurs sont plutôt très fiables.

Salut,

En plus des commentaires que les gens t'ont donné, j'en rajoute une couche. :-)

1. Si tu utilises gcc ou clang, je te conseille fortement l'utilisation de ces options de compilation sur la ligne de commande : -Wall -Wextra -pedantic -Werror. Si tu apprends sous Windows, Visual C++ peut aussi se régler avec un niveau d'avertissement maximal. Pour les projets qu'on donne aux élèves en fac/IUT/école d'ingé, il y n'y a jamais de bonne raison de laisser un warning/avertissement du compilateur traîner. Dans la vraie vie non plus d'ailleurs, m'enfin parfois on a pas le choix…
2. scanf retourne une valeur qui peut-être utilisée pour savoir s'il y a eu une erreur de lecture. J'avais oublié de rentrer la taille du tableau avant de lire les nombres, et du coup scanf a gobé mon "10.4" goulûment sans sourciller. Et du coup il a évidemment tronqué l'entrée dans stdin.
3. scanf est la fonction du diable, tellement que des gens dédient des pages complètes à son sujet. Je suppose que tes profs te demandent de l'utiliser, mais je te conseille fortement d'utiliser fgets et strtol à la place (je donne un exemple en bas).
4. sscanf, fscanf, etc., sont « sûres » en supposant que les entrées soient déjà formatées comme il faut (hint: en C il ne faut jamais assumer quoi que ce soit sauf si on maîtrise la chaîne complète de production/consommation — et encore, même ainsi il faut rester vigilant).
5. Tu imbriques une boucle for dans une autre boucle for, ce qui fait que tu mélanges les valeurs pour la variable i.
6. Je te conseille fortement d'utiliser C99. Si ton prof dit que c'est pas autorisé, je te conseille de quand même insister, car la norme C99 a 15 ans, et il serait temps que les profs se mettent à jour (je ne parle même pas de C11).
7. Même si tu dois rester sur du C89 (celui qui est généralement enseigné), il y a plein de façons de rendre ton code plus lisible et plus facile à déboguer.
8. Utiliser la notation « pointeur » comme tu le fais n'est pas incorrecte, mais comme tu accèdes très clairement à ptr comme à un tableau, la notation indicée me semble plus indiquée.

Voici une version utilisant la notation C89 pour déclarer les variables au plus près de leur utilisation dans le code. Je n'ai pas touché à la logique du code lui-même, sauf pour la boucle imbriquée pour pouvoir lui donner un indice différent de i (qui est un bug hein !). J'ai aussi transformé les accès « pointeur » en accès « tableau » pour que ce soit plus lisible :

/* Version pure C89 -- Attention, tous les bugs sont restés ! */
#include <stdio.h>
#include <stdlib.h>

float Trie_selection(double *ptr, int Taille)
{
    int i;
    double *tab = malloc(Taille*sizeof(double));;
    if (tab==NULL)
    {
        printf(" erreur d'allocation\n");
        return EXIT_FAILURE;
    }
    for (i = 0;i< Taille-1;i++)
    {
        int max = i;
        int j, ii;
        for (j=i+1;j<Taille;j++)
        {
            if (ptr[max] < ptr[j])
            {
                double tm = ptr[i];
                ptr[i]    = ptr[max];
                ptr[max]  = tm;
                max=j;
            }

        }
        for (ii=0;ii<Taille;ii++)
        {
            printf("tab[%d]=%f\n",ii+1,ptr[ii]);
        }
    }
}

int main()
{
    int i,N;
    double *tab;
    printf("taille du tableau :\n");
    scanf("%d",&N);
    tab=malloc(N*sizeof(double));
    if (tab==NULL)
    {
        printf(" erreur d'allocation\n");
        return(EXIT_FAILURE);
    }
    for (i=0;i<N;i++)
    {
        printf(" tab[%d]:",i);
        scanf("%f",tab+i);
    }
    printf("tableau non trie\n");
    for (i=0;i<N;i++)
    {
        printf("tab[%d]:%f\n",i,tab[i]);
    }
    printf("tableau trie\n");
    Trie_selection(&tab,N);
    free(tab);
    return 0;
}

Voici le même code, version C99 :

/* Version C99 -- Attention, les bugs ne sont TOUJOURS PAS corrigés ! */

#include <stdio.h>
#include <stdlib.h>

float Trie_selection(double *ptr, int Taille)
{
    double *tab = malloc(Taille*sizeof(double));;
    if (tab==NULL)
    {
        printf(" erreur d'allocation\n");
        return EXIT_FAILURE;
    }
    for (int i = 0;i< Taille-1;i++)
    {
        int max = i;
        for (int j=i+1;j<Taille;j++)
        {
            if (ptr[max] < ptr[j])
            {
                double tm = ptr[i];
                ptr[i]    = ptr[max];
                ptr[max]  = tm;
                max=j;
            }

        }
        for (int i=0;i<Taille;i++)
        {
            printf("tab[%d]=%f\n",i+1,ptr[i]);
        }
    }
}

int main()
{
    printf("taille du tableau :\n");
    int N; scanf("%d",&N);
    double* tab=malloc(N*sizeof(double));
    if (tab==NULL)
    {
        printf(" erreur d'allocation\n");
        return(EXIT_FAILURE);
    }
    for (int i=0;i<N;i++)
    {
        printf(" tab[%d]:",i);
        scanf("%f",tab+i);
    }
    printf("tableau non trie\n");
    for (int i=0;i<N;i++)
    {
        printf("tab[%d]:%f\n",i,tab[i]);
    }
    printf("tableau trie\n");
    Trie_selection(&tab,N);
    free(tab);
    return 0;
}

Enfin, en utilisant les options que je préconise au-dessus, je me fais engueuler par gcc :

$ gcc -std=c99 -Wall -Werror -Wextra -pedantic -o tri99 tri99.c 
tri99.c: In function ‘main’:
tri99.c:46:9: error: format ‘%f’ expects argument of type ‘float *’, but argument 2 has type ‘double *’ [-Werror=format=]
         scanf("%f",tab+i);
         ^
tri99.c:54:5: error: passing argument 1 of ‘Trie_selection’ from incompatible pointer type [-Werror]
     Trie_selection(&tab,N);
     ^
tri99.c:4:7: note: expected ‘double *’ but argument is of type ‘double **’
 float Trie_selection(double *ptr, int Taille)
       ^
tri99.c: In function ‘Trie_selection’:
tri99.c:31:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

En regardant chaque erreur sortie par le compilateur, je peux réparer une bonne partie de tes bugs (je garde la forme C99) :

#include <stdio.h>
#include <stdlib.h>

void Trie_selection(double *ptr, int Taille)
{
    double *tab = malloc(Taille*sizeof(double));;
    if (tab==NULL)
    {
        printf(" erreur d'allocation\n");
        exit(EXIT_FAILURE);
    }
    for (int i = 0;i< Taille-1;i++)
    {
        int max = i;
        for (int j=i+1;j<Taille;j++)
        {
            if (ptr[max] < ptr[j])
            {
                double tm = ptr[i];
                ptr[i]    = ptr[max];
                ptr[max]  = tm;
                max=j;
            }

        }
        for (int i=0;i<Taille;i++)
        {
            printf("tab[%d]=%f\n",i+1,ptr[i]);
        }
    }
}

int main()
{
    printf("taille du tableau :\n");
    int N; scanf("%d",&N);
    double* tab=malloc(N*sizeof(double));
    if (tab==NULL)
    {
        printf(" erreur d'allocation\n");
        return(EXIT_FAILURE);
    }
    for (int i=0;i<N;i++)
    {
        printf(" tab[%d]:",i);
        scanf("%lf",tab+i);
    }
    printf("tableau non trie\n");
    for (int i=0;i<N;i++)
    {
        printf("tab[%d]:%f\n",i,tab[i]);
    }
    printf("tableau trie\n");
    Trie_selection(tab,N);
    free(tab);
    return 0;
}

J'ai remplacé le retour de ta fonction de tri par void (vu que tu ne retournes pas de valeur et que gcc se plaint). Du coup, j'utilise la fonction exit dans ta fonction de tri au lieu du return EXIT_FAILURE. J'ai enlevé le & devant tab dans ton main puisque le compilateur nous dit qu'on passe double ** alors que la fonction de tri prend un double *. J'ai changé %f pour %lf aussi.

Malgré tout ça, il y a de sérieux problèmes de logique liés à l'algorithmique.

Je te réponds de nouveau, et autant utiliser %f dans printf visiblement ça marche, autant pour scanf pas du tout et tu as raison, il faut %lf.

Euh, si en fait c'est clairement utilisé aussi.

Il faudrait que tu changes tes "%f" en "%lf" car tu utilises des double et pas des float.

Nope, %f fonctionne pour float et double (en fait %f prend implicitement un double).

Tu as raison pour le reste, et même non seulement tab est inutilisé dans Trie_selection, mais en plus il n'est libéré.

Je me demande aussi pourquoi jhonbouda utilise la notation pointeur *(ptr+deplacement) plutôt que la notation tableau ptr[deplacement].

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…)