Développeur : Flash player 8 recherche son ingénieur linux
Posté par tectonik (). Modéré le 23 septembre 2005.
Tinic Uro, le développeur principal du Flash Player explique dans son blog son ambition de faire un portage propre de l'application, et toute la complexité que représentera ce travail ; pour résumer, il faut prendre en compte les différentes bibliothèques pour le son, l'affichage, les fontes, la multiplicité des plateformes (x86, mais aussi PPC, x86-64), tenir compte de la différence des compilateurs gcc et Intel, etc. Le blog de Tinic Uro rentre dans les détails et propose même des bouts de code pour mieux comprendre la problématique.
![[en]](../images/en.png)
Article de Tinic Uro : Porting the Flash Player to 'alternative' platforms (2769 hits)-
Annonce de Macromedia: Principal Software Engineer, Flash Player for Linux (943 hits)
![[fr]](../images/fr.png)
DLFP : Flash Player 7 pour Linux disponible (1177 hits)-
Alternatives libres (703 hits)
-
DLFP : Logiciels libres et contenus web interactifs (462 hits)
> Lire la dépêche (82 commentaires, moyenne: 3,7).
Vous avez demandé le commentaire #629114.
Run by 
Cette page a été générée par Templeet en 0.0558s (dont 0.006 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
dites
commentaire de quelqu'un qui n'a jamais fait du C que dans ses études (et vraiment pas beaucoup) :
On est encore obligé de jouer de l'assembleur dès qu'on veut utiliser des choses multimédia efficacement ? de faire de l'assembleur pour utiliser mmx/sse ?
Personne n'a encore fait de compilo assez intelligent pour utiliser mmx/sse tout seul ? de bibliothèque assez bien foutue pour lancer des fonction multimédia sans tomber dans de l'assembleur ?
C'est surtout ça moi qui m'étonne.
[^]Re: dites
> On est encore obligé de jouer de l'assembleur dès qu'on veut utiliser des choses multimédia efficacement ?
De mon experience (limitée), non. Avec gcc, les "intrinsics" (les fonctions _mm_add_ps etc) produisent du très bon code. Par contre quand j'ai essayé de compiler le même code avec msvc 2003, les perf ont été divisées par deux, donc je pense que quand il dit "Please note that we can't use intrinsics on x86 since they generate extremly slow code" il parle de msvc, pas de gcc. Honnetement je serais à leur place je switcherais tout sous gcc: xcode pour macos, mingw pour windows, et gcc pour le reste :)
> Personne n'a encore fait de compilo assez intelligent pour utiliser mmx/sse tout seul ?
icc est censé savoir le faire, pour gcc c'est en cours mais je ne pense pas qu'il faille en attendre des miracles, le compilateur est obligé de deviner trop de choses: l'alignement des trucs, est-ce que ça aliase ou pas, et surtout il n'y a pas de moyen de lui dire "ça c'est LA boucle où on va passer 95% du temps je me que tu me l'optimise à bloc"
[^]Re: dites
> et surtout il n'y a pas de moyen de lui dire "ça c'est LA boucle où on va passer 95% du temps je me que tu me l'optimise à bloc"
le --fprofile-arcs et ses amis de gcc servent à ca. L'idée est simple, sans aide un compilateur aura beaucoup de mal a savoir si la branche if ou else a plus de chance d'être exécutée. On peut demander au programmeur d'annoter son code mais c'est lourd et souvent le programmeur n'en sait trop rien voir se trompe.
L'idée de générer un premier exécutable non optimisé avec le profiling activé pour ensuite se reservir des informations d'exécution pour recompiler le programme est très bonne.
Au passage si un compilateur sait optimiser a bloc du code ca coute pas plus cher de tout optimiser à bloc. On est pas en train de payer un ingé expert à la minute pour le faire :-)
[^]Re: dites
> L'idée de générer un premier exécutable non optimisé avec le profiling activé pour ensuite se reservir des informations d'exécution pour recompiler le programme est très bonne.
Mais en pratique c'est assez lourd à mettre en oeuvre, du coup c'est peu utilisé, et comme c'est peu utilisé ça marche mal (y'a des bugreports où gcc optimise moins bien avec le profile feedback que sans). Pour les branches if on peut déjà annoter avec __builtin_expect mais je n'ai jamais vu de difference sensible (sur x86).
Perso je prefere largement annoter le code, c'est quand même pas bien dur de savoir quels sont les quelques points chauds du programme.
> Au passage si un compilateur sait optimiser a bloc du code ca coute pas plus cher de tout optimiser à bloc.
ça coute en temps de compilation!
[^]Re: dites
Perso je prefere largement annoter le code, c'est quand même pas bien dur de savoir quels sont les quelques points chauds du programme.
C'est possible avec gcc (de signaler les parties de code nécéssitant une meilleur optim) ?
Comment fait-on ?
[^]Re: dites
> C'est possible avec gcc (de signaler les parties de code nécéssitant une meilleur optim) ?
Pas a ma connaissance. Tu actives les options globalement ou pas du tout.
Par contre il existe un petit nombre de mots magiques pour l'aider par exemple __builtin_expect qui permet d'indiquer quelle branche sera la plus probablement utilisée (les likely/unlikely de linux viennent de la), _builtin_prefetch pour charger des adresses en cache.
Il y en a peut être d'autres.
[^]Re: dites
Avec gcc tu peux aussi des vecteurs et faire des operations vectorielle dessus. De plus MMX, SSE, ... sont sense etre automatiquement utiliser si tu passe les bons flags.
Mais du peu que j'ai testé, ca reste assez loin d'un code optimise a la main...