Western Digital a annoncé le 10 février dernier la mise sur le marché d'un disque dur nommé 'Raptor' ayant les caractéristiques suivantes :

• Vitesse de rotation : 10000 trs/min
• Temps d'accès moyen : 5,4 ms
• Capacité : 36 Go

On pourrait croire qu'il s'agit là d'un disque dur SCSI, mais il n'en est rien, car il s'agit d'un disque dur destiné à l'interface Serial-ATA ! Cette annonce, si elle a été rapportée par de nombreux sites de news, ne semble pas avoir fait de vagues et pourtant il s'agit d'une annonce importante puisqu'elle annonce tout simplement le remplacement des disques durs SCSI (hormis très haut de gamme) par les disques durs Serial-ATA.

La mise en concurrence des disques durs Serial-ATA et SCSI avait été soulevée par plusieurs lecteurs lors de la parution de mon article sur le Serial-ATA et la réponse était que cette concurrence serait finalement assez limitée. Mais l'annonce de Western Digital, qui est aussi un constructeur de disques durs SCSI, ne laisse aucun doute quant à l'avenir que réservent certains constructeurs au Serial-ATA. Maintenant il faudra quand même attendre confirmation en prêtant attention à la politique de Maxtor et Seagate. S'ils suivent Western Digital, alors l'interface SCSI et les disques durs SCSI deviendront des technologies réservées essentiellement aux serveurs haut de gamme.

Le Raptor est annoncé aussi avec un prix de vente de 30% inférieur à ses homologues SCSI. Mais même s'il était au même prix, un tel disque dur serait plus économique qu'une solution SCSI, car d'ici quelques mois toutes les nouvelles cartes mères disposeront d'une interface Serial-ATA intégrée au chipset en remplacement de l'interface IDE. La solution SCSI impliquant un surcoût minimum de 100€, si ce n'est de 200€ à 300€, a cause de l'interface, deviendra pour nombre d'entre nous un objet de curiosité.

La seule question qui reste en suspend est l'évolution en capacité de disque SATA haute performance comme le Raptor, car 36 Go c'est insuffisant pour répondre aux besoins actuels des petites et moyennes entreprises.

Un des effets négatifs de la généralisation de carte mère dual-DDR, c'est que l'augmentation de mémoire ne peut se faire que par pas de 256 Mo (2*128 Mo),et bientôt que par pas de 512 Mo vu la raréfaction des barrettes 128 Mo, voire leur absence lorsqu'il s'agit de mémoire DDR à 200 MHz (PC3200). La question de savoir si 512 Mo de mémoire RAM suffisent ou non prend donc une importance considérable puisque toute augmentation de mémoire impliquera un passage à 1 Go de mémoire ! Il est non moins clair qu'un Go de RAM pour une utilisation courante est du gaspillage pur et simple.

Les applications qui pourraient éventuellement en avoir besoin sont certains futurs jeux utilisant un grand nombre de textures de haute qualité et qui pourraient avoir un impact sur la vitesse d'affichage des images. Mais je ne crois pas que ce scénario se produira. D'abord parce que les concepteurs et éditeurs de jeux sont plutôt regardant au type de configuration moyenne dont disposent les futurs acheteurs et soyons clairs, la majorité ne dispose pas, et ne disposera pas pour 2003, de plus de 512 Mo. Ensuite, il est tout à fait possible qu'un jeu utilise toute la mémoire d'une machine disposant de 512 Mo de RAM, soit environ 300 Mo à 400 Mo de vraiment disponibles pour le jeu si on retire ce que consomment le système d'exploitation et autres logiciels se chargeant au démarrage. Mais il faut distinguer la comsommation totale du jeu et la consommation durant une partie. Ainsi, tout jeu est séquencé en scène ou map, lorsque l'on passe de l'une à l'autre, il arrive souvent que la mémoire ne soit pas totalement libérée, même si certaines informations ne sont plus nécessaires. Dans cette situation, la quantité de mémoire globale utilisée par le jeu augmentera, et pourra générer des appels au disque dur durant le passage d'une scène à une autre, mais durant une scène, 300 Mo ou 400 Mo suffiront. Je ne dis pas qu'on ne trouvera pas un contre exemple durant cette année mais dans l'ensemble je ne vois pas de raison de s'engager sur la voie des plus de 512 Mo.

Maintenant on peut espérer que les constructeurs de barrette mémoire produisent à nouveau des barrettes de 128 Mo, mais je n'y crois pas trop sauf pour des fabricants peu scrupuleux qui verront là un marché pour revendre des trucs innomables. Par contre, il y a un fait en France, la mémoire DDR-SDRAM PC3200, qui va devenir un standard pour les futures cartes mères Intel, est hors de prix (environ 40% plus chère qu'aux USA). Toutefois j'ai bon espoir que les prix baissent :).

Copier des données d'un tableau à un autre ou d'une chaîne de caractère à une autre est une des opérations les plus classiques que l'on puisse faire en programmation. En langage C/C++, on dispose pour ce faire d'une panoplie complète de méthodes, allant de la boucle copiant élément par élément à l'utilisation de fonctions comme strcpy, memcpy, ... Pourtant, il existe un cas particulier de copie de données qui restreint considérablement les choix du programmeur. Il s'agit de la copie avec recouvrement, et c'est ce que nous allons voir dans ce mini-article.

Le terme 'copie avec recouvrement' signifie que la zone mémoire source a des parties communes avec la zone mémoire de destination, elles se recouvrent partiellement. La copie par recouvrement n'est pas très courante sauf dans le cas où il faut insérer un élément impliquant le déplacement d'une partie de ceux existants.

La surprise qui attend tout programmeur qui doit faire pour la première fois une copie par recouvrement, c'est que les fonctions strcpy et memcpy ne lui seront d'aucune utilité. Effectivement, ces fonctions ne garantissent pas leur bon fonctionnement lors d'un recouvrement. En pratique, ça plante sévère ;). Si on veut utiliser une fonction (au lieu d'une boucle) il faut utiliser la fonction : memmove. Voici un exemple de l'utilisation de cette fonction suivi de sa version équivalente en utilisant une boucle. Vous remarquerez que la boucle utilise une décrémentation. Dans le cas d'un recouvrement, vous êtes obligé de commencer la copie par la fin et donc de décrémenter. Un dernier commentaire sur l'utilisation de memmove. Vous pouvez en fait l'utiliser pour déplacer tout ce que vous voulez, des entiers, des pointeurs, des flottants, ... le tout est de se rappeler que cette fonction copie octet par octet, il faut donc bien veiller à préciser la taille des éléments que vous déplacez par un : sizeof(type). Pour des pointeurs se sera un : sizeof(type *) où type sera remplacé par char, long, ...

Pour finir, sachez que la version boucle de la copie par recouvrement n'est pas forcément la plus lente. Il y a plusieurs raisons à cela, la première est que memmove est plus lente que strcpy ou memcpy à cause du recouvrement possible des données. Dit autrement, les fonctions strcpy et memcpy sont rapides car elles ne font pas attention au recouvrement et donc peuvent copier des informations d'une manière plus 'brutale'. Une autre raison est que les compilateurs récents savent non seulement produire un code performant pour les boucles, mais aussi les optimiser de manière assez significative en fonction du microprocesseur auquel est destiné le programme. Et enfin, la boucle effectue une copie élément par élément et non octet par octet. C'est une différence importante car plus l'élément est important en termes d'octet, plus l'utilisation de la boucle pourra se justifier. Par exemple la copie de 1000 éléments d'un tableau de type long peut produire la copie de 1000 éléments de 4 octets et une copie de 4000 octets par mememove. Mais le même tableau avec des shorts (2 octets) produira toujours une copie de 1000 éléments et donc 1000 itérations. Par contre, la fonction memmove n'aura plus qu'à déplacer 2000 octets, puisqu'un short prend 2 octets.

Voilà une question récurrente dont certains d'entre vous connaissent déjà la réponse mais pour les autres voici la raison pour laquelle on a besoin de microprocesseurs et de machines de plus en plus puissantes. En fait, il existe de nombreux algorithmes et projets de programmes qui dorment dans les tiroirs et qui ne peuvent pas voir le jour faute de puissance.

Revenons au début des années 1980, l'un des programmes qui fait fureur à l'époque est le tableur. Or, ceux-ci se traînent dès qu'il y a quelques milliers de cellules à additionner ou à multiplier. Aujourd'hui, la vitesse de calcul d'un tableur n'est plus vraiment à l'ordre du jour. Les performances des microprocesseurs augmentant, on a commencé à parler de multimédia. Je me rapelle très bien que lorsque j'ai entendu pour la première fois ce terme je me suis demandé ce qu'était cette bête là, puis j'ai vu les premières applications, c'était assez moche (avec les critères d'aujourd'hui) et plutôt lent. D'ici quelques années, les applications multimédias vont progresser en beauté et en performances. Et pour demain ? Je ne sais pas de quoi demain est fait, l'intelligence artificielle aura sa part pour consommer toute la puissance des microprocesseurs qui existeront dans 10 ans, mais pas seulement. La notion de temps réel par exemple pose beaucoup de problème, c'est-à-dire la capacité d'une application à répondre en un temps très court. Pour l'instant, dans de nombreux domaines comme les moteurs de recherche, on prémâche l'analyse des données pour avoir un temps de réponse acceptable, mais cela implique un aspect statique et la non prise en compte immédiate de données toutes fraîches, de même que de pouvoir faire de l'analyse en cascade, c'est-à-dire qu'on fait une analyse (test par exemple) qui produit un résultat et que ce résultat est lui-même réanalysé et produit un résultat, etc ...

Bref, la puissance des microprocesseurs de demain sera totalement exploitée par les applications de demain. Maintenant, ce qui peut arriver et va certainement arriver, c'est que les applications les plus utiles au grand public aient de moins en moins besoin de processeurs ou machines de plus en plus puissantes.

J'ai eu l'occasion de faire quelques commentaires sur la version 6.0 du compilateur d'Intel à propos des options de compilation. Lire : Intel C/C++ 6.0. Faites chauffer les Pentiums. La version 7 semble différer de la 6.0 dans sa manière d'optimiser, en particulier en ce qui concerne l'importance de la fonction de profiling.

Le profiling est une option assez récente dans les compilateurs, du moins qui s'est généralisée assez récemment. Le principe du profiling consiste à compiler le programme avec une option particulière (/Qprof_gen pour le compilateur d'Intel) qui va générer un code contenant différents marqueurs et fonctions qui font durant l'execution du programme créer des fichiers contenant des informations détaillées sur le fonctionnement du programme. Pour exploiter ces informations, il suffit de recompiler en utilisant une autre option. Dans le cas du compilateur Intel 7.0, on remplace /Qprog_gen par /Qprof_use. D'un point de vue pratique, le compilateur d'Intel génère des fichiers .dyn dont les informations seront analysées et compilées dans un fichier .dpi. Je vous recommande fortement d'effacer ces fichiers et de recommencer un profiling à chaque modification de votre programme.

Comme pour mon précédent mini-article sur le compilateur d'Intel, j'ai utilisé l'analyseur syntaxique d'Onversity pour faire des tests de performances. Les tests sont faits de la même manière, mais pour cause d'optimisations de programmation c'est environ 25% plus rapide. Ce que nous montre le tableau ci-dessous, c'est qu'avec ou sans profiling la version 6 produit un résultat assez semblable, tandis que la 7.0 montre une variation bien plus marquée. Cela semble indiquer que si on pouvait se passer du profiling avec la version 6.0, ce serait une erreur avec la version 7.0. Cela est confirmé par le fait qu'avec profiling, la version 7.0 est plus performante que la version 6, mais sans profiling plus lente. Intel a, semble-t-il, reporté une partie des capacités d'optimisation de son compilateur sur le profiling, et ne pas l'utiliser serait renoncer à des gains de performances conséquents.

