Pour les premiers essais j'utilisait les binnaires fournits directement par Lisaac, mais justement, ne sachant pas quelles options il passait à gcc je me suis mits à les compiler avec exactement les mêmes options que pour mon code. Les comparaisons sont faites avec ces derniers binnaires.
Pour ce qui est des algorithmes, ils sont déjà optimisés à mort, mais même avec les meilleurs algos, si tu les implémente comme un pieds tu obtiens un programme qui se trainne comme un bousin. Et même si tu fais gaffe de bien coder ton algo il peut toujours y avoir certains coûts cachés dans certaines constructions du langage.
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.
Le programme en C est beaucoup plus complèxe à ce niveau car toute la mémoire est gérée manuellement et le tout optimisé pour tenir en mémoire sur cette machine. Mais cela n'explique pas toute la différence de perfs.
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.
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.
Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
[^] # Re: sonntag
Posté par beagf . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
Pour ce qui est des algorithmes, ils sont déjà optimisés à mort, mais même avec les meilleurs algos, si tu les implémente comme un pieds tu obtiens un programme qui se trainne comme un bousin. Et même si tu fais gaffe de bien coder ton algo il peut toujours y avoir certains coûts cachés dans certaines constructions du langage.
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.
Le programme en C est beaucoup plus complèxe à ce niveau car toute la mémoire est gérée manuellement et le tout optimisé pour tenir en mémoire sur cette machine. Mais cela n'explique pas toute la différence de perfs.
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.
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.
Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...