Oui, mais sur quel CPU ? Sur A8, je n'en doute pas, sur A9, c'est moins évident.
Le A8 n'est pas multiprocesseur :-) Donc on parle bien des generations apres le A8.
Vous triez déjà les champs des structures de données par ordre décroissant de taille pour éviter le padding ?
Ca, ca fait des annees que l'on fait ca ! C'est un peu la base. On en est a faire de la deduplication de structure entre objet pour limiter la consomation memoire. Une espece de copy on write de certaine partie d'une structure en C avec un garbage collector qui utilise une table de hash pour trouver qui ressemble a qui et merger tout le monde on-idle.
Vous pouvez aussi mettre en place du tiling, c'est à dire de changer l'ordre des opérations pour que les données utiles restent dans le cache le plus longtemps possible (travailler par texture et non par coordonnés d'écran par exemple, etc...).
On fait deja ca, meme en OpenGL, pour reordonneer les operations et rester en cache (ou limiter les switch de context en OpenGL).
Sinon, je croyais qu'un des avantages des images vectorielles étaient justement la faible empreinte mémoire, remplacé par du temps cpu.
Le probleme etant que le temps de generation devient bien trop important et que la somme de code necessaire pour generer une image est aussi problematique. Il faut trouver un equilibre entre le niveau de compression, la somme de code que cela necessite pour faire la decompression, la bande passante memoire utilise et la puissance CPU necessaire pour cela.
Le RLE se code assez facilement en inline pour la decompression. Globalement, c'est "juste" une expansion d'une valeur. En ajoutant une table de saut en entete pour faciliter le saut a une ligne precise, tu te retrouves avec un code un peu complexe, mais pas impossible a maintenir et sans impact important sur la masse de code traverse. Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard...
[^] # 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é à 2.
Le A8 n'est pas multiprocesseur :-) Donc on parle bien des generations apres le A8.
Ca, ca fait des annees que l'on fait ca ! C'est un peu la base. On en est a faire de la deduplication de structure entre objet pour limiter la consomation memoire. Une espece de copy on write de certaine partie d'une structure en C avec un garbage collector qui utilise une table de hash pour trouver qui ressemble a qui et merger tout le monde on-idle.
On fait deja ca, meme en OpenGL, pour reordonneer les operations et rester en cache (ou limiter les switch de context en OpenGL).
Le probleme etant que le temps de generation devient bien trop important et que la somme de code necessaire pour generer une image est aussi problematique. Il faut trouver un equilibre entre le niveau de compression, la somme de code que cela necessite pour faire la decompression, la bande passante memoire utilise et la puissance CPU necessaire pour cela.
Le RLE se code assez facilement en inline pour la decompression. Globalement, c'est "juste" une expansion d'une valeur. En ajoutant une table de saut en entete pour faciliter le saut a une ligne precise, tu te retrouves avec un code un peu complexe, mais pas impossible a maintenir et sans impact important sur la masse de code traverse. Ce n'est bien entendu pas le cas avec le SVG qui est tellement complexe qu'il te faut une VM Javascript pour couvrir tout le standard...