• Option /QxW (vectorisation et prefetching) : Avec la nouvelle version de l'analyseur syntaxique et de différents outils, je dois désactiver l'option /QxW pour obtenir les meilleures performances, que ce soit avec ou sans profiling. Cet 'échec' d'optimisation que les compilateurs d'Intel rencontrent avec l'option /QxW est du, à mon avis, au prefetching car il n'y a pas grand chose à vectoriser dans l'analyseur syntaxique d'Onversity. Effectivement, je pense que le prefetching est efficace s'il y a prédictabilité des données qui peuvent être préfetchées ou non, or un analyseur syntaxique est un des algorithmes les moins prédictibles. De plus la nouvelle version de l'analyseur a été sévèrement optimisée au niveau des redondances de copie d'information, ce qui fait que ce qui peut être préchargé (préfetché) est nettement moins important qu'avant et que le choix de ce qui peut être préfetché ou non devient enocre plus complexe à définir. Dans le cas présent, les deux compilateurs se plantent. Mais si je rapelle qu'un analyseur syntaxique est un algorithme un peu particulier, je vous recommande quand même de ne pas utiliser les options de vectorisation et de prefetching les yeux fermés.
  
  

• J'ai regardé le code assembleur produit par la version 7, et je dois dire que j'ai été surpris de voir que certaines boucles assez simples d'initialisation sur des structures de tableaux de type 'long' ou de pointeur sont assez mal optimisées. Je travaille actuellement dessus car il semble que l'importance de présenter les instructions d'une certaine manière facilite le travail d'analyse du compilateur et soit parfois plus important que bon nombre d'options d'optimisation. Mais bon ceci est un autre sujet :).

En conclusion, le compilateur C/C++ 7.0 m'a donné l'impression d'être plus pointu au niveau des optimisations que la version 6. Il est tout à fait vraisemblable que dans certaines situations celui-ci produise un code nettement plus rapide. D'un autre côté, il reste manifestement des possibilités importantes d'optimisation et là j'ai hâte de pouvoir tester la future version du compilateur GCC 3.3 qui s'annonce assez prometteuse en termes de performances.

Que l'hyper-threading d'Intel apporte un plus en termes de performances en environnement multitâche ou pour l'exécution d'applications multi-thread ne fait aucun doute. Il est même certain qu'à l'avenir ce gain s'accentuera puisque l'apparition de l'hyper-threading généralise l'utilisation du multi-threading et incite donc les programmeurs à optimiser leurs programmes multi-thread, ou encore à les rendre multi-thread. Toutefois, les nombreux articles que j'ai lu sur l'hyper-threading d'Intel et commentaires dans des forums sur cette même technologie m'amènent à faire deux précisions.

En premier, tout programme ne gagne pas à devenir multi-threading de même que certains algorithmes ne sont pas décomposables en plusieurs thread. Dans le premier cas, la raison est que le multi-threading impose un certain nombre de contraintes comme la réentrance, la synchronisation des thread le temps de switcher d'un thread à un autre, ... qui peuvent faire perdre le bénéfice de certaines optimisations spécifiques à un fonctionnement mono-thread. Pour que le gain en multi-thread soit réel, il faut que l'équation suivante des temps d'exécution soit vérifiée :

Cette équation signifie simplement que si une fonction est exécutée en un temps T alors, pour qu'il y ait un gain dans sa version multi-thread, il faut que la somme des temps d'exécution des thread qui la composent soit inférieure. Evidemment, cela dépend aussi énormément de la machine utilisée (microprocesseur, architecture des bus, ...). Dans le second cas, il arrive que des tâches ne puissent être décomposées, de même que la décomposition d'une tâche en de plus petite à ses limites. C'est souvent le cas d'algorithmes avec historique. Par exemple toute fonction qui analyse un texte et génère une table dont le contenu varie et influe durant et sur le déroulement de la fonction est impossible à décomposer (algorithme de compression de Huffman, calcul du clef de Hashage, ...). Toutefois, je mets un petit bémol à ce que je viens de dire. Effectivement, la recherche dans le domaine des algorithmes est très active, et il n'est pas impossible que certains algorithmes dits indécomposables puissent un jour exister en une forme décomposable, et je pense que certains le deviendront, mais j'ai dit certains pas tous, et le chemin est encore rempli d'embûches.

