Diagrammes parallèles de mise à l'échelle / efficacité log-log

Une grande partie de mon propre travail consiste à améliorer la mise à l'échelle des algorithmes, et l'une des façons préférées de montrer la mise à l'échelle parallèle et / ou l'efficacité parallèle est de tracer les performances d'un algorithme / code sur le nombre de cœurs, par exemple

où l' axe représente le nombre de cœurs et l' axe une métrique, par exemple le travail effectué par unité de temps. Les différentes courbes montrent des rendements parallèles de 20%, 40%, 60%, 80% et 100% à 64 cœurs respectivement.$x$$y$

Malheureusement, dans de nombreuses publications, ces résultats sont tracés avec une échelle log-log , par exemple les résultats dans ce ou cet article. Le problème avec ces tracés log-log est qu'il est extrêmement difficile d'évaluer la mise à l'échelle / efficacité parallèle réelle, par exemple

C'est le même tracé que ci-dessus, mais avec une mise à l'échelle log-log. Notez qu'il n'y a plus de grande différence entre les résultats pour une efficacité parallèle de 60%, 80% ou 100%. J'ai écrit un peu plus à ce sujet ici .

Voici donc ma question: quelle justification y a-t-il pour afficher les résultats de la mise à l'échelle log-log? J'utilise régulièrement la mise à l'échelle linéaire pour montrer mes propres résultats, et je suis régulièrement martelé par les arbitres qui disent que mes propres résultats de mise à l'échelle parallèle / efficacité ne sont pas aussi bons que les résultats (log-log) des autres, mais pour la vie de moi, je ne vois pas pourquoi je devrais changer de style de tracé.

Nous écrivons actuellement un document qui contient un certain nombre de parcelles comparables, et nous avons plus ou moins eu le même problème. L'article porte sur la comparaison de la mise à l'échelle de différents algorithmes sur le nombre de cœurs, qui varie entre 1 et jusqu'à 100k sur un BlueGene. La raison de l'utilisation de loglog-plot dans cette situation est le nombre d'ordres de grandeur impliqués. Il est impossible de tracer 6 ordres de grandeur sur une échelle linéaire.

Et en effet, lors du traçage de l'heure sur le nombre de cœurs dans le journal des événements, les algorithmes ne sont pas très distinguables, comme vous pouvez le voir dans le graphique suivant.

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

Le traçage de l'efficacité parallèle relative sur une échelle de semi-journal montre assez clairement la mise à l'échelle d'un algorithme et montre également comment les algorithmes fonctionnent relativement les uns par rapport aux autres.

Georg Hager a écrit à ce sujet dans Fooling the Masses - Stunt 3: L'échelle logarithmique est votre ami .

S'il est vrai que les tracés log-log de mise à l'échelle forte ne sont pas très exigeants sur le haut de gamme, ils permettent de montrer la mise à l'échelle sur de nombreux autres ordres de grandeur. Pour voir pourquoi cela est utile, considérons un problème 3D avec un raffinement régulier. Sur une échelle linéaire, vous pouvez raisonnablement afficher les performances sur environ deux ordres de grandeur, par exemple 1024 cœurs, 8192 cœurs et 65536 cœurs. Il est impossible pour le lecteur de dire à partir de l'intrigue si vous avez exécuté quelque chose de plus petit, et de manière réaliste, l'intrigue compare principalement les deux plus grandes séries.

Supposons maintenant que nous pouvons adapter 1 million de cellules de grille par cœur en mémoire, cela signifie qu'après une forte mise à l'échelle deux fois par un facteur de 8, nous pouvons toujours avoir 16 000 cellules par cœur. C'est toujours une taille de sous-domaine importante et nous pouvons nous attendre à ce que de nombreux algorithmes s'exécutent efficacement là-bas. Nous avons couvert le spectre visuel du graphique (1024 à 65536 cœurs), mais nous ne sommes même pas entrés dans le régime où une mise à l'échelle forte devient difficile.

Supposons plutôt que nous commencions avec 16 cœurs, également avec 1 million de cellules de grille par cœur. Maintenant, si nous passons à 65536 cœurs, nous n'aurons que 244 cellules par cœur, ce qui sera beaucoup plus exigeant. Un axe logarithmique est le seul moyen de représenter clairement le spectre de 16 cœurs à 65536 cœurs. Bien sûr, vous pouvez toujours utiliser un axe linéaire et avoir une légende disant "les points de données pour 16, 128 et 1024 coeurs se chevauchent dans la figure", mais maintenant vous utilisez des mots au lieu de la figure elle-même pour afficher.

Une échelle log-log permet également à votre évolutivité de "récupérer" des attributs de la machine, comme le déplacement au-delà d'un seul nœud ou rack. C'est à vous de décider si cela est souhaitable ou non.

Je suis d'accord avec tout ce que Jed avait à dire dans sa réponse, mais je voulais ajouter ce qui suit. Je suis devenu un fan de la façon dont Martin Berzins et ses collègues montrent la mise à l'échelle pour leur cadre Uintah. Ils tracent la mise à l'échelle faible et forte du code sur les axes log-log (en utilisant le temps d'exécution par étape de la méthode). Je pense que cela montre comment le code évolue assez bien (bien que l'écart par rapport à une mise à l'échelle parfaite soit un peu difficile à déterminer). Voir page 7 et 8 figures 7 et 8 de ce * papier par exemple. Ils donnent également un tableau avec les nombres correspondant à chaque chiffre de mise à l'échelle.

Un avantage de ceci est qu'une fois que vous avez fourni les chiffres, il n'y a pas grand-chose qu'un critique peut dire (ou du moins pas beaucoup que vous ne pouvez pas réfuter).

* J. Luitjens, M. Berzins. «Improving the Performance of Uintah: A Large-Scale Adaptive Meshing Computational Framework», dans les actes du 24e IEEE International Parallel and Distributed Processing Symposium (IPDPS10), Atlanta, GA, pp. 1--10. 2010. DOI: 10.1109 / IPDPS.2010.5470437