lasher a écrit 2753 commentaires

Ça fait partie du shtick de stand up. Et je suis sûr que ça lui permet d'occuper ses mains en même temps.

Location Consistency, un truc qui est principalement de la recherche.

Hum, depuis au moins le Core 2, les CPU Intel sont capables d'effectuer une addition double précision SIMD et une multiplication double précision SIMD en parallèle et en un cycle. Donc 4 FLOP/cycle.

Lorsque tu transfères une ligne d'un niveau à un autre, cette dernière ne peut être utilisée que si l'intégralité de la ligne a été transférée. Une ligne de cache sur x86 fait 64 bytes. Le bus a une largeur de 8 bytes. Donc pour transférer 64 bytes, il faut 8 transferts au total. Si Nicolas a raison et qu'il existe plusieurs ports d'écriture et plusieurs ports de lecture (en tout cas sur les Nehalem ça ne semblait pas vrai du tout quand j'avais fait mes benchs), alors la latence et la bande-passante peuvent avoir sérieusement augmenté¹. Donc pour résumer : au moins pour les micro-archis Nehalem et SandyBridge, à ma connaissance il n'y a qu'un seul port de lecture et un seul d'écriture utilisables pour les L1 et L2 (qui sont privés). Le L3, ça dépend du modèle. Par exemple sur les Nehalem EP, c'est pareil que pour les L1/L2, mais pour les Nehalem EX, ils utilisent un cache de type NUCA, avec un bus segmenté qui peut allonger la latence jusqu'à 8 cycles, mais augmente la bande passante de façon significative par rapport aux EP.

Au passage, les 32 bytes/cycle annoncés sont expliqués dans le papier que je référence plus bas : sur les archis Intel, il y a 5 ou 6 ports : 1 port pour l'ALU, 1 port pour le × flottant, un pour le + flottant, un pour les loads, et un pour les stores (parfois certaines archis on 2 ALU, mais pour l'architecture Nehalem je crois pas). Si tu émets un store et un load « en même temps » en utilisant les SSE, alors tu as effectivement bougé 32 bytes depuis les registres vers le L1. Par contre, je renvoie à la figure 4 du papier mis en note : s'il faut aller chercher la ligne de cache jusqu'en L3, alors ça peut prendre jusqu'à 14 ou 20 cycles (latence).

Si la "bande passante" est de 64Bytes/cycle, j'imagine que le bus fait 64Bytes, non ?

Non. Si tu charges une ligne depuis la RAM jusqu'au L1, puis jusque dans un registre, alors tu vas payer la latence au prix fort. Par contre, si tu effectues des opérations arithmétiques avec les données accédées, tu vas bénéficier des effets de cache (temporalité : tu réutilises les mêmes adresses mémoire; et localité : tu n'as pas besoin d'aller chercher les mots « voisins » du mot que tu avais initialement chargé). Comme en plus il existe des prefetchers extrêmement efficaces sur archi x86 (si tu as un cache miss, alors la ligne de cache suivant celle que tu veux est automatiquement préchargée; sur Intel, il y a un pattern matcher d'adresses, et tant que ça reste dans une page physique, le prefetcher va reconnaître le pas de déplacement et précharger automatiquement les lignes qui correspondent), tu n'as généralement pas trop à t'inquiéter de payer la latence à chaque fois : tu vas juste payer le prix fort de temps en temps.

J'oubliais :

Effectivement si les données sont organisées selon un layout arrays-of-structures plutôt que structure-of-arrays, l'auto-vectorisation ne fonctionne pas actuellement (dans gcc au moins). À quand des compilateurs qui modifient automatiquement le layout mémoire ?

Jamais avec C ou C++, car le standard l'interdit (quoi que avec C11 ou C99 il y a moyen de déclarer un champ de type char field[]; qui pourra être précisé plus tard si je me souviens bien).

