A priori non, car la tension varie en fonction de l'horloge.
Quand a la strategie du race to idle, il faut qu'il n'y ait rien qui ne se mette en travers du CPU. Hors il est tres tres difficile d'avoir une tache qui n'est pas memorie bound. Resultat si tu peux, et c'est le cas sur pas mal de tache, diviser le boulot entre 4 coeurs qui tourneront a frequence plus faible qu'un unique coeur qui tournera a frequence maximum, tu gagnes en batterie. Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. Le probleme, c'est qu'a ce moment la, c'est la memoire qui ne suit plus et tu te retrouves a prendre au tant de temps qu'avant, sauf que tu as 4 coeurs qui tournent dans le vide une bonne partie du temps. Le principal probleme vient de la bande passante memoire qu'un unique coeur peut saturer assez facilement sur quasiment toutes les operations.
Pour la blague, on fait de la compression RLE des glyphs pour gagner sur la bande passante memoire. On gagne 30% de performances sur le rendu du texte et un peu plus de 10% en terme de gain sur la batterie. On fait faire plus au processeur, mais il attend alors moins longtemps avant d'aller roupiller. Sans compter qu'en accedant moins au sous-systeme memoire, on diminue aussi la consomation, car chaque niveau a un cout d'acces energetique superieur. Ah, et c'est chiffre sont sans optimisation de type vectorisation pour l'instant. Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur...
[^] # 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é à 4.
A priori non, car la tension varie en fonction de l'horloge.
Quand a la strategie du race to idle, il faut qu'il n'y ait rien qui ne se mette en travers du CPU. Hors il est tres tres difficile d'avoir une tache qui n'est pas memorie bound. Resultat si tu peux, et c'est le cas sur pas mal de tache, diviser le boulot entre 4 coeurs qui tourneront a frequence plus faible qu'un unique coeur qui tournera a frequence maximum, tu gagnes en batterie. Ton point etant que quitte a avoir 4 coeurs qui tournent, autant les faire aller le plus vite possible. Le probleme, c'est qu'a ce moment la, c'est la memoire qui ne suit plus et tu te retrouves a prendre au tant de temps qu'avant, sauf que tu as 4 coeurs qui tournent dans le vide une bonne partie du temps. Le principal probleme vient de la bande passante memoire qu'un unique coeur peut saturer assez facilement sur quasiment toutes les operations.
Pour la blague, on fait de la compression RLE des glyphs pour gagner sur la bande passante memoire. On gagne 30% de performances sur le rendu du texte et un peu plus de 10% en terme de gain sur la batterie. On fait faire plus au processeur, mais il attend alors moins longtemps avant d'aller roupiller. Sans compter qu'en accedant moins au sous-systeme memoire, on diminue aussi la consomation, car chaque niveau a un cout d'acces energetique superieur. Ah, et c'est chiffre sont sans optimisation de type vectorisation pour l'instant. Il faut encore qu'on fasse le port NEON. Oui, l'implementation C d'un blit de glyph en RLE est plus performante qu'un blit vectorise en assembleur...