Journal eclipse et kernel 2.6

Posté par Nicolas Antoniazzi (site web personnel) le 23 septembre 2003 à 02:20.

Étiquettes : aucune

sept.

2003

Je ne sais pas si parmis-vous il y a des utilisateur d'eclipse, un puissant IDE de dévelopement... Mais depuis le début, il y a un truc qui est assez ennuyeux avec ce programme... C'est qu'il tourne très bien sous windows... mais par contre, sous linux, il est assez mou.

Etant donné que tout est codé en Java, on peut se dire que ca vient de la machine virtuelle, pourtant les dévelopeurs pensent que ca vient de l'implémentation des threads dans linux.
Comme c'est quelque chose qui touche au kernel, je voulais savoir si des personnes qui utilisent eclipse et qui ont par la même occasion compilé un kernel 2.6, ont vu une amélioration sur la réactivité de cet IDE sous linux.

D'une manière ou d'une autre, je l'utilise toujours ... mais bon, ca serait bien si l'ouverture des fenetres pouvait répondre dès le clic de souris, et pas 1 secondes apres.... Surtout que c'est possible, vu que sous windows ca trace.

Sinon, pour les personnes interessé par le plugin C/C++ (CDT) il commence à prendre forme en intégrant un gestionnaire de création de Makefile et de trucs dans ce genre... Et l'indexer/parser qui sert a la completion est quasiment opérationel

# Re: eclipse et kernel 2.6

Posté par Edouard Gomez (site web personnel) le 23 septembre 2003 à 03:26. Évalué à 2.

En effet les Posix Threads sous Linux (LinuxThreads intégrés à la GNU Libc version >= 2.0 iirc) sont en effet un peu mauvais. Avec le noyau 2.6, tout change, l'arrivée des futex (des _f_ast m_utex_) a rendu possible une nouvelle implémentation des POSIX Threads, d'une part conforme au standard, et d'autre part bien plus rapide :-)

Si tu regardes sur kerneltrap.org et que tu fouilles un peu les archives tu devrais trouver les résultats postés par Ingo Molnar, qui je crois est le codeur qui a fait tout le travail sur le scheduler O(1) du 2.5/2.6 et les futex qui ont rendu possible la librairie NPTL. A noter que les dernières Red Hat intègrent les futex/NPTL et doivent deja beneficier d'un gain substantiel de perfs pour les programmes fortement threadés... enfin toute incompatibilité mise a part etant donné que les LinuxThreads permettaient des choses pas très standard et que certains programmes en tiraient parti.
- [^] # poxix vs clone
  
  Posté par free2.org le 23 septembre 2003 à 08:58. Évalué à 1.
  
  il s'agit bien probablement d'un problème de posix threads, qui devrait être réglé sous 2.6
  
  sinon Linux a depuis longtemps ses propres threads non posix avec son API clone() qui est ultra rapide car bien moins compliquée que l'API posix (thread groups, etc...)
  - [^] # gcj
    
    Posté par free2.org le 23 septembre 2003 à 09:04. Évalué à 1.
    
    ah au fait, il y a une version linux d'eclipse compilée en langage machine par gcj, tu peux l'essayer aussi (surtout que gcj est libre contrairement au jdk de Sun, même si les brevets de Sun sur Java seront toujours une menace)
    - [^] # Re: gcj
      
      Posté par Nicolas Antoniazzi (site web personnel) le 23 septembre 2003 à 11:42. Évalué à 1.
      
      Oui, j'ai vu sur la liste de dévelopement qu'il y avait une version gcj, mais d'après ce que j'ai pu comprendre, tous les modules ne sont pas totalement compilable encore
- [^] # Re: eclipse et kernel 2.6
  
  Posté par deftones_chris le 23 septembre 2003 à 09:50. Évalué à 1.
  
  en parlant de NPTL, il paraitrait que cette librairie ne serait pas complètement compatible avec la nouvelle implémentation des POSIX Threads.
  Quelqu'un a des infos ?
# Re: eclipse et kernel 2.6

Posté par seedeexeen le 23 septembre 2003 à 11:23. Évalué à 2.

Je trouve ça très facile d'accuser les threads...
Au pire c'est la création/destruction de threads en masse qui peut être un peu lente avec l'api posix sous linux.
Dire qu'Eclipse est lent à cause de l'implementation des threads sous linux, ça revient à peu près à dire qu'Eclipse s'amuse à créer 100 threads par secondes, j'ai quelques doutes...
A mon avi, l'explication est plus simple, les jvm sont developpés pour windows, puis portées sous linux, et comme dans la plupart des cas, la version portée est moins complète, moins optimisée, plus lente, etc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.