En règle générale, tu peux passer par un outil de transformation de code qui fera du source-to-source, mais un compilateur qui obéit à la norme du C ou du C++ ne pourra sans doute jamais optimiser la disposition des champs dans une structure car cela irait contre la norme (et surtout ce ne serait pas portable—par exemple si tu as 2 machines différentes qui communiquent via le réseau, et qui doivent s'envoyer des bouts de tableau/structure).

À noter que aussi chez Intel que chez IBM, il y a de la recherche faite sur des « memory ISA », c'est-à-dire un jeu d'instruction pour gérer les motifs d'accès à la mémoire (genre accès « 2D », accès « stridé », etc.). C'est pas près de sortir, mais ça avance doucement…

Je regarde juste les chiffres de vente d'Intel et d'IBM. Certes IBM joue sur sa marque, ça fait plaisir à du monde, mais c'est tout.

Sérieusement, je pense simplement que tu ne traites pas avec les services de (grosses) boites qui ont réellement besoin de ce genre de machines. Pas simplement dans le HPC (qui est réellement un monde à part, même si les petits clusters ont tendance à apparaître un peu partout), mais aussi pour certains traitements de données en quasi-temps réel et qui bénéficient grandement de ce genre de matériel. IBM est à ma connaissance le seul constructeur qui fasse de la R&D sérieuse sur les processeurs haute-performance (AMD essaie mais semble pas mal se planter : depuis Hyper-Transport, y'a des tentatives mais rien de convaincant) et qui soit capable de contrer Intel. Et oui, une grande partie de ces applications s'exécute loin des regards, dans des trucs genre DOD.

Hum, 40% de moins, c'est 4 jours de calcul en moins pour obtenir une réponse pour simuler un modèle quelconque. Je ne suis pas du tout d'accord pour dire « juste derrière ». Dans le domaine de la haute performance (pas forcément calcul scientifique), 5 ou 10 % je suis d'accord c'est « négligeable », mais 40%, certainement pas.

On ne parle pas de la même chose. Je parle de latence, tu parles de bande-passante. :)

Lorsque j'avais fait des micro-benchmarks sur Nehalem EP et EX, j'avais les mesures suivantes :

• 0,5 cycle par mot de 64 bits (8 octets) pour un load (en utilisant SSE, car le bus est de 16 octets entre le cœur et le L1)
• ~0,8 cycle par mot de 64 bits pour accéder au L2
• ~1,2 cycle par mot de 64 bits pour accéder au L3

Comme les caches sont configurés en « write allocate », une écriture en mémoire pour un mot = load + store, ce qui réduisait d'environ 25% la bande passante en pratique lorsqu'on faisait du write-only.

Sur Sandy Bridge au pifomètre je m'attends à quelque chose de sensiblement équivalent.

Ça dépend fortement de quel pays on parle. En Australie / Nouvelle Zélande, on s'en fout un peu, et en fonction du milieu où on se trouve, en Irlande itou. Aux US et en GB, c'est aussi mauvais que « nigger » et considéré comme très misogyne (d'ailleurs ils parlent de « n-word » et « c-word » sur les chaînes qui blippent les mots¹).

Ce que je trouve rigolo, c'est que « cunt » se traduit littéralement par con en Français (donc le vagin), et que chez nous il a complètement perdu son sens initial.

Et donc écrire ceci :

L’UE puis l’Allemagne ont activement et consciencieusement participé au démentèlement de la Grèce. Alors quelqu’un qui pense que l’UE n’a pas assez aidé la Grèce, ben ça me fait juste l’effet d’un extra-terrestre qui vient de débarquer sur Terre, c’est carrément surréaliste. Voir ce blog qui résume la question : http://www.greekcrisis.fr/

… C'est si difficile que ça ?

Dire que c'est surréaliste je trouve ça un peu fort par contre, car justement ce que j'essaie d'expliquer, c'est que dans un vrai état fédéral, même avec des états qui se font de la compèt' niveau maternelle, le gouvernement fédéral ne laisserait pas passer ce qui se passe en ce moment en Grèce, et encore moins ne poserait de mécanisme pour encourager son démantèlement (un état en faillite est un état qui ne rapporte plus de pognon pour le budget fédéral).

Concernant le lien avec le Cell BE — oui ça ressemble beaucoup, mais avec quelques grosses différences :

1. Les SPU du Cell BE avaient un scratchpad de 256 Kio, pour le code ET les données. Par contraste, C64 avait un cache d'instructions et le scratchpad et la SRAM n'étaient utiles que pour les données. Je l'ai déjà peut-être dit ici, mais un ingénieur d'une agence américaine à trois lettres bien aimée ici avait dit aux architectures présents dans la salle que le prochain à lui filer une architecture sans cache d'instruction, il le tabasserait.
2. Comme j'avais dit avant, la SRAM partagée suit le modèle SC (sequential consistency) grâce à son cross-bar. Ça veut dire entre autre que toute lecture ou écriture dans le « cache » / la SRAM (il y a en fait 30 bancs mémoire vers la SRAM) suivra un ordre total sans le surcoût d'un protocole de cohérence.
3. Pas de DMA engine (mais pas d'anneau pour communiquer entre les threads non plus, ce qui est un plus)
4. Instructions atomiques au niveau du contrôleur mémoire : fetch-and-add est en réalité plutôt un add-and-return-old-value, ce qui permet de faire de l'overlapping, contrairement à la sémantique du load-modify-write avec verrouillage de ligne de cache ou même du bus.

Après, évidemment il y a plein de soucis, du genre le malloc du système alloue sur le tas, et donc en DRAM. Il faut ensuite utiliser des variantes spécialisées et effectuer des mouvements mémoire à la main entre DRAM et SRAM. C'est bien entendu contraignant.

Quand on m'a expliqué l'archi et l'OS/Runtime qui tournait dessus, la première chose que je me suis dite c'est « ça doit être le rêve pour un expert en parallélisme, et un cauchemar pour un programmeur normal ».

Un de mes anciens collègues avait développé un cache logiciel sur cette machine et le Cell et démontré que l'overhead était minimal si tu choisissais un protocole de constance mémoire beaucoup plus faible que la cohérence de cache classique.

Hum, en 2007, Cyclops64 te promettait 80 GFLOPS soutenus en double précision, et une réelle généricité des applications. Les cartes Nvidia de l'époque ne pouvaient pas en dire autant.

Graou. Paris-Lille = 1h de TGV, et chez-moi-New York City, pour une distance relativement comparable, c'est ~2h30.

Voilà voilà.

J’ai pas éludé. J’ai mis un lien. Lisez tous les billets de ce blog pendant quelques années, et vous vous rendrez compte pourquoi vous dites une grosse connerie. Et que vous récidivez.

Tu te rends compte de la condescendance de ton propos ? Tu balances un lien sans explication, et tu me dis que j'ai à me taper tous les billets contenu dans le site visé ? OK, la prochaine fois que quelqu'un pose une question sur un sujet que je prétends connaître, genre un truc sur l'architecture des processeurs ou la compil, je filerai vers un lien vers le papier qui décrit la technique dont on parle, et qui se trouve derrière un paywall. T'as pas payé ton dû à l'ACM ? Dommage, mais c'est tellement évident que je ne vais pas me prendre la tête à t'expliquer hein.

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].