Pour ce qui est de la gestion de la mémoire, à mon avis, une bonne partie de la différence de prformance viens de la. Mes programmes travail sur des volumes de données assez énormes, l'un d'entre eux ayant des pics à 15 Go en C, le même dépassant les 21 Go en Lisaac. Et la machine sur laquelle il tourne dispose de 16 Go de ram, le deuxième doit donc swapper de temps en temps pendant l'éxecution.
Pour le moment, Lisaac prend ses aises niveau mémoire, mais ça va s'améliorer, ya des idées en l'air comme la réutilisation de variables locales, en jouant sur les lignes de cache (oui parce que la gestion de la mémoire en lisaac essaye de jouer sur la gestion de ligne de cache)
Comme on veut cibler l'embarqué, on va travailler sur la consommation mémoire, mais c'était pas la priorité pour cette version.
Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
C'est prévu.
Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
Tu parles du cache code ou du cache données ?
En ce qui concerne le cache code, il faut effectivement faire attention à ne pas trop inliner.
En ce qui concerne le cache données, Lisaac gère tant que possible la mémoire en se basant sur des lignes de cache à 64 octets, mais c'est encore très perfectible.
Ya aussi une grosse optim qui est prévu et qui fera gagner beaucoup, c'est de sortir les variables.
Dans le C généré par lisaac, tu as souvent :
while( cond) {
((int *)struct1->struct2->struct3)[index ] = ...
...
}
Le pb c'est que gcc recalcul le pointeur à chaque fois ds la boucle, faut donc créer une variable locale (ou mieux utilser une existante) qui va le faire avant le début du while, et éviter ça.
Benoit évalue cette optim à deux semaine de travail.
J'ai fait cette optim à la main sur du code critique en calcul, j'ai gagné 15%
Et je te parle pas de la futur autovectorisation de GCC, de mélanger flottant et entier, etc...
Ya encore énormément de chose à faire en optim, on est qu'au tout début.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 5.
Pour le moment, Lisaac prend ses aises niveau mémoire, mais ça va s'améliorer, ya des idées en l'air comme la réutilisation de variables locales, en jouant sur les lignes de cache (oui parce que la gestion de la mémoire en lisaac essaye de jouer sur la gestion de ligne de cache)
Comme on veut cibler l'embarqué, on va travailler sur la consommation mémoire, mais c'était pas la priorité pour cette version.
Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
C'est prévu.
Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
Tu parles du cache code ou du cache données ?
En ce qui concerne le cache code, il faut effectivement faire attention à ne pas trop inliner.
En ce qui concerne le cache données, Lisaac gère tant que possible la mémoire en se basant sur des lignes de cache à 64 octets, mais c'est encore très perfectible.
Ya aussi une grosse optim qui est prévu et qui fera gagner beaucoup, c'est de sortir les variables.
Dans le C généré par lisaac, tu as souvent :
while( cond) {
((int *)struct1->struct2->struct3)[index ] = ...
...
}
Le pb c'est que gcc recalcul le pointeur à chaque fois ds la boucle, faut donc créer une variable locale (ou mieux utilser une existante) qui va le faire avant le début du while, et éviter ça.
Benoit évalue cette optim à deux semaine de travail.
J'ai fait cette optim à la main sur du code critique en calcul, j'ai gagné 15%
Et je te parle pas de la futur autovectorisation de GCC, de mélanger flottant et entier, etc...
Ya encore énormément de chose à faire en optim, on est qu'au tout début.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker