On t'a déjà répondu en dessous, mais j'en rajoute une couche.
euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération
Mais non !
1) c'est stable depuis des années (cf en dessous). Le coût de la mémoire cache rapide est délirant contrairement à celui de la mémoire lente. C'est très bien expliqué dans l'article de Drepper.
2) les méthodes dont je parle sont « cache oblivious » c'est-à-dire qu'elles travaillent sur le principe de la hiérarchie mémoire, pas sur les valeurs fines des caches
3) pour les bibliothèques open source, les réglages fins sont faits à la compilation (cf atlas). Pour les bibliothèques propriétaires (genre MKL intel), il a plusieurs versions. Matlab intègre par exemple ces bibliothèques super optimisées.
4) la prédiction de branchement n'a pas grand impact sur les codes intensifs en calcul. En outre, son amélioration est impossible sans introspection. Il faut faire tourner le code de base instrumenté, puis donner le résultat au compilateur pour qu'il améliore le code par la suite. C'est ce que fait la JVM et c'est expliqué pour le C dans l'article de Drepper.
des algo compréhensible par les compilateurs de façon à se qu’ils optimisent
Ceci me semble bien naïf. Un compilateur compile, il ne comprend rien. Surtout si c'est du C qui est un langage peu structuré que les compilateurs ont beaucoup de mal à optimiser (comparé à du fortran, par exemple). Et à ma connaissance, aucun compilateur ne tient compte aujourd'hui des schémas d'accès à la mémoire, au moins pour les langages de bas niveau. En revanche, le C++ et ses expressions templates ou scale et ses DSL permettent de faire ça. Il faut bien sûr se pogner la bibliothèque de bas niveau qui fait ça.
De plus, tu occultes le fait que tout le monde n’a pas une puce Intel et que dans ce cas, il faut aussi optimiser pour AMD, faire un algo spécial pour chaque ARM, etc.
Non, cf le code d'Atlas (qui a exactement été conçu pour résoudre ce problème, il y a plus de 10 ans).
C’est envisageable quand tu fais de l’embarqué, que tu connais ta cible pour de l’applicatif PC, c’est de la masturbation intellectuelle. C’est ce que je disais dans un autre commentaire, c’est intéressant pour le sport, pour le défi, mais ça n’a aucune importance pour ça.
Mais bien sûr. Je te suggère d'en discuter avec des développeurs de jeu dont l'influence sur le hardware est considérable (pas de jeu, pas de cartes Nvidia qui crachent du teraflop/s). Et plus généralement, qui de sérieux peut cracher sur un facteur 10 ?
Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances... mais pour de l’applicatif, ce n’est pas généralisable.
Je ne comprends pas ta remarque dans le contexte de ngix, par exemple.
Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. Mais il ne faut pas tomber dans le travers inverse à chasser la dernière ns en dépensant 30 jours de développement.
Ah, le bon vieil homme de paille... Je ne parle pas de ça, nom de dieu ! Je parle d'un facteur 10 !!!!
Je vois que tu es universitaire d’après ton lien page perso. Ce qui explique cela. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)
Si tu veux faire intervenir la personnalité de ton interlocuteur dans une discussion, ce qui frise à mon avis l'ad hominem et donc n'apporte rien, autant te renseigner sur le dit interlocuteur. Et plus généralement sur l'université. Par exemple, j'ai fait ma thèse dans l'industrie en contribuant (modestement) à l'amélioration d'un radar de Thalès (Thomson CSF à l'époque, ma barbe est grise). J'encadre des doctorants en CIFRE dans des minuscules startup comme Lokad, dans des entreprises moyennes comme Viadeo ou dans des grands groupes comme Orange et Snecma. Nos travaux sur le machine learning dans le cloud, sur l'amélioration de l'estimation des performances d'algorithmes de recommandation, sur l'exploration de grandes bases de données clients ou sur le monitoring des moteurs d'avions sont tous appliqués à des problèmes concrets. Ils sont passés en production dans certains cas. Je pratique aussi la masturbation intellectuelle en faisant des preuves de convergence pour certains algorithmes d'apprentissage automatique. Mais bon, tout ça on s'en fout car ça n'a rien à voir avec la discussion sur l'optimisation de code ! Mais c'est sûr qu'avec une telle mentalité, tu risques de ne pas suivre ce qui se fait en recherche et conserver des habitudes de programmation complètement dépassées.
[^] # Re: suppressions ?!
Posté par boubou . En réponse à la dépêche OpenBSD 5.6. Évalué à 4.
On t'a déjà répondu en dessous, mais j'en rajoute une couche.
Mais non !
1) c'est stable depuis des années (cf en dessous). Le coût de la mémoire cache rapide est délirant contrairement à celui de la mémoire lente. C'est très bien expliqué dans l'article de Drepper.
2) les méthodes dont je parle sont « cache oblivious » c'est-à-dire qu'elles travaillent sur le principe de la hiérarchie mémoire, pas sur les valeurs fines des caches
3) pour les bibliothèques open source, les réglages fins sont faits à la compilation (cf atlas). Pour les bibliothèques propriétaires (genre MKL intel), il a plusieurs versions. Matlab intègre par exemple ces bibliothèques super optimisées.
4) la prédiction de branchement n'a pas grand impact sur les codes intensifs en calcul. En outre, son amélioration est impossible sans introspection. Il faut faire tourner le code de base instrumenté, puis donner le résultat au compilateur pour qu'il améliore le code par la suite. C'est ce que fait la JVM et c'est expliqué pour le C dans l'article de Drepper.
Ceci me semble bien naïf. Un compilateur compile, il ne comprend rien. Surtout si c'est du C qui est un langage peu structuré que les compilateurs ont beaucoup de mal à optimiser (comparé à du fortran, par exemple). Et à ma connaissance, aucun compilateur ne tient compte aujourd'hui des schémas d'accès à la mémoire, au moins pour les langages de bas niveau. En revanche, le C++ et ses expressions templates ou scale et ses DSL permettent de faire ça. Il faut bien sûr se pogner la bibliothèque de bas niveau qui fait ça.
Non, cf le code d'Atlas (qui a exactement été conçu pour résoudre ce problème, il y a plus de 10 ans).
Mais bien sûr. Je te suggère d'en discuter avec des développeurs de jeu dont l'influence sur le hardware est considérable (pas de jeu, pas de cartes Nvidia qui crachent du teraflop/s). Et plus généralement, qui de sérieux peut cracher sur un facteur 10 ?
Je ne comprends pas ta remarque dans le contexte de ngix, par exemple.
Ah, le bon vieil homme de paille... Je ne parle pas de ça, nom de dieu ! Je parle d'un facteur 10 !!!!
Si tu veux faire intervenir la personnalité de ton interlocuteur dans une discussion, ce qui frise à mon avis l'ad hominem et donc n'apporte rien, autant te renseigner sur le dit interlocuteur. Et plus généralement sur l'université. Par exemple, j'ai fait ma thèse dans l'industrie en contribuant (modestement) à l'amélioration d'un radar de Thalès (Thomson CSF à l'époque, ma barbe est grise). J'encadre des doctorants en CIFRE dans des minuscules startup comme Lokad, dans des entreprises moyennes comme Viadeo ou dans des grands groupes comme Orange et Snecma. Nos travaux sur le machine learning dans le cloud, sur l'amélioration de l'estimation des performances d'algorithmes de recommandation, sur l'exploration de grandes bases de données clients ou sur le monitoring des moteurs d'avions sont tous appliqués à des problèmes concrets. Ils sont passés en production dans certains cas. Je pratique aussi la masturbation intellectuelle en faisant des preuves de convergence pour certains algorithmes d'apprentissage automatique. Mais bon, tout ça on s'en fout car ça n'a rien à voir avec la discussion sur l'optimisation de code ! Mais c'est sûr qu'avec une telle mentalité, tu risques de ne pas suivre ce qui se fait en recherche et conserver des habitudes de programmation complètement dépassées.