Le SMP n’est plus seulement une affaire de serveurs

Quelques temps après avoir migré de Windows 3.x à  NT, j’ai découvert un phénomène
intéressant : Windows NT plantait rarement, certes, mais des applications médiocrement
écrites verrouillaient fréquemment la console. Même si le système ne s’arrêtait
pas et que les processus continuaient à  fonctionner à  l’arrière-plan, je ne parvenais
pas à  obtenir de réaction du système.
Celui-ci reprenait parfois le contrôle de la console, il m’arrivait de pouvoir
arrêter l’application responsable à  partir du Gestionnaire des tâches, mais très
fréquemment NT se comportait comme un système Windows 3.x qui aurait généré une
erreur générale de protection. Je n’avais alors pas d’autre choix que de rebooter.

Ce problème était insoluble du point de vue de l’utilisateur et mes réclamations
auprès des éditeurs de logiciels tombaient généralement dans l’oreille d’un sourd.
Peu d’éditeurs étaient concernés par le comportement de leurs applications sur
un système qu’ils considéraient comme étant l’OS serveur de Microsoft.Lorsque
Microsoft a lancé Windows NT 3.51, j’ai acheté l’une des stations de travail multiprocesseurs
pour NT de la première génération. Avec deux Pentium à  90 MHz et une énorme RAM
de 32 Mo, cette station de travail Intergraph était le nec plus ultra des systèmes
NT de bureau. Mais le plus important à  mes yeux était que ni les mauvaises applications,
ni les exécutables Win16 sur Win32 défaillants n’empêchaient le système de fonctionner.

Au lieu de n’arriver qu’occasionnellement à  récupérer une application arrêtée
au premier plan, j’avais presque toujours la possibilité d’accéder au Gestionnaire
des tâches et d’arrêter l’application récalcitrante. A mesure que je travaillais
avec le système, je découvris autre chose : cette machine bi-processeur était
beaucoup plus dynamique qu’un système monoprocesseur équipée du même processeur
(ou d’un processeur de vitesse équivalente).Windows NT semblait tourner convenablement
avec deux processeurs.
Seules quelques rares applications verticales pouvaient tirer profit de la configuration
bi-processeur, mais les applications de bureautique traditionnelles et les applications
16 bits tournant dans la Machine DOS virtuelle s’exécutaient mieux avec deux processeurs.
Le second processeur permettait à  NT d’effectuer ses tâches sans être encombré
par les applications et ces dernières n’avaient pas à  partager le processeur avec
l’OS.

De plus, les rares applications verticales qui pouvaient tirer profit du second
processeur (par exemple Excel réeffectuant des calculs en arrière-plan) affichaient
une hausse de performances remarquable.Lorsque Microsoft a sorti Windows 95, j’avais
toujours ce système à  90 MHz (bien qu’étant passé à  120 Mo de RAM). Lorsque les
applications Win95 32 bits firent leur apparition sur le marché, je fis deux découvertes
qui m’ennuyaient réellement. D’abord, les éditeurs continuaient à  utiliser le
modèle de développement monothread, même pour écrire des applications 32 bits.

La plupart n’utilisaient pas un threading sérieux permettant à  NT et au matériel
SMP de tirer le maximum de leurs applications. Les applications monothread écrites
sur un modèle de comportement linéaire ne profitaient réellement ni de l’OS ni
du matériel. Deuxièmement, le programme de certification Windows était insignifiant.
A l’origine le programme exigeait que les applications arborant le logo  » Conçu
pour Windows  » tournent sous NT (ou qu’une version pour NT soit présente dans
l’emballage), couvrent les mêmes fonctionnalités ou adoptent un comportement raisonnable
en cas d’incident. Mais, sans fanfare (ni d’ailleurs de communiqué presse), Microsoft
a supprimé la nécessité de supporter NT du programme.

Cette mesure n’a pas exactement encouragé les éditeurs à  écrire des applications
tirant pleinement profit de NT et moins encore d’un poste de travail multiprocesseur.A
l’époque, mes habitudes de travail avaient changé. Au lieu d’ouvrir et de fermer
des applications au fur et à  mesure que j’en avais besoin, j’avais 10 ou 15 applications
ouvertes en même temps.
Je gardais celles que j’utilisais fréquemment (c’est-à -dire Lotus Notes, programme
de messagerie POP3, traitement de texte, tableur) ouvertes en même temps pendant
des jours (voire des semaines) et celles que j’utilisais moins fréquemment (c’est-à -dire
les compilateurs) seulement quand j’en avais besoin. Cette approche était beaucoup
plus facile que de travailler sur Win95 et d’avoir à  faire le suivi des applications
ouvertes et actives, pour ne pas manquer de mémoire. Mais la possibilité de garder
les applications ouvertes et d’être productif n’était pas seulement due à  NT,
mais aussi aux deux processeurs du système.