Le deuxième commentaire que m'inspire le récent engouement pour l'hyper-threading et donc le multi-threading, c'est l'engouement lui-même, ou plutôt ses conséquences. Soyons clair, l'arrivée d'un microprocesseur équipé d'une technologie permettant d'augmenter les performances des programmes multi-thread active et atise le développement de d'application multi-thread. La conséquence, c'est que les machines à base de multiprocesseur en seront les premières bénéficiaires, puis le Pentium 4 disposant de la technologie hyper-threading. Et les autres ? Et bien ils n'auront que leur yeux, je veux dire leurs transistors, pour pleurer. Effectivement, une version multi-thread d'un programme sera toujours plus lente que sa version monothread en s'exécutant sur une machine monoprocesseur, et si ce microprocesseur ne dispose pas d'une technologie comme l'hyper-threading. Pire encore, il existe d'ors et déjà des programmes qui sont non seulement optimisés pour le multi-threading, mais aussi pour que ce multi-threading soit le plus performant possible sur les microprocesseurs Intel Pentium 4 avec hyper-threading. Nous sommes nombreux à nous être demandé les raisons de l'apparition de la technologie hyper-threading. Gain de performances des applications multi-thread ou dans un environnement multi-thread, mais l'HT comme le surnomment les intimes, c'est aussi comme la force, il y a un côté obscur, et il est justement dans l'engouement que cette technologie suscite, car tous les microprocesseurs qui n'en disposeront pas se trouveront très désavantagés. Bien joué Mr Intel.

Pour conclure, je soupçonne certains lecteurs de soupçonner des propos anti-Intel :D. En fait, il n'en est rien. Le Hammer, qui pourrait être un concurrent au Pentium 4 hyper-threading, est très en retard et ce retard est entièrement du à AMD pas à Intel. Mais Hammer ou pas, aucun microprocesseur que pourra développer AMD ne pourra concurrencer les futurs microprocesseurs Intel, s'il n'entre pas dans le mouvement qu'a initié Intel, à savoir la généralisation des applications multi-thread. C'est ça l'essence même de ce qui est en train de se passer au niveau informatique.

Il y a là un parallèle à faire avec les instructions des microprocesseurs. Depuis leur existence (microprocesseur 4004 développé par Intel en 1971), les fonctions (addition, multiplication, décalage, ...) n'ont cessé de voir leur temps d'exécution en nombre de cycle diminuer, du moins jusqu'au milieu des années 90 (génération des Pentiums). Ainsi une divison entière de 32 bits met aujourd'hui environ 30 cycles pour s'exécuter, ce qui n'a guère changé depuis près de 5 ans. Il va se passer la même chose avec le multi-threading. Le moindre programme, la moindre fonction va être décomposée en thread de plus en plus petite dans les années à venir, mais cela aura une fin, car la décomposition a ses limites. Durant ce temps, les microprocesseurs vont se voir doter de technologies permettant d'exploiter au mieux cette conception en de multiples thread des programmes augmentant par là même les performances. Trois voies existent :

• L'utilisation de machines multiprocesseurs : Je ne pense pas que cette solution soit viable pour les ordinateurs familiaux ou de bureau, car le coût de l'architecture de la carte mère, pour gérer les communications entre processeurs, reste et restera assez élevé.
  
  

• L'hyper-threading : Technologie consistant à assister matériellement le passage d'un thread à un autre en augmentant le parallélisme. La question est de savoir si une telle technologie est applicable à d'autres microprocesseurs comme le Hammer ? A priori non, et même Intel avec ses futures générations d'Itanium n'intègre pas l'hyper-threading. Mais voilà, il s'agit d'une technologie Intel, donc même si elle était applicable à d'autres microprocesseurs, des sociétés comme AMD ou IBM pourraient-elles développer un équivalent sans marcher sur les brevets d'Intel, ou Intel acceptera-t-elle de la louer ? Celui ou celle qui a la réponse à cette question me le fasse savoir ;).
  
  

