Et gcc?

• [^]Re: Et gcc?

  Posté par Jerome Demeyer () le 02/01/2002 à 15:46. (lien). Évalué à 2.

  Ce n'est pas au compilateur de "paralleliser" le code, c'est au programmeur de le faire, en utilisant les threads (light ou pseudo ou autres). C'est ensuite l'OS qui va paralleliser les threads sur les différents CPU.

  • [^]Re: Et gcc?

    Posté par kalahann () le 02/01/2002 à 17:06. (lien). Évalué à 3.

    Je me demande s'il ne parlais pas de pipelining plutôt que de multitheading... De toute façon la question est bizarre.

  • [^]Ca dépend :-)

    Posté par reno () le 02/01/2002 à 22:47. (lien). Évalué à 8.

    J'ai "presque" fait un thése sur un compilateur parallélisant.
    
    Certains compilateurs sont capables d'extraire certains type de parallélisme tout seul comme des grands, mais pour extraire plus de parallélisme, l'intervention d'un programmeur peut aider.
    
    Pour autant que je sache, gcc n'est pas capable d'extraire automatiquement du parallélisme.
    
    Il n'y a pas un parallélisme mais plusieurs type, par exemple: les threads, les vecteurs (ex 3DNow! ou MMW/SSE), le pipeline.

    • [^]Re: Ca dépend :-)

      Posté par Christophe Nowicki (Jabber id, page perso, ) le 02/01/2002 à 23:50. (lien). Évalué à 4.

      Donc gcc n'est pas "capable" de parallelise les instruction dans les pipeline de mon proc :(
      Et quant est il des projets tel que PentiumGCC ? (qui est abondonner depuis pas mal de temps ...)
      Car je me souviens avoir reussi a compiler un noyau 2.2 avec ce compilo et gagner pas mal en perf :)
      
      PS : desoler je parler de pipelining dans le commentaire precedant :))

    • [^]Re: Ca dépend :-)

      Posté par Henri () le 03/01/2002 à 04:51. (lien). Évalué à 7.

      Oui justement. Et malheureusement au point de vue des performances pures, gcc tient rarement la comparaison...
      Au niveau de la parallélisation, c'est du côté de PGI qu'il faut chercher (http://www.pgroup.com(...)). Sinon, d'une façon générale, il existe pour linux icc (d'Intel) avec une licence de merde (on est loin du libre), des rpms uniquement mais les résultats sont éloquents : +-20% de gagnés en moyenne, et parfois beaucoup plus dès que le code n'est pas optimal (car certaines optimisations sont faites automatiquement).

      • [^]Re: Ca dépend :-)

        Posté par Silence (page perso, ) le 03/01/2002 à 16:30. (lien). Évalué à 1.

        J'utilise le flag -march=k6 pour compiler sur mon k6 c'est deja ca ! Savez vous ce que fait ce flag ?
        Quelqu'un sait si AMD prepare un patch pour gcc ? histoire d'ameliorer les perf sur les k6/k7

        --
        ^d^c

        • [^]Re: Ca dépend :-)

          Posté par Stone Tramo () le 03/01/2002 à 17:04. (lien). Évalué à 3.

          Pour les athlon(et duron), il existe AthlonGCC http://hannah.ipc.miyakyo-u.ac.jp/kim/Linux/AthlonGCC.html(...) Il est fait par Kimura Takuhiro qui a fait fait les optimisations 3dnow! pour xmms et mpg123. Sa derniere maj date un peu(mai).
          
          Dans la branche officielle de gcc, il y a avait des optimisations pour athlon, mais il n'etait pas pret pour la sortie de la 3.0 et il est prevu pour qu'il soit intégré dans la 3.1.

Lien

C'est mieux comme ça...

• [^]Re: C'est mieux comme ça...

  Posté par Jerome Demeyer () le 02/01/2002 à 21:40. (lien). Évalué à 3.

  Le patche pour rendre le noyau pré-emptible ne doit pas et -j'espère- ne sera pas intégré au noyau standard.
  
  A quoi sert ce patche ? à assurer des temps de réponses très rapides aux applications qui en ont besoin, ceci par une modification du scheduler.
  
  Ainsi, on peut par exemple faire de l'acquisition et du montage video/son dans d'excellentes conditions.
  
  Par contre, ce patche implique un nombre beaucoup plus élevé de changement de contextes, ce qui signifie que si tu as beaucoup de processes qui tournent en meme temps sur ta bécane, l'ensemble du système sera fortement ralenti.
  
  C'est pour cette raison que c'est un patche et que cela doit le rester. Linux sert plus comme serveur à tout faire que comme station de montage vidéo.
  
  Si ce n'est plus un patche, ce doit être au plus une option du noyau.

  • [^]Re: C'est mieux comme ça...

    Posté par Gaël Le Mignot (page perso, ) le 03/01/2002 à 01:16. (lien). Évalué à 8.

    1/ Le patch ne modifies pas le sheduler, mais rend le code s'exécutant en mode noyau interruptible au même titre que le code user-space;
    2/ Oui, il augmente la fréquence des changements de contexte, mais ce n'est pas son but. Si tu veux modifier la fréquence des changements, tu changes les #define sur le timeslice. Le but là est d'éviter qu'une appli qui a épuisé son temps puisse garder parce qu'elle s'exécute en mode noyau; cela n'a rien à voir.
    3/ Le patch se contente de rajouter une option de compile (CONFIG_PREEMPT) qui est désactivée par défaut, donc intégrer le patch au noyau ne vaut pas dire qu'il soit activé par défaut.