lasher a écrit 2738 commentaires

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.

Tu ne peux sans doute pas vivre du site, mais ça peut faire un sérieux complément financier. J'ai connu un étudiant qui avait fait un site sur un domaine particulier, avec quelques pubs, et ça lui a permis de partir en vacances chaque été.

En d'autres mots : dire que la pub donne un aspect néfaste à un site est sans doute une tautologie, de même que la pub à la télé ou à la radio est chiante, etc. Donc si tu n'as pas de pub sur le site, il reste peu de solutions pour faire du fric avec du libre-mais-aussi-gratuit :

1. Tu proposes un ensemble de services gratuits (au moins un), et d'autres payants. Si tu as un joli produit à proposer, alors il est possible que pour un tarif attractif tu trouves des clients.
2. Tu mets une « tirelire électronique » (paypal, flattr, etc.) sur ton site en disant aux gens que s'ils aiment tes services, ils peuvent te récompenser en payant un petit quelque chose.
3. Tu fais pas : tu fais payer un prix qui te semble raisonnable pour le service que tu proposes. Par exemple : tu proposes un prix relativement bas mais fixe chaque mois, et un prix variable en fonction du nombre d'utilisateurs (pour couvrir les frais de location du serveur et de la bande passante par exemple). Plus tu as d'utilisateurs, plus le prix variable baissera, mais finira par atteindre un « plateau bas » (car il y a un minimum de bande-passante par utilisateur à considérer).

Perso, j'aime bien l'approche Wikipedia qui fait une campagne chaque année jusqu'à ce qu'un objectif financier soit atteint. Bien entendu, ça marche d'autant mieux que le site est déjà extrêmement bien fourni en contenu (donc en « service »). Le site de Reddit fait un truc un peu équivalent en ayant un objectif financier journalier pour payer tout le monde (employés, serveurs, etc.).

Au-delà de ça, point de salut : la pub est malheureusement nécessaire si on veut faire des sous.

Mon code était portable, mais il était clairement écrit pour qu'icc comprenne quelles optimisations il pouvait faire. ;)

Après, la portabilité des performances, c'était un autre problème…

Mouais. Les SPEC utilisent gzip/bzip2 (en fonction des années), gcc (une vieille version), des noyaux de type traversée de graphe, algèbre linéaire creux, etc., et du coup les fabricants de processeurs et compilateurs font du fine-tuning dessus pour avoir un joli score… :)

Je suis complètement pour l'utilisation d'applis plus grosses pour faire des tests en « conditions réelles » hein, mais par exemple compiler un gros projet ça risque de stresser plus ton hdd/ssd que ton processeur au final, et donc tes résultats seront bien pour ta machine perso, mais pas trop pour généraliser.

Les micro-benches sont intéressants pour voir si les limites théoriques annoncées par les constructeurs sont atteignables facilement. Genre on nous annonce « x GB/s » sur le cache L2 ? Ah oui, mais seulement en lecture, car en écriture on doit faire avec la politique d'allocation « write allocate » (c'est-à-dire on charge la ligne, puis on écrit). Du coup ensuite on passe (pour du x86 par ex) par des « non-temporal stores » et on s'aperçoit qu'en fonction du processeur, ça fait réellement ce qu'on veut ou pas. Je trouve que c'est quand même important d'en être conscient quand on écrit du soft pour la performance.

Il n'a peut-être pas de langage aussi fleuri que les deux autres, mais il peut cracher un venin très puissant…

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