Lorsque Microsoft a sorti NT 4.0, j’ai mis à  niveau mon système et j’ai entamé
une campagne sérieuse pour exiger des éditeurs de logiciels qu’ils écrivent des
applications avec des threads convenables, tournant sur des systèmes Win95 mais
réellement performantes sur NT et particulièrement sur des systèmes SMP. Cette
campagne échoua complètement.
Les éditeurs (dont Microsoft) ne voyaient aucun intérêt à  créer des applications
desktop qui profiteraient pleinement des possibilités de Windows NT. Entre-temps
la vitesse des processeurs augmentait et je me mis à  tester et examiner à  peu
près chaque système dernier cri qui sortait, mais je n’en découvris aucun qui
soit capable d’exécuter NT significativement mieux que mon système bi-processeur
à  90 MHz, pourtant devenu très lent. J’étais sur le point de remplacer mon système
lorsque sont arrivées les stations de travail bi Pentium Pro à  200 MHz, mais la
différence de prix pour ce qui n’était qu’une amélioration de performances incrémentielle
me retint de le faire.

De plus, pour ce qui était d’exécuter des applications de bureautique, d’écrire
en HTML, de gérer des réseaux et d’effectuer à  l’occasion de la compilation C++,
la différence entre les deux systèmes ne justifiait pas le passage au bi Pentium
Pro.Lorsqu’Intel a sorti le processeur Pentium II, je fis d’abord évoluer mon
serveur principal. Le taux d’utilisation de la CPU de mon biprocesseur Pentium
à  133 MHz était dans la fourchette de 60 pour cent quand j’exécutais NT Server
4.0 avec IIS hébergeant une demi douzaine de sites Web et une implémentation NT
de Sendmail de MetalInfo.
Les fonctions de serveur Web et la messagerie était suffisamment rapides, mais
la réponse de la console était lente et tout fonctionnait mieux quand j’administrais
le système à  distance. Je fis évoluer le système avec une carte mère Pentium II
de première génération en réutilisant les composants de l’ancien système (à  l’exception
des processeurs) sur le nouvel ordinateur. Je résolus un certain nombre de bugs
mineurs consécutifs à  la mise à  jour et à  l’installation de NT et le nouveau système
afficha alors un taux moyen d’utilisation de la CPU inférieur à  10 pour cent pour
exécuter les applications. Cette opération s’avéra beaucoup plus efficace et je
fus alors convaincu qu’il fallait faire une mise à  niveau du desktop.
Pour la mise à  niveau du PC de bureau, je conservai seulement le sous-système
SCSI et ses périphériques connectés. Après avoir migré vers une carte mère Pentium
II avec deux processeurs à  266 MHz et de la mémoire SDRAM, je m’attendais à  être
emballé par les performances de mon nouveau PC. Mais le système me parut à  peine
plus rapide qu’auparavant. La mise à  niveau ne me déçut pas car, pour certaines
applications (par exemple quand je chargeais une demi douzaine de fichiers TIFF
de 12 Mo dans un éditeur d’images), la différence de performances était surprenante.

Comparées à  un monoprocesseur Pentium II, les performances de mon système étaient
définitivement meilleures, mais pas spectaculaires au point de me rendre fanatique
de l’utilisation du SMP dans les desktop.Puis une boîte contenant la station de
travail 410 d’entrée de gamme de Dell Computer fût livrée au labo. Ce système
était équipé de 2 processeurs Pentium II à  450 MHz, de 256 Mo de RAM et de disques
durs Fast/Ultra SCSI.
L’installation du logiciel se passa rapidement et le système fonctionna très bien.
Lorsque je commençai à  utiliser des applications (principalement la beta d’Office
2000 et Visual Studio 6.0), je pus enfin constater un résultat enthousiasmant.

Comparée à  mes biprocesseurs Pentium II à  256 MHz et à  un monoprocesseur Pentium
II à  400 MHz, le Dell 410 était nettement plus rapide. Etant donné son coût relativement
peu élevé et le fait que la plupart des grands constructeurs offrent des produits
similaires, j’estime qu’est enfin venu le temps du SMP pour tous les utilisateurs.
J’imagine déjà  ce qui va se passer quand les développeurs d’applications profiteront
pleinement de ces plates-formes…