De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. Le principale probleme, c'est que compare a toute la tripote de MMX, SSE et compagnie du x86, NEON est assez pauvre et manque souvent de fonctionalites qui le rendent moins utile. Mais le point important, c'est qu'un blit d'un glyph en 8bits optimise en assembleur vectorise est plus lent que du code qui fait du blit d'un glyph compresse en RLE code en C (optimise aussi, mais pas autant).
Cela veut dire que l'on est clairement memory bound sur ce genre d'operation. En fait, ce n'est pas la premiere optimisation qui en reduisant notre consomation memoire resulte en une amelioration de nos performances. Nous avons fait de la deduplication de chaine de characteres et de structure C en memoire pour diminuer notre consomation memoire, mais, au final, nous avons gagne plus de 10% de performance de rendu. On en est a ce demander si ca ne vaut pas le cout de compresse en RLE certaine de nos resources graphiques. Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser.
[^] # Re: Mouais
Posté par cedric . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 3.
De maniere generale, on arrive a rendre du code vectorise avec NEON plus rapide qu'en C. Le principale probleme, c'est que compare a toute la tripote de MMX, SSE et compagnie du x86, NEON est assez pauvre et manque souvent de fonctionalites qui le rendent moins utile. Mais le point important, c'est qu'un blit d'un glyph en 8bits optimise en assembleur vectorise est plus lent que du code qui fait du blit d'un glyph compresse en RLE code en C (optimise aussi, mais pas autant).
Cela veut dire que l'on est clairement memory bound sur ce genre d'operation. En fait, ce n'est pas la premiere optimisation qui en reduisant notre consomation memoire resulte en une amelioration de nos performances. Nous avons fait de la deduplication de chaine de characteres et de structure C en memoire pour diminuer notre consomation memoire, mais, au final, nous avons gagne plus de 10% de performance de rendu. On en est a ce demander si ca ne vaut pas le cout de compresse en RLE certaine de nos resources graphiques. Globalement, le seul moyen d'ameliorer les performances que nous voyons maintenant, c'est de trouver ce que l'on peut encore dedupliquer et ce que l'on peut compresser.