Articles précédents : Articles
- [12] Renaissance de Moonlight|3D.
- [20] Le POWER4 est-il prêt pour le desktop ?
- [132] Redhat voit rouge ?
- [23] Le site de traductions des mans : un an déjà
- [3] Des collectivités associées pour constituer un patrimoine de logiciels libres
- [69] Un nouveau processeur pour les Mac ?
- [18] Statistiques sur les distributions Linux
- [27] Votre future gateway ou DVD/DivX/TV-recorder de salon
- [249] Nouveau site LinuxFr
- [19] Le modem Sagem Fast 800 certifié par France Telecom
Liens connexes
- Maîtriser les techniques de débogage sous Linux (856 hits)
- Develop rock-solid code in PHP (660 hits)
- Connecter un middleware à Apache 2.0 (437 hits)
- Utiliser des formulaires HTML avec PHP (605 hits)
- RunTime: Commutation de contexte, deuxième Partie (460 hits)
- Accélérez le démarrage de votre application Linux (820 hits)
Dépêche modérée par
Articles : Plein d'articles sur DeveloperWorks
Posté par developerWorks (). Modéré le 16 octobre 2002.
1- Maîtriser les techniques de débogage sous Linux (fautes de segmentation, surcharges et insuffisances de mémoire, crashs)
2- Série « Develop rock-solid code in PHP » : 1ère partie
3- Connecter un middleware à Apache 2.0. Cet article présente un exemple de module de filtre Apache 2.0, puis illustre la nouvelle API par un exemple.
4- Utiliser des formulaires HTML avec PHP. La possibilité de manipuler facilement l'information soumise par l'utilisateur à travers un formulaire HTML a toujours été l'une des forces de PHP. En fait, PHP version 4.1 ajoute plusieurs nouvelles façons d'accéder à cette information et d'enlever de manière effective celle utilisée le plus communément dans les versions antérieures. Cet article s'attarde donc sur les différentes manières de traiter l'information soumise par un formulaire, que ce soit avec des versions PHP anciennes ou plus récentes.
5- RunTime: Commutation de contexte, deuxième Partie Cet article s'attarde sur deux comportements du "scheduler". Le premier étant sa réaction à ajouter plus de choix lors de sa décision de commutation. Le second démontrant l'impartialité par la réalisation d'une charge de travail uniforme dans les multi-threads. Le code source est fournit de façon à ce que vous puissiez l'expérimenter vous-même.
6 - Comment accélérer le démarrage de votre application Linux.
![[en]](../../../images/en.png)
Maîtriser les techniques de débogage sous Linux (856 hits)-
Develop rock-solid code in PHP (660 hits)
-
Connecter un middleware à Apache 2.0 (437 hits)
-
Utiliser des formulaires HTML avec PHP (605 hits)
-
RunTime: Commutation de contexte, deuxième Partie (460 hits)
-
Accélérez le démarrage de votre application Linux (820 hits)
> Lire les commentaires (8 commentaires, moyenne: 1).
Re: Plein d'articles sur DeveloperWorks
Il est pas déjà passé le premier ? ça me dit quelque chose.. En plus il oublie de parler de valgrind, qui renvoie aux oubliettes les outils présentés (sauf gdb ;)
SAI MAL
-
[^]Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme () le 16/10/2002 à 18:46. (lien). Évalué à 1.Je sais pas s'il est déjà passé, mais que pour une fois, on n'ait qu'une seule news, au lieu des séries de 5 ou 6 auxquelles on était habitués, c'est appréciable...
-
[^]Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme () le 17/10/2002 à 08:32. (lien). Évalué à 1.Je sais que tout le monde a l'air de trouver ces articles nuls parce qu'ils sont posté en rafales et qu'en plus ils sont techniques donc ils faut un peu réfléchir pour les commenter.
Néanmoins on y trouve des informations intéressantes :
"Last month's column looked at bare context switch times by using the best primitives on both Windows and Linux. According to those results, context switch time under Windows takes only half as long as under Linux. I concluded that the algorithm for choosing a thread to run is well optimized in Windows."
En gros, linux gère plus mal les threads que Windows NT, d'une part Linux a du mal a supporter plus de 100-150 threads sur un serveur alors que sur ma machine NT de développeur j'atteint couramment 500 threads. D'autres part (et c'est la raison pour laquelle on est limité en nombre de threads) il y a un mauvais support des threads au niveau noyau, qui donne des perfs plus mauvaise que sous NT, et surtout ses perfs se dégradent beaucoup quand le nombre de threads est élévé (ce qui n'est pas le cas sous NT)
C'est la raison pour laquelle RedHat bosse actuellement sur une nouvelle Posix Thread Librairy, quand cette librairie sera stable et que le noyau 2.6 sera sortie (car la librairie a des dépendance au niveau noyau), le support des threads sous Linux pourra rivaliser (voir dépasser) celui de NT.
Je crois que pour RedHat, le mauvais support des threads est un des principaux freins à l'adoption de Linux au niveau serveur, d'ou le fait qu'il investisse beaucoup pour l'améliorer (c'est comme le manque de système de fichiers journalisés autrefois).-
[^]Re: Plein d'articles sur DeveloperWorks
Posté par Aurélien Girard () le 17/10/2002 à 16:12. (lien). Évalué à 1.Quid de la news relativement récente qui annoncait fièrement que dans le noyeau 2.6, la complexité de l'algo de gestion des threads serait en 0(1), et donc permettrait de gérer des nombres astronomiques de threads les doigts dans le nez ?
-
[^]Re: Plein d'articles sur DeveloperWorks
Posté par LupusMic (page perso, ) le 17/10/2002 à 17:05. (lien). Évalué à 1.que dans le noyeau 2.6
Le noyau 2.6 effectivement
la complexité de l'algo de gestion des threads serait en 0(1)
Ce n'est pas la complexité, je ne connais malheureusement pas le terme exact. Mais c'est la description du comportement de l'algorythme.
Et pour préciser, le post auquel tu réponds y fait justement allusion :)-
[^]Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme () le 18/10/2002 à 09:25. (lien). Évalué à 1.je ne connais malheureusement pas le terme exact.
C'est la complexité du changement de contexte entre deux processus/threads (il n'y a pas de distinction sous Linux).
Plus précisement, je pense qu'il s'agit de la complexité de l'algorithme qui élit le processus auquel serait attribué la prochaine tranche de temps CPU exprimée en fonction du nombre de processus qui la réclament (donc qui sont dans l'état "Running").
-
-
[^]Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme () le 18/10/2002 à 09:15. (lien). Évalué à 1.dans le noyau 2.6 ,permettrait de gérer des nombres astronomiques de threads les doigts dans le nez
Bah, justement à l'heure actuelle la RedHat est configurée par défaut avec un maximum de 256 threads/processus.
Bien sûr, il est facile de recompiler soi-même sa Posix Thread librairie avec une limite plus élévée, mais si RedHat à fixé cette valeur par défaut, c'est pour faire prendre conscience au dévéloppeur que pour Linux, 256 threads c'est déjà beaucoup et qu'au delà le système risque de "souffrir".
Par comparaison, quand je lance quelques applis sur mon Duron 900 avec XP (Warcraft 3, Winamp, Opera, et Outlook) le gestionnaire des tâches me donne déja presque 250 threads, au boulot sur ma station de développeur ou j'utilise beaucoup d'applis gourmandes, j'ai déja dépassé les 500.
Imagine, que tu ai acheté un serveur en Rack, et que pour accélérer ton appli serveur, tu souhaites lancer 1000 threads en parallèle. Pour NT c'est une charge de travail raisonnable (surtout pour un serveur), pour Linux c'est délirant, ton système va être poussé dans ses derniers retranchements.
Donc soit tu bride ton appli, soit tu change d'OS (c'est pour éviter celà que REDHAT dépense de l'argent la-dessus).
Le coup du nombre de threads astronomique, c'est justement pour essayer de casser cette image "Linux = limité en nombre de threads".
-
-
-
Re: Plein d'articles sur DeveloperWorks
6 - Accélérez le démarrage de votre application Linux
Le titre est trompeur, en fait cet article regroupe plein de liens pour aider à démarrer sous Linux (qu'est-ce que c'est, comment installer, etc), il ne s'agit pas d'accélérer le démarrage d'une appli Linux.
Cette page a été générée par Templeet en 0.1818s (dont 0.1104 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.