Si on ne parle pas d'API, cela veut dire qu'on parle uniquement de comparer un systeme qui utilise des locks vs un systeme qui utilise une queue. Dans le cas, qui nous concerne, pour l'implementation de fyne, il n'y a pas de data race, pas d'allocation, et les locks ne sont pas sous contention et donc se comporte comme deux appels atomics successif par lecture/ecriture sur le meme CPU. Techniquement, cela veut dire que le premier atomic va, en pire cas, declencher un vidage de cache dans les autre core du CPU pour obtenir la propriete de la memoire pointe par l'acces atomique. Comme il n'y a pas de contention, aucun autre CPU ne declenchera une perte du cache du core et le second acces sera equivalent a un acces memoire directe sans cout particulier. Ce sera cela le cout d'un lock dans ce scenario.
Maintenant, si tu prend une queue ideale, tu peux te retrouver avec une implementation qui a un seul appel a un atomic par ecriture/lecture dans la queue (CAS ou atomic sont equivalent en terme de cout, donc pas tres important). Par contre, tu es oblige d'allouer de la memoire ou de travailler de maniere bloquante. Dans le cas ideal, disons que tu pars du principe qu'il n'y a pas de contention non plus sur les acces a ta queue et que tu peux te permettre d'avoir juste une seule entree, donc pas non plus de probleme d'allocation memoire. Tu te retrouve exactement dans le cas precedent, un atomic pour faire l'ecriture avec une perte de cache dans les autres core. Par contre par design, tu as probablement plus de chance, comme tu as plus de thread dans ce design, de te retrouver avec la requete d'acces suivante sur un autre core et donc declenche une perte de cache.
Au final, un lock vs une queue dans le cas sans contention sont au mieux equivalent au pire au desaventage d'une queue. Maintenant si on n'est plus dans le cas sans contention, mais dans un cas avec contention, ce que je viens de dire n'est plus valable et le profile de performance sera different. Mais dans le cas de Fyne, il n'y a pas de contention du fait de l'API et de son usage.
Pour ce qui est de la copie c'est dommage. Je ne sais pas ce qu'il y a comme possibilité de réflexion et comme rtti pour pouvoir copier simplement. Une autre possibilité serait d'avoir un proxy qui donne une vue en lecture seule de la structure qu'il proxifie. Après ce n'est pas une obligation vuex ne fait pas ça et fais confiance à l'utilisateur.
Pour revenir sur le sujet du deep copie, c'est bien parce que quoi qu'on fasse, c'est une operation couteuse dans tous les languages et qu'il vaut mieux l'eviter autant que possible. De maniere generale, la contrainte, c'est toujours la bande passante memoire, un seul core peut facilement saturer toute ta bande passante memoire et il faut y faire attention. En forcant le developpeur a etre conscient des couts sans cacher les operations, le go renforce cette affirmation. Et reflexion et rtti sont des operations encore plus lente qu'il vaut mieux eviter en generale. Pas uniquement en go, mais dans tous les languages.
Pour ce qui est du proxy, c'est une possibilite. Mais franchement quel est le probleme que tu essaie de resoudre? Le systeme garde deja pour toi une copie des etats graphiques (uniquement ce qui a finit a l'ecran). Pas la peine de garder l'ensemble des widgets et d'en faire une copie si ceux ci ne finissent pas sur l'ecran. La memoire du delta ne sert pas a grand chose pour ca. Je pense qu'il y a un biais dans ta reflexion du a la mechanique utilise par les navigateurs web pour faire leur rendu. Ceux-ci sont bien plus proche des systemes de rendu immediat du fait de la complexite historique de leur tache. Du coup, on a rajoute des framework en JS pour essayer d'aider les navigateurs web a faire leur boulot. Ce n'est pas un probleme pour les toolkits natifs et c'est globalement devenu un standard de faire du "retained" pour la majorite d'entre eux. Il n'y a pas de besoin pour les utilisateurs de se poser se genre de problematique. Les API pour modifier les widgets sont en O(1) et le systeme ne fera un calcul de delta entre frame que lorsqu'une nouvelle frame pourra etre pousse a l'ecran.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Si on ne parle pas d'API, cela veut dire qu'on parle uniquement de comparer un systeme qui utilise des locks vs un systeme qui utilise une queue. Dans le cas, qui nous concerne, pour l'implementation de fyne, il n'y a pas de data race, pas d'allocation, et les locks ne sont pas sous contention et donc se comporte comme deux appels atomics successif par lecture/ecriture sur le meme CPU. Techniquement, cela veut dire que le premier atomic va, en pire cas, declencher un vidage de cache dans les autre core du CPU pour obtenir la propriete de la memoire pointe par l'acces atomique. Comme il n'y a pas de contention, aucun autre CPU ne declenchera une perte du cache du core et le second acces sera equivalent a un acces memoire directe sans cout particulier. Ce sera cela le cout d'un lock dans ce scenario.
Maintenant, si tu prend une queue ideale, tu peux te retrouver avec une implementation qui a un seul appel a un atomic par ecriture/lecture dans la queue (CAS ou atomic sont equivalent en terme de cout, donc pas tres important). Par contre, tu es oblige d'allouer de la memoire ou de travailler de maniere bloquante. Dans le cas ideal, disons que tu pars du principe qu'il n'y a pas de contention non plus sur les acces a ta queue et que tu peux te permettre d'avoir juste une seule entree, donc pas non plus de probleme d'allocation memoire. Tu te retrouve exactement dans le cas precedent, un atomic pour faire l'ecriture avec une perte de cache dans les autres core. Par contre par design, tu as probablement plus de chance, comme tu as plus de thread dans ce design, de te retrouver avec la requete d'acces suivante sur un autre core et donc declenche une perte de cache.
Au final, un lock vs une queue dans le cas sans contention sont au mieux equivalent au pire au desaventage d'une queue. Maintenant si on n'est plus dans le cas sans contention, mais dans un cas avec contention, ce que je viens de dire n'est plus valable et le profile de performance sera different. Mais dans le cas de Fyne, il n'y a pas de contention du fait de l'API et de son usage.
Pour revenir sur le sujet du deep copie, c'est bien parce que quoi qu'on fasse, c'est une operation couteuse dans tous les languages et qu'il vaut mieux l'eviter autant que possible. De maniere generale, la contrainte, c'est toujours la bande passante memoire, un seul core peut facilement saturer toute ta bande passante memoire et il faut y faire attention. En forcant le developpeur a etre conscient des couts sans cacher les operations, le go renforce cette affirmation. Et reflexion et rtti sont des operations encore plus lente qu'il vaut mieux eviter en generale. Pas uniquement en go, mais dans tous les languages.
Pour ce qui est du proxy, c'est une possibilite. Mais franchement quel est le probleme que tu essaie de resoudre? Le systeme garde deja pour toi une copie des etats graphiques (uniquement ce qui a finit a l'ecran). Pas la peine de garder l'ensemble des widgets et d'en faire une copie si ceux ci ne finissent pas sur l'ecran. La memoire du delta ne sert pas a grand chose pour ca. Je pense qu'il y a un biais dans ta reflexion du a la mechanique utilise par les navigateurs web pour faire leur rendu. Ceux-ci sont bien plus proche des systemes de rendu immediat du fait de la complexite historique de leur tache. Du coup, on a rajoute des framework en JS pour essayer d'aider les navigateurs web a faire leur boulot. Ce n'est pas un probleme pour les toolkits natifs et c'est globalement devenu un standard de faire du "retained" pour la majorite d'entre eux. Il n'y a pas de besoin pour les utilisateurs de se poser se genre de problematique. Les API pour modifier les widgets sont en O(1) et le systeme ne fera un calcul de delta entre frame que lorsqu'une nouvelle frame pourra etre pousse a l'ecran.