• Le multi-core : Intégration au sein d'un même microprocesseur de plusieurs processeurs. Cette technologie existe déjà et offre des performances bien supérieures que le multiprocesseur (puisque les échanges entre les processeurs se font à l'intérieur d'un même microprocesseur) et que l'hyper-threading (puisque les thread s'exécutent totalement et réellement simultanément). Ce qui freine actuellement le développement de cette technologie, c'est la finesse de gravure. Mais d'ici 3 ans, avec l'arrivée de gravures en 0,065 micron, IBM, Intel mais aussi AMD pourront proposer des microprocesseurs double core dont le prix sera compatible avec celui du marché grand public.

Alors l'hyper-threading une mode ? Nous verrons, mais ce qu'il y a de bien dans l'hyper-threading ce n'est pas l'hyper-threading, c'est le mouvement de développement à outrance du multi-threading que cette technologie initie. Certes des sociétés comme AMD seront mises à mal pendant quelques temps, mais je pense aussi que la finesse de gravure permettra l'adoption de microprocesseurs double-core, qui permettra à d'autres sociétés qu'Intel d'exister sur le marché des microprocesseurs. Mais voilà un sacré débat et je vous invite à donner votre opinion ou à poser des questions sur le forum dédié à ce mini-article.

Le dernier vol d'une navette spatiale américaine, qui a explosé à son retour sur Terre, a coûté la vie à 7 astronautes. Cela a réveillé la querelle récurrente depuis une vingtaine d'années de savoir si oui ou non, il faut des vols spatiaux habités. Et la question corollaire, de savoir si la station spaciale internationale a une raison d'être ou non.

L'argument soi-disant massu, qu'assènent ses défenseurs, est que cette station permet de faire de nombreuses expériences en particulier dans le domaine de la recherche fondamentale, et la recherche fondamentale, si on ne sait pas à quoi ça sert aujourd'hui, on sera bien content de l'avoir fait quand on aura besoin de ces résultats. Evidemment, il n'existe pas de recherche sans recherche fondamentale, c'est-à-dire une recherche dont les résultats théoriques ou expérimentaux n'ont pas nécessité à avoir un débouché industriel ou commercial. Toutefois, la recherche fondamentale que l'on peut faire dans une station spatiale aujourd'hui n'est de loin qu'une infime partie de la recherche fondamentale tout domaine confondu, de même toute recherche fondamentale n'est pas forcément justifiée parce qu'elle a l'étiquette de recherche fondamentale et pour finir, il faut savoir que certains laboratoires de recherche fondamentale ont des budgets de fonctionnement qui ne dépassent pas les quelques milliers d'euros, comparé aux sommes colossales que nécessitent quelques dizaines d'expérience en gravité zéro (enfin presque zéro).

Bref la recherche fondamentale n'est pas vraiment un argument de poids quand il s'agit des sommes énormes dépensées et surtout du coût en vie humaine que cela peut avoir. Mais alors à quoi sert cette station spatiale et cette navette spatiale, puisqu'aujourd'hui son principal intérêt est de faire le bus entre la Terre et la station ? On se le demande. Pourtant je suis un défenseur des vols spaciaux habités, mais ce que je reproche aux projets actuels c'est leur incroyable manque d'envergure. Des vols habités oui, mais pour quoi faire ? Mais pour aller sur Mars, installer une base permanente sur la Lune, bref des projets fous, de grands projets qui vont nous obliger à nous dépasser nous-mêmes, et nous faire rêver à un futur différent et peut-être meilleur.

Si vous souhaitez discuter de l'iss (station spatiale), des expériences en gravité zéro, ... ben n'hésitez pas :). Sinon pour ceux qui voudrait en savoir plus sur les projets spatiaux, allez sur le site GB Ciel

On l'oublie de plus en plus souvent mais ce qui fait les performances d'une base de données c'est son moteur, c'est-à-dire l'algorithme qui exécute les recherches d'informations. Mais quelque soit l'algorithme utilisé, il faut, à un moment ou à un autre, lire et/ou écrire des informations sur les disques durs, et généralement c'est là que ça coince. La performance d'un algorithme se mesure essentiellement par le nombre d'accès qu'il doit faire pour trouver ou non une donnée. Moins il en fait, plus rapide sera la base de données. Mais malgré cela, ce n'est pas encore assez rapide s'il y a un grand nombre d'utilisateurs simultanément. Pour résoudre cela, les bases de données de type Oracle, DB2 (IBM), ... tournent en tant que service sur le serveur, c'est-à-dire qu'elles sont chargées une fois pour toute au démarrage du serveur et qu'ensuite elles stockent en mémoire RAM toutes les données qu'on leur demande, diminuant d'autant les besoins d'accès au disque dur.

Le moteur de base de données d'Onversity ne fonctionne pas en tant que service sur le serveur. A chaque fois que vous cliquez sur un lien Onversity, un script (programme) se lance, chargeant en même tant le moteur de base de données d'Onversity. Lorsque le script se termine, toutes les données qu'a collectées le moteur de base de données sont supprimées de la mémoire RAM. Ces dernier mois, j'ai fait pas mal de recherches pour améliorer l'algorithme (sans en changer) et chose troublante, d'après les accès disque, ce qui consomme le plus de temps, se sont les transferts de données qui sont constamment faits entre les fonctions du moteur de la base de données entre elles et avec les fonctions chargées de la présentation des pages. J'ai donc fait différentes améliorations et cela a été extrêmement profitable.

Ce qu'il faut comprendre dans ce que je viens de vous raconter, c'est qu'un moteur comme celui d'Onversity, très dépendant des accès disque, a vu ses performances sérieusement augmenter en diminuant la masse d'échange des données. Alors que penser de moteurs tournant en permanence sur le serveur et qui ne font que peu d'accès disque, du moins tant qu'il y a assez de mémoire ? (j'exclue le cas de l'écriture qui par ailleurs peut être différée donc correspondre à des accès mémoire uniquement). Effectivement, la majeure partie du travail de ces moteurs consiste à transférer des données en RAM pour être récupérées par des programmes applicatifs (comptabilité, site internet/intranet, ...).

Cette petite réflexion indique clairement que les moteurs de base de données sont aujourd'hui essentiellement limités par l'architecture mémoire des serveurs. Si on exclue pour l'instant la mémoire cache, en sachant que les données gérées par les moteurs de base de données sont de petite taille, quelques dizaines d'octets à quelques kilos généralement (taille des champs), c'est le temps d'accès aux mémoires qui est le point crucial. Dans cette situation, les performances exceptionnelles du serveur quadri-opteron s'explique en grande partie par l'utilisation d'un contrôleur mémoire intégré au microprocesseur réduisant considérablement les temps d'accès. Dans la même ligne, on peut déduire que les Pentium 4 Xeon, s'ils disposaient d'un FSB de 200 MHz, deviendraient des serveurs beaucoup plus performants.

Concernant la mémoire cache, il faut qu'elle fasse plusieurs Mo pour être vraiment utile vu d'une part la masse de données gérées et d'autre part qu'en environnement multi-utilisateurs son utilisation est vite saturée. Ce n'est pas pour rien si de nombreux serveurs haut de gamme disposent de plusieurs dizaines de Mo de mémoire cache. Bien sûr, 512 Ko c'est mieux que 256 et 1 Mo mieux que 512 Ko, mais pour permettre un vrai 'boost' des bases de données il y a ce qu'on pourrait appeler un seuil qui dépend du moteur de base de données, de la quantité de mémoire et du nombre d'utilisateurs, mais 1 Mo reste une quantité assez faible.

Pour l'avenir, je vois très bien des serveurs composés de bi ou quadri opteron ou Xeon disposant de contrôleur intégré et d'un haut FSB (on parle déjà de 266 MHz pour le Pentium 4 en début 2004) venir s'installer dans la chasse gardée de gros serveurs. Quand je pense qu'actuellement le serveur d'Onversity est équipé de mémoire SDRAM PC133 avec un FSB de 133 MHz et que d'ici la fin de l'année on parlera de DDR-SDRAM en double canal avec un FSB de 200 MHz, je me dis que l'architecture mémoire a fait de beaux progrès.

Voilà une mise à jour qui s'est fait attendre, mais elle est enfin là. L'article Evolution et perspectives des microprocesseurs II a subi une correction importante concernant l'explication liée en partie au temps de propagation des signaux, explication servant à détailler les relations entre architecture d'un pipeline et fréquence d'un microprocesseur.Cette correction me permettra ce mois-ci d'aborder en toute sérénité ;) un mini-article intitulé : Différence entre microprocesseur et processeur graphique.

Je tiens à remercier les différentes personnes qui ont contribué à améliorer cet article, en particulier Jean-Philippe Boyer.