Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de patrick_g :
- [13/05@13:39] Télécharger sur le net = torturer des irakiens ?
- [07/05@11:47] le mémo de Bush déchiffré par des cryptologues
- [07/05@07:47] Intel fait sa révolution !
- [28/04@12:19] Si vous étiez riches ..très riches !
- [26/04@09:57] Pas de Windows pour les astronomes !
- [23/04@14:56] 100 Ghz.....pour écrire son CV ?
- [20/04@08:06] Lindows ou Linspire....c'est des plagieurs !
- [16/04@07:51] après la sarge
- [05/04@07:56] docs Gnome 2.6 en français ?
- [25/03@11:09] Marre des trolls politiques sur DLFP !
- [16/03@16:34] hors-sujet sur Jünger
- [12/03@13:09] Je suis un drogué !
- [10/03@11:03] La France malade de ses comptes publics : un dossier qui fait peur !
- [05/03@16:13] L'administration Bush restreint la liberté des revues scientifiques
- [04/03@13:47] componentized linux....quézaco ?????
- [01/03@15:24] Un nouveau KControl pour KDE ?
- [27/02@12:28] La france c'est pas terrible...mais c'est toujours mieux qu'ailleurs !
- [25/02@12:35] troll économique et politique (vous êtes prévenus ;-)
- [25/02@10:03] Que pensez-vous du nouveau file selector de Gnome ?
- [23/02@15:39] KDE 3.2 sur arstechnica
Elle est vraiment très puissante par rapport aux processeurs X86....mais je me pose une petite question sur sa prise en compte sous GNU/Linux.
Autant je suis certain que OSX utilise à fond cette unité autant j'ai de gros doutes pour les distribs Linux.
Pour utiliser GNU/Linux sur un PPC y'a pas 36 choix :
- Yellow Dog n'évoque nulle part sur son site une quelconque optimisation Altivec
- Debian propose des paquets PPC et donc je pense que c'est le plus petit dénominateur sans prise en compte d'Altivec
- Gentoo propose de compiler ses paquets mais existe-il du code vectoriel Altivec dans le source ?
Il faudrait quoi pour une prise en compte correcte ? que les libs multimedia genre Gstreamer soit optimisées ? et le kernel ça compte ?
Est-ce que c'est envisageable des codes du genre :
IF PPC-Altivec
THEN code_vectoriel_de_la_mort_qui_tue
ELSE code_classique_tout_lent
> Lire le journal (19 commentaires, moyenne: 1,8).
GCC?
C'est plutôt du côté du compilateur qu'il faille regarder je pense. Les optimisations se font à ce niveau, du moins en ce qui concerne les traitements de ce genre.
-
[^]Re: GCC?
Posté par kolter (page perso, ) le 13/05/2004 à 14:39. (lien). Évalué à 3.exact...
un thread sur la ML de gcc en parle : http://gcc.gnu.org/ml/gcc/2003-04/threads.html#00656(...)
en le parcourant en travers on découvre les options à passer à gcc pour le gérer.... après tu peux recompiler tous ce qui te chante.....
M.
-
[^]Re: GCC?
Posté par patrick_g (page perso, ) le 13/05/2004 à 14:41. (lien). Évalué à 2.ben tant que GCC ne saura pas vectoriser automatiquement il faudra optimiser à la mano cad prévoir du code assembleur altivec dans le source.
c'est exactement ce que je demande : est-ce que ce code existe sous linux ou non ?
avec un beau powerbook qui tourne sous un OSX super-optimisé avec pleins d'applis super-optimisées c'est quoi l'avantage de passer sous GNU/Linux pour un néophyte ? (outre la liberté)-
[^]Re: GCC?
Posté par Sylvain Briole (page perso, ) le 13/05/2004 à 16:04. (lien). Évalué à 1.ben tant que GCC ne saura pas vectoriser automatiquement il faudra optimiser à la mano cad prévoir du code assembleur altivec dans le source.
En effet : ou alors compiler avec aut' chose que GCC.
Puisque tu penses que le compilo de BSD de MacOSX supporte l'Activec, pourquoi ne pas tenter de compiler dans un premier temps avec lui pour tester?-
[^]Re: GCC?
Posté par Christophe Fergeau () le 13/05/2004 à 16:05. (lien). Évalué à 4.C'est gcc le compilo de macosx. Donc meme si apple l'a customisé, les sources modifiées devraient être qqpart...
-
-
[^]Re: GCC?
Posté par Loïs Taulelle (page perso, ) le 13/05/2004 à 18:32. (lien). Évalué à 1.c'est quoi l'avantage de passer sous GNU/Linux pour un néophyte ?
Avoir la même distribution sur toutes tes machines ?
(j'ai du Sparc32, Sparc64, x86-32 et PPC, partout du Debian,
je reste en terrain connu)
-
-
[^]Tout a fait thierry (tm)
Posté par TheBreton () le 13/05/2004 à 14:50. (lien). Évalué à 1.sur le site
http://www.findsabrina.org/altivec/(...)
un point de depart pour patcher le gcc3.3 de yellow dog pour la prise en charge de l'altivec.
une recompil de l'appli en question pour la prise en compte et hop...
recompiler le kernel directement est une mauvaise(idée pour moi) car je crois qu'il faut le patcher d'abord--
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )-
optimisations altivec sous Linux
La réponse est, en gros, oui à toutes tes dernières questions.
Pour utiliser l'altivec il faut un noyau qui le supporte (il le supporte, faut juste le cocher, mais je crois que le pmac_defconfig l'a précoché).
Ensuite, il faut passer des arguments à gcc, genre "-maltivec -mabi=altivec".
Enfin, il faut que le code source compilé contienne ces optimisations en assembleur. En effet gcc ne peut pas générer du code altivec "tout seul", il faut le lui faire. FFmpeg, par exemple, a des bouts de source optimisés altivec (voir http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/ppc/?(...) ).
Pour MacOS X, il me semble que c'est pareil, une appli doit implémenter de l'assembleur Altivec pour en profiter.
-
[^]Re: optimisations altivec sous Linux
Posté par twisla (page perso, ) le 13/05/2004 à 14:46. (lien). Évalué à 1.il existe en tout cas une variable USE à passer au make.conf de gentoo pour activer ce genre de choses, je suppose qu'il faut aller scruter les ebuilds pour voir ou cela peut avoir son utilité, n'ayant pas de PPC, je ne m'y suis jamais intéressé ...
"altivec Adds support for optimizations for G4 and G5/ppc970 processors "--
twisla
-
[^]Re: optimisations altivec sous Linux
Posté par patrick_g (page perso, ) le 13/05/2004 à 14:53. (lien). Évalué à 2.ok merci pour ta réponse.
en gros y'a quasi rien qui est prévu sur le plan des optimisations en assembleur dans les sources....
c'est lourd quand même je trouve car en passant sous nux on abandonne volontairement l'intégration et le coté "bien léché et bien intégré" de OSX....si en plus on perds en performance et on n'utilise plus que 50 % de son CPU ça fait mal !-
[^]Re: optimisations altivec sous Linux
Posté par TheBreton () le 13/05/2004 à 15:01. (lien). Évalué à 2.linux est portable et optimisable a volontée.
Il suffit juste que quelqu'un se penche la dessus et se bouge un peut pour faire la chose.
Forcement, si personne ne se bouge cela ne se feras pas.
sur le dev x86 de nombreuse optimisation et utilisation de particularité en asm sont faite. au possesseur de G3/4 de faire pareille dans le kernel tree ou dans gcc.--
Merde, ca fait trois fois que je le coupe il est toujours trop court!
-(un stagiaire hardware qui devait connaitre le grand pere de Sylvain Sauvage ;-) )--
[^]Re: optimisations altivec sous Linux
Posté par patrick_g (page perso, ) le 14/05/2004 à 07:36. (lien). Évalué à 1.d'accord sur le plan théorique....mais du point de vue du simple newbie utilisateur de base comme moi ce que je vois c'est :
OSX optimisé : OUI
OSX déja installé : OUI
OSX bien intégré : OUI
Linux optimisé :NON
Linux déja installé :NON
Linux bien intégré :NON
Faut avoir vraiment la foi en saint Stallman pour switcher je trouve....
Je sais bien que l'install c'est pas la faute des devs libres mais l'intégration et l'optimisation si.
-
-
[^]Re: optimisations altivec sous Linux
Posté par cedric () le 13/05/2004 à 15:04. (lien). Évalué à 1.Euh, tu es sure que ce n'est pas pareille pour la version MacOSX ? Parce que a part les filtres Photoshop et le lecteur multimedia, je vois pas trop ce qui peut-etre tant optimise que ca...
-
[^]Re: optimisations altivec sous Linux
Posté par Colin Leroy (page perso, ) le 13/05/2004 à 15:18. (lien). Évalué à 2.C'est ce que j'ai dit: il me semble que c'est pareil pour OSX ;-)
-
[^]Re: optimisations altivec sous Linux
Posté par patrick_g (page perso, ) le 14/05/2004 à 07:32. (lien). Évalué à 2.je crois que toute l'interface Quartz d'OSX profite d'altivec....c'est loin d'être négligeable !
-
-
-
[^]Re: optimisations altivec sous Linux
Posté par Christophe Fergeau () le 13/05/2004 à 15:23. (lien). Évalué à 4.> .si en plus on perds en performance et on n'utilise plus que 50 % de son CPU ça fait mal !
Faut pas rêver non plus et trop écouter apple. altivec (tout comme sse2 d'ailleurs) sur des algos très spécifiques (en particulier tout ce qui est traitement du signal, d'image, de matrices, ...) améliorera grandement les performances, mais c'est beaucoup moins versatile qu'un vrai proc et dans beaucoup de cas ça ne sert à rien.
-
[^]Re: optimisations altivec sous Linux
Posté par fmaz fmaz () le 13/05/2004 à 15:31. (lien). Évalué à 2.J'aimerai savoir ce qu'il en est vraiment.
D'après ce que j'ai compris, les noyaux macOS X sont des noyaux hybrides. C'est à dire qu'ils sont entre les micro-noyaux genre hurd et les noyaux monoblocs à la linux.
Toujours d'après ce que j'ai compris un micro noyau, c'est propre, c'est modulaire mais c'est lent car à chaque appel système, il y a beaucoup plus de changements de contexte que dans un noyau monobloc.
Bref au boulot, j'ai un superbe mac G4 mais je trouve qu'il rame. L'interface est rapide mais il est beaucoup plus lent que mon portable intel+linux. Je n'ai pas eu le courage de le passer sous linux pour juger de l'impact de la conception noyau.
Donc si tu fais l'essai, je suis intéressé pas d'éventuels retours.
-
[^]Re: optimisations altivec sous Linux
Posté par Sylvain Briole (page perso, ) le 13/05/2004 à 16:08. (lien). Évalué à 1.en gros y'a quasi rien qui est prévu sur le plan des optimisations en assembleur dans les sources....
Et c'est normal : normalement c'est le boulot du compilo ce genre de choses.
La seule partie assembleur qui doit être contenue dans le noyau, AMHA, c'est ce dont le noyau a besoin pour démarrer ou alors les pilotes de périphériques qui ne peuvent pas être codés autrement.
Le gros intérêt de déléguer ce genre de choses au compilo' réside dans le fait que ce dernier fera une optimisation globale, automatisée, dès qu'il verra que c'est possible, sur le code source. Alors que l'insertion sous forme "pragma" dans le code source du noyau impose au développeur de revoir tout le noyau (je ne sais pas si tu as vu la quantité de sources...) pour voir où c'est implémentable (francais?)....
-
Cette page a été générée par Templeet en 0.1059s (dont 0.0199 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.