Le add représente bien plus d'un cycle, car il y a une dépendance read-after-write. C'est évidement une amélioration du loop unrolling, mais bon, c'est la base, même gcc le fait tout seul (ou presque).
"via un, à la louche, load R16, PTR [R15 + CST]."
C'est bien ce que je reproche, il passe par la mémoire au lieu d'utiliser un registre (en cas de réutilisation du str->foo bien sûr). Cela doit être dû à la gestion des alias mémoire par le compilo C (2 pointeurs du même type dans le même scope et tout passe par la mémoire, car l'un peu aliaser l'autre).
D'ailleurs, cela me rappelle aussi une personne qui pensait que parce que la donné se trouvait dans les write buffer, cela n'était pas la peine d'essayer de passer par un registre. Pourtant, la bande passante, même entre un registre, et un write buffer n'a rien à avoir. Il y a souvent qu'un ou 2 bus (1read/ 1write) pour gérer la mémoire, or un x86 gère 5 instructions à la volé soit 10 read et 5 write. Et encore, il n'est pas question du surcout de la mémoire à cause de la gestion de la pagination et de sa cohérence (lecture retardé juste après un write pour vérifier que l'on ne relit pas la même donné).
Il faudrait que je le relise, mais quand il était sorti, il y avait des trucs qui m'avait fait tiquer, (mais j'ai oublié quoi :).
Il faut connaitre aussi un peu le genre de truc que sortent les compilo C, surtout avec la vectorisation automatique, en changeant un peu son code, le compilo peut faire plus de chose.
De plus, laisser faire le compilo marche bien pour les monstres comme les Intel core. Mais pour des trucs plus simple comme les PPC 603 (et donc les ARM des smartphone), tu te prends tous les problèmes des CPU les plus simple : prédiction de branchement statique, pas de prédiction de saut dynamique (vtable), très peu de write buffer (donc mélanger lecture et écriture est pénalisant), l'alignement mémoire est primordial, etc…
La doc d'AMD parle d'assembleur mais aussi de code C.
Par exemple, un code que l'on trouve dans le kernel linux, n'est pas intuitif :
for (i=0;i<N;tab+=4,i+=4){
tab[0] = tab[0] + n…
tab[1] = tab[1] + n…
tab[2] = tab[2] + n…
tab[3] = tab[3] + n…
}
C'est plus rapide car l'indexation d'un tableau par une constante, génère une seul instruction contrairement à "tab[i]" qui nécessite une addition.
Le cout d’usage des pointeurs est souvent négligé. Tous les codes utilisant des "str->foo" passe très souvent par la mémoire, plutôt que par un registre.
Je l'avais lu à une époque :) dans mon souvenir, il y avait 3 pdf. Concernant les perfs pour le codage en C, AMD avait sorti quelques choses de très lisible.
oula non. La meilleur distance de prefetch dépend de l'architecture. A la limite, le preload est mieux : tu coupes ta boucle en 3, pour qu'en simultané tu ais la lecture des données n+1, le traitement des données n, et l'écriture des données n-1. Si le parcours suit un pattern pas trop complexe, les prefetch automatiques pourront s'en sortir.
A l'époque où j'avais lu sur le sujet, il y avait les Cray qui avait un mode non-coherent (nc). C'était le seul moyen d'avoir toute la puissance disponible. Les codeurs s'arrachaient tellement les cheveux, qu'ils ont renoncer à ce genre de mode dans les machines suivantes. J'imagine que cela devait ressembler à un gros GPU mais avec des vecteurs de plusieurs centaines de flottant.
Tu veux dire que le mécanisme de cohérence mémoire n'entre pas en compte lorsque la donnée est en write buffer, mais pas encore en cache. Donc, pris en compte par le cpu ayant écrit mais pas les autres ? J'avais lu qu'il relachait sans cesse la cohérence mémoire, et l'itanium allait assez loin, mais je ne pensais pas à ce point-là.
volatile est un mot clef pour dire que la donnée mémoire déclarée ensuite, à le contenu qui bouge tout seul. C'est la base pour accéder à des registres hardware.
Dans le cas contraire, un compilo considère que seul le programme C en cours de compilation peut y toucher, d'où la génération possible de boucle infinie, de lecture unique puis un usage de registre.
La mémoire de PC est cohérente de partout normalement. Une fois une données écrite quelques part, elle est visible par tous de la même façon. Il y a logiquement un mécanisme de synchronisation qui détecte ce genre de cas.
Et une fois tu as expliqué clairement un problème, tu trouves la solution. J'adore aller ennuyer un collègue avec un problème, je fais mon monologue, puis je trouve la solution tout seul :)
Les téchniques disponibles par processeurs, ne sont pas pléthoriques. Je ne connais pas ton équipe, mais toutes les universitaires que j'ai vu bosser dans le domaine des compilateurs avaient une vision très vague de la façon de fonctionner d'un cpu.
Genre cela peut les défriser quand on leur dit :
- que plus d'instructions peut permettre d'aller plus vite que moins
- que l'instruction la plus lente est souvent un load
- que le temps d'accès à la mémoire, n'est absolument pas uniforme, avec un rapport environ de 100 entre le plus lent et le plus rapide.
- qu'une multiplication est une instruction très rapide de nos jours, mais pas du tout une division
tu peux t'en sortir, si il s'agit d'un pointeur dans B et des données dans A.
Le pointeur B peut être invalide (en dehors du fichier tel que vu actuellement), ou B pointe vers une vielle donné : si le nom est présent, on peut détecter l'erreur.
C'est un "free running counter" par cpu. Cela veut dire que si on change de cpu, il peut y a voir un shift. Intel pour les crétins qu'il l'utilise comme horloge fixe l'a sorti du domaine de fréquence variable, pour le coller à une horloge fixe : donc cela ne correspond plus vraiment à un nombre de cycle et plus à du temps à l'échelle de l'instruction.
Dans le cas de mesure courte, il y a peu de chance que l'os foute le bordel dans la mesure. C'est 2 instructions super légères.
En général, je colle des résultats dans un tableau, que je print ensuite pour faire une jolie courbe dans un tableur. C'est facile de voir les valeurs "à la con", les pattern, les extrêmes. Faire une boucle pour atteindre un pas de temps mesurable pour les autres fonctions te donnes une sorte de borne supérieurs du code, car les caches sont "archi chauds". Cela te donne peu d'info sur la vitesse réelle dans ton code, ni la vitesse minimum.
Je ne sais pas trop comment tu gères les données "à effacer", qui est le problème des structures en softupdate. Tu as une sorte de garbage collector ?
J'imagine qu'en écriture, tu alloues de la mémoire dans ton fichier pour y mettre ton triplet, puis l'écrit, puis tu modifies un pointeur de l'ancienne vers la nouvelle valeur ? Comment tu récupères la mémoire du triplet précédent, sur une liste de blocs libres ?
Il doit exister un paquet de littérature sur la manière la plus efficace d'implémenter une sparse-matrix (matrice à trous).
J'ai du mal à suivre. Est-ce une vrai base de donné avec sauvegarde sur disque des écritures de façon protégé ? Parce que niveau perf, il y a une différence énorme entre une grosse structure de donné en mémoire, et des données sauvé sur disque. Il y a aussi une grosse différence de performance si chaque écriture doit être pris en compte immédiatement ou non.
Ton bench de qq Ko n'a strictement aucun sens, la base tient dans le cache L1 d'un processeur ! Les perfs peuvent tomber drastiquement si la base ne tient pas en cache L2 ou L3, voir ne tient pas dans la RAM.
"32 octets par triplet (objet, clé, valeur)"
C'est quoi cet objet ? Tu ne parles que d'une matrice[i][j]-> k, i,j,k étant entier.
En général, le "make it work" implique le bon algorithme et la bonne architecture. Le "make it fast" sous-entend une transformation du code source uniquement pour aller plus vite, il reste peu de marge, et cela rend le code source difficile à lire.
Il ne faut pas faire des boucles pour augmenter les chiffres. Sur tout les benchs que j'ai fait, j'ai observé un ramp-up des performances, entre la 1er, la deuxième et la 3ième exécution d'un même code. La meilleur façon de faire de mon point de vue est de tracer des courbes, tu imprimes le temps d’exécution de chaque itération, ainsi tu peux comparer en repérant les anomalies et les patterns (très amusant à faire sur un malloc par exemple, ou on repère facilement 3 branches de code).
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
"le add supprimé c'est 1 cycle"
Le add représente bien plus d'un cycle, car il y a une dépendance read-after-write. C'est évidement une amélioration du loop unrolling, mais bon, c'est la base, même gcc le fait tout seul (ou presque).
"via un, à la louche, load R16, PTR [R15 + CST]."
C'est bien ce que je reproche, il passe par la mémoire au lieu d'utiliser un registre (en cas de réutilisation du str->foo bien sûr). Cela doit être dû à la gestion des alias mémoire par le compilo C (2 pointeurs du même type dans le même scope et tout passe par la mémoire, car l'un peu aliaser l'autre).
D'ailleurs, cela me rappelle aussi une personne qui pensait que parce que la donné se trouvait dans les write buffer, cela n'était pas la peine d'essayer de passer par un registre. Pourtant, la bande passante, même entre un registre, et un write buffer n'a rien à avoir. Il y a souvent qu'un ou 2 bus (1read/ 1write) pour gérer la mémoire, or un x86 gère 5 instructions à la volé soit 10 read et 5 write. Et encore, il n'est pas question du surcout de la mémoire à cause de la gestion de la pagination et de sa cohérence (lecture retardé juste après un write pour vérifier que l'on ne relit pas la même donné).
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4.
Il faudrait que je le relise, mais quand il était sorti, il y avait des trucs qui m'avait fait tiquer, (mais j'ai oublié quoi :).
Il faut connaitre aussi un peu le genre de truc que sortent les compilo C, surtout avec la vectorisation automatique, en changeant un peu son code, le compilo peut faire plus de chose.
De plus, laisser faire le compilo marche bien pour les monstres comme les Intel core. Mais pour des trucs plus simple comme les PPC 603 (et donc les ARM des smartphone), tu te prends tous les problèmes des CPU les plus simple : prédiction de branchement statique, pas de prédiction de saut dynamique (vtable), très peu de write buffer (donc mélanger lecture et écriture est pénalisant), l'alignement mémoire est primordial, etc…
La doc d'AMD parle d'assembleur mais aussi de code C.
Par exemple, un code que l'on trouve dans le kernel linux, n'est pas intuitif :
for (i=0;i<N;tab+=4,i+=4){
tab[0] = tab[0] + n…
tab[1] = tab[1] + n…
tab[2] = tab[2] + n…
tab[3] = tab[3] + n…
}
C'est plus rapide car l'indexation d'un tableau par une constante, génère une seul instruction contrairement à "tab[i]" qui nécessite une addition.
Le cout d’usage des pointeurs est souvent négligé. Tous les codes utilisant des "str->foo" passe très souvent par la mémoire, plutôt que par un registre.
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Je l'avais lu à une époque :) dans mon souvenir, il y avait 3 pdf. Concernant les perfs pour le codage en C, AMD avait sorti quelques choses de très lisible.
Sans doute ce truc : http://support.amd.com/us/Processor_TechDocs/22007.pdf
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
oula non. La meilleur distance de prefetch dépend de l'architecture. A la limite, le preload est mieux : tu coupes ta boucle en 3, pour qu'en simultané tu ais la lecture des données n+1, le traitement des données n, et l'écriture des données n-1. Si le parcours suit un pattern pas trop complexe, les prefetch automatiques pourront s'en sortir.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2. Dernière modification le 16 mai 2013 à 10:29.
A l'époque où j'avais lu sur le sujet, il y avait les Cray qui avait un mode non-coherent (nc). C'était le seul moyen d'avoir toute la puissance disponible. Les codeurs s'arrachaient tellement les cheveux, qu'ils ont renoncer à ce genre de mode dans les machines suivantes. J'imagine que cela devait ressembler à un gros GPU mais avec des vecteurs de plusieurs centaines de flottant.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Tu veux dire que le mécanisme de cohérence mémoire n'entre pas en compte lorsque la donnée est en write buffer, mais pas encore en cache. Donc, pris en compte par le cpu ayant écrit mais pas les autres ? J'avais lu qu'il relachait sans cesse la cohérence mémoire, et l'itanium allait assez loin, mais je ne pensais pas à ce point-là.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 1.
acid est rarement nécessaire comme le montre le succès du no-sql.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
volatile est un mot clef pour dire que la donnée mémoire déclarée ensuite, à le contenu qui bouge tout seul. C'est la base pour accéder à des registres hardware.
Dans le cas contraire, un compilo considère que seul le programme C en cours de compilation peut y toucher, d'où la génération possible de boucle infinie, de lecture unique puis un usage de registre.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
La mémoire de PC est cohérente de partout normalement. Une fois une données écrite quelques part, elle est visible par tous de la même façon. Il y a logiquement un mécanisme de synchronisation qui détecte ce genre de cas.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 8.
Et une fois tu as expliqué clairement un problème, tu trouves la solution. J'adore aller ennuyer un collègue avec un problème, je fais mon monologue, puis je trouve la solution tout seul :)
"La première sécurité est la liberté"
[^] # Re: C'est trop limité ;)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Galeries de shaders GLSL et fond d'écran animé pour Android. Évalué à 2. Dernière modification le 15 mai 2013 à 17:13.
"Pas que je sache, mais en même temps, vu que la variable est globale et constante, quel serait l'intérêt de la limiter à une fonction ?"
Faire des calculs genre lui faire calculer 1/ srqt(5) une fois pour toutes sans avoir à faire confiance au compilo du drivers opengl.
"a" pour faire de la transparence, dans une fenêtre web ?
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 3.
:)
Les téchniques disponibles par processeurs, ne sont pas pléthoriques. Je ne connais pas ton équipe, mais toutes les universitaires que j'ai vu bosser dans le domaine des compilateurs avaient une vision très vague de la façon de fonctionner d'un cpu.
Genre cela peut les défriser quand on leur dit :
- que plus d'instructions peut permettre d'aller plus vite que moins
- que l'instruction la plus lente est souvent un load
- que le temps d'accès à la mémoire, n'est absolument pas uniforme, avec un rapport environ de 100 entre le plus lent et le plus rapide.
- qu'une multiplication est une instruction très rapide de nos jours, mais pas du tout une division
"La première sécurité est la liberté"
# La suite pour ocaml ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Présentation OCaml le 21 mai 2013 à Paris. Évalué à 3.
Est-ce que quelqu'un sait ce qui est prévu pour la prochaine version d'ocaml ?
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
tu peux t'en sortir, si il s'agit d'un pointeur dans B et des données dans A.
Le pointeur B peut être invalide (en dehors du fichier tel que vu actuellement), ou B pointe vers une vielle donné : si le nom est présent, on peut détecter l'erreur.
"La première sécurité est la liberté"
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4.
C'est un "free running counter" par cpu. Cela veut dire que si on change de cpu, il peut y a voir un shift. Intel pour les crétins qu'il l'utilise comme horloge fixe l'a sorti du domaine de fréquence variable, pour le coller à une horloge fixe : donc cela ne correspond plus vraiment à un nombre de cycle et plus à du temps à l'échelle de l'instruction.
Dans le cas de mesure courte, il y a peu de chance que l'os foute le bordel dans la mesure. C'est 2 instructions super légères.
En général, je colle des résultats dans un tableau, que je print ensuite pour faire une jolie courbe dans un tableur. C'est facile de voir les valeurs "à la con", les pattern, les extrêmes. Faire une boucle pour atteindre un pas de temps mesurable pour les autres fonctions te donnes une sorte de borne supérieurs du code, car les caches sont "archi chauds". Cela te donne peu d'info sur la vitesse réelle dans ton code, ni la vitesse minimum.
"La première sécurité est la liberté"
# utilisable en production ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de Tuleap 6.0. Évalué à 1.
Et le logiciel est dans quel état ?
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 5.
C'est totalement vrai, mais il y a aussi une bonne dose de mauvaise communication de sa part.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 3.
Je ne sais pas trop comment tu gères les données "à effacer", qui est le problème des structures en softupdate. Tu as une sorte de garbage collector ?
J'imagine qu'en écriture, tu alloues de la mémoire dans ton fichier pour y mettre ton triplet, puis l'écrit, puis tu modifies un pointeur de l'ancienne vers la nouvelle valeur ? Comment tu récupères la mémoire du triplet précédent, sur une liste de blocs libres ?
Il doit exister un paquet de littérature sur la manière la plus efficace d'implémenter une sparse-matrix (matrice à trous).
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 7.
roooh, te rappelles-tu comment tu étais à son age ? (ce que tu pensais des plus vieux sur les forums :)
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 5.
J'ai du mal à suivre. Est-ce une vrai base de donné avec sauvegarde sur disque des écritures de façon protégé ? Parce que niveau perf, il y a une différence énorme entre une grosse structure de donné en mémoire, et des données sauvé sur disque. Il y a aussi une grosse différence de performance si chaque écriture doit être pris en compte immédiatement ou non.
Ton bench de qq Ko n'a strictement aucun sens, la base tient dans le cache L1 d'un processeur ! Les perfs peuvent tomber drastiquement si la base ne tient pas en cache L2 ou L3, voir ne tient pas dans la RAM.
"32 octets par triplet (objet, clé, valeur)"
C'est quoi cet objet ? Tu ne parles que d'une matrice[i][j]-> k, i,j,k étant entier.
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
ta base de donnée, c'est 2 chiffres de 32 bits qui pointent vers un seul chiffre de 32 bits ou est-ce n chiffres de 32 bits vers un seul de 32 bits ?
Quelle est sa taille ? Genre 100 mo ? 10 Go ? 1 To ?
"La première sécurité est la liberté"
[^] # Re: Ai-je bien compris ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 4.
En général, le "make it work" implique le bon algorithme et la bonne architecture. Le "make it fast" sous-entend une transformation du code source uniquement pour aller plus vite, il reste peu de marge, et cela rend le code source difficile à lire.
"La première sécurité est la liberté"
[^] # Re: Linux perf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 2.
Il y a un peu plus de 30 personnes qui font des cpu dans le monde :)
"La première sécurité est la liberté"
[^] # Re: y'a trop peu d'infos pour t'aider.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 3.
Il ne faut pas faire des boucles pour augmenter les chiffres. Sur tout les benchs que j'ai fait, j'ai observé un ramp-up des performances, entre la 1er, la deuxième et la 3ième exécution d'un même code. La meilleur façon de faire de mon point de vue est de tracer des courbes, tu imprimes le temps d’exécution de chaque itération, ainsi tu peux comparer en repérant les anomalies et les patterns (très amusant à faire sur un malloc par exemple, ou on repère facilement 3 branches de code).
"La première sécurité est la liberté"
[^] # Re: C'est trop limité ;)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Galeries de shaders GLSL et fond d'écran animé pour Android. Évalué à 2.
Est-ce qu tu peux déclarer une variable uniforme dans une fonction du shader ?
Quel est l’intérêt du "a" dans rgba quand on est plus dans un espace 3d ?
"La première sécurité est la liberté"