 |
Jeudi 13 août 2026 - 11:39 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Figure légendaire de la communauté de l'architecture informatique, John Cocke a participé à la conception de plusieurs machines qui ont eu un impact considérable sur la conception actuelle des processeurs, notamment l'IBM Stretch ; l'Advanced Computer System (ACS) ; et les processeurs 801, RS/6000 et PowerPC.
Surtout connu pour avoir été un pionnier des idées ayant mené au jeu d'instructions RISC (reduced instruction set computing), John Cocke est également admiré pour son intérêt et sa compréhension approfondie des technologies, notamment en mathématiques, compilateurs, architecture, circuits, conditionnement et automatisation de la conception. À l'occasion de l'obtention du premier prix Seymour Cray, le magazine Computer lui a rendu visite à son domicile de Westchester, dans l'État de New York, près du centre de recherche TJ Watson, où il a travaillé pendant près de quarante ans jusqu'à sa retraite.
John Cocke
Commençons par
le début. Comment et quand avez-vous découvert les ordinateurs ? Et quand ont-ils commencé à vous fasciner ?Sullivan Campbell, qui avait travaillé plusieurs années chez IBM, est arrivé à Duke après avoir travaillé sur Oracle à Oak Ridge, dans le Tennessee. Oracle était essentiellement un ordinateur von Neumann parallèle de 40 bits, comme celui de l'Institute for Advanced Study. Je venais d'obtenir mon diplôme et j'avais prévu de passer l'été à Duke à travailler pour J.J. Gurgen, un mathématicien engagé pour étudier les ordinateurs que l'armée pourrait utiliser. J'ai loué une chambre chez Sully Campbell ? qui travaillait lui aussi pour Gurgen - et nous avons bu beaucoup de bière et passé beaucoup de temps à parler d'informatique.
J'avais étudié les mathématiques, mais je ne connaissais rien aux ordinateurs avant de discuter avec Sullivan Campbell d'Oracle, de la construction d'additionneurs plus rapides - des choses simples comme ça. Le domaine m'a tout de suite passionné.
Comment êtes-vous
arrivé à travailler pour IBM ?Je songeais à travailler pour Arthur D. Little, alors je suis passé chez eux et chez GE. J'avais un ami chez IBM, un logicien nommé Brad Dunham, qui m'a présenté Steve Dunwell, le responsable du projet Stretch, qui venait de démarrer. Dunwell m'a convaincu que travailler sur Stretch serait intéressant - l'un des principaux objectifs était d'optimiser sa vitesse d'exécution - et c'est ainsi que j'ai rejoint IBM en 1956.
Nous avions un groupe très intéressant, avec notamment Jim Pomerene, qui avait conçu la mémoire CRT pour la machine de l'Institut, Johnniac, et Fred Brooks. J'avais un bureau entre les deux. J'ai appris le Fortran auprès d'Irv Ziller, qui avait travaillé sur le compilateur original et inventé le Fortran 3. Notre équipe comptait également Gerry Blaauw et John Fairclough. John a ensuite dirigé le laboratoire IBM de Hursley, puis travaillé pour le Premier ministre britannique, avant d'être anobli.
J'étais ravi que les personnes que je rencontrais s'y connaissent en informatique, car moi, j'ignorais tout. Par la suite, j'ai convaincu Sully Campbell de venir chez IBM, qui avait alors une réputation scandaleuse. À l'époque, IBM était essentiellement une entreprise de cartes perforées, et Sullivan Campbell m'a donc envoyé à titre d'essai. Si je ne démissionnais pas immédiatement, il prendrait le risque de venir.
2. Influences
Seymour Cray
a souvent établi les normes de la compétition en calcul haute performance. La compréhension de ses
techniques de conception de machines vous a-t-elle éclairé sur ce qui pourrait ou devrait être réalisé
en architecture informatique ?Oui. J'ai toujours eu la plus grande admiration pour Seymour Cray en tant qu'architecte informatique. Il a eu beaucoup de bonnes idées, non seulement pour le 6600, mais aussi pour ses machines précédentes. Il a développé l'indexation progressive et bien d'autres technologies qui permettaient d'obtenir des performances élevées. Je pense que c'était un véritable passionné d'informatique. Il était très cultivé. Je ne l'ai jamais rencontré ni entendu parler, mais certains de ceux qui l'ont connu m'ont dit qu'il avait un sens de l'humour formidable, ce que je ne soupçonnais pas.
Y a-t-il
quelqu'un d'autre que Seymour Cray qui corresponde à votre définition d'un véritable informaticien ?Sullivan Campbell, chez IBM, connaissait bien les différents aspects des ordinateurs, mais pas autant que Seymour Cray, qui excellait dans la conception de circuits, la conception logique, le conditionnement... absolument tout. Il les construisait, les refroidissait et écrivait son propre système d'exploitation. Je ne connais personne d'autre comme lui. J'aurais aimé le rencontrer ; je suis sûr que Seymour Cray aurait été un interlocuteur passionnant. J'admirais aussi son audace d'avoir créé sa propre entreprise.
Avez-vous
des idées sur la façon dont l'architecture informatique devrait être enseignée aujourd'hui ?À mes débuts, je travaillais avec beaucoup de gens qui n'avaient suivi aucun cours d'informatique, car il n'y en avait pas. Avant l'arrivée de Don Knuth, personne n'avait écrit de bons ouvrages sur l'informatique. Après la publication de son livre sur les algorithmes fondamentaux, de nombreux autres livres ont vu le jour.
Je pense qu'il faudrait, selon le niveau du cours, enseigner le fonctionnement des ordinateurs : la logique, les additionneurs, les méthodes pour les rendre plus rapides, mais surtout la mémoire. Le rapport coût/performance s'est amélioré de façon spectaculaire depuis l'invention de la DRAM par Robert Dennard. On payait un dollar le bit de mémoire, et maintenant on est à environ un dollar le mégaoctet. Les performances sont également bien meilleures. On avait une mémoire de 12 ms sur le 704, et maintenant on a une mémoire de 100 ns. Robert Dennard a aussi travaillé sur la miniaturisation, c'est-à-dire ce qui se passe lorsqu'on réduit la taille des circuits tout en maintenant la densité de puissance constante. Ce travail a été une contribution majeure. On doit donc à Robert Dennard deux avancées majeures.
Vous
semblez admirer Don Knuth. Vos nombreux échanges avec lui sur des questions informatiques ont-ils
influencé votre réflexion ?Absolument. Par exemple, avant le profilage, je pensais qu'il fallait compiler en comptant les occurrences et comprendre les fréquences. Il a donné un cours sur le profilage où il obtenait les fréquences et proposait des méthodes permettant de compiler avec moins d'occurrences, puis de calculer le reste. Il connaissait aussi très bien les compilateurs et les langages : le nombre de variables à double indice, à indice simple et sans indice dans les programmes Fortran, etc. Nous étions d'accord pour dire que les développeurs devaient avoir accès à de nombreuses informations lorsqu'ils travaillaient avec des compilateurs. Knuth était un homme travailleur et organisé, et je pense qu'il a eu un impact plus important sur l'industrie informatique que quiconque.
3. Conception du système
Vous avez
conçu plusieurs machines qui ont eu un impact considérable sur la conception actuelle des processeurs,
notamment Stretch,
ACS et les processeurs 801, RS/6000 et PowerPC. Parlons-en.
Stretch a peut-être été la première machine à intégrer la partition du processus d'exécution des
instructions en une phase de récupération et de décodage des instructions et une phase d'exécution
des données. Cette innovation a permis l'avènement de l'anticipation des instructions, du pipeline,
du transfert de données en court-circuit, de la mémoire partitionnée et du retour en arrière des
instructions afin de préserver les interruptions matérielles. Qu'est-ce qui vous a conduit à développer
ces fonctionnalités novatrices ?Stretch était un projet conjoint entre Los Alamos et IBM. Lors de nos discussions, nous leur avons donné un aperçu du fonctionnement de la synchronisation sur Stretch, et plus particulièrement de la prévisualisation. J'ai proposé d'écrire un simulateur en Fortran. Pour ce faire, j'ai dû imaginer le fonctionnement de la prévisualisation : lors d'un chargement, l'opération n'était pas bloquée par l'opération suivante ; on chargeait d'abord une valeur, puis une addition, et le chargement et l'addition chargeaient chacun un tampon, puis l'opération proprement dite s'exécutait. Mais l'opération suivante n'était pas bloquée par l'exécution de l'addition, car elle était liée à la référence en mémoire. Ainsi, on plaçait une opération dans un tampon pour une exécution ultérieure et on chargeait également les données dans un tampon.
L'objectif
de Stretch était d'être cent fois plus rapide que le 704. Pour atteindre cette vitesse,
il fallait une machine complexe qui, à son tour, nécessitait un simulateur complexe. Dans quelle mesure
était-il pratique d'exécuter des séquences de code sur ce type de simulateur pour qu'elles soient utiles ?Les séquences ont clairement montré que nous n'allions pas atteindre cet objectif de performance dans les délais impartis. Le simulateur nous a permis d'obtenir de nombreuses informations sur la conception de la machine et a mis au jour plusieurs mauvaises idées. L'une des pires consistait à rendre les registres adressables comme faisant partie de la mémoire. La justification invoquée était de rendre les choses "propres" - c'est le pire mot en architecture informatique. Prenons l'exemple d'une instruction de stockage. Impossible de déterminer ce qui est affecté par cette instruction. Cela a anéanti tout espoir de concevoir un allocateur de registres correct.
Compte tenu
de toutes les caractéristiques uniques de Stretch qui sont si importantes aujourd'hui, telles que le
partitionnement de l'exécution des instructions, le processus d'exécution, le court-circuitage, la
prévisualisation, partitionnée, etc., quelle caractéristique considérez-vous comme la plus importante ?C'est difficile à dire. La mémoire partitionnée était en quelque sorte la configuration par défaut. Nous disposions d'une mémoire très rapide de 1000 mots et nous avons décidé de la partitionner pour optimiser ses performances, tout en ayant une mémoire beaucoup plus importante pour stocker nos instructions.
La
mémoire partitionnée était-elle le résultat de l'anticipation des instructions qui vous permettait de
continuer à récupérer des instructions ?Nous pensions que la mémoire partitionnée n'affecterait pas les performances de prédiction, même si elle a effectivement ralenti une simulation Monte Carlo comportant de nombreuses branches. C'est pourquoi, lors de la conception d'ACS, nous avons intégré une prédiction de branchement très sophistiquée. Nous avions une instruction de préparation de branchement et ajouté des sauts (saut sur bit, saut sans bit) permettant de marquer une instruction avec un bit et de l'exécuter conditionnellement. On pouvait ainsi se préparer à un branchement, exécuter autant d'instructions que nécessaire, atteindre ce bit, puis passer à l'instruction suivante. Sans préparation du branchement, il était impossible de configurer une instruction pour le saut. La préparation des branchements nous a permis d'alléger leur charge.
ACS
a peut-être été le premier projet à s'être concentré simultanément sur tous les aspects de sa conception :
l'organisation de la machine, le compilateur, la technologie d'encapsulation et la fiabilité. L'expérience
acquise avec Stretch vous a mené à comprendre que le compilateur et le matériel d'ACS devaient être
conçus de concert ?Lorsque nous avons lancé le projet ACS, l'une de nos principales préoccupations concernait la conception du jeu d'instructions. Lors de la conception du compilateur, nous souhaitions garantir une compilation fiable des instructions fournies.
Nous avons travaillé sur des aspects comme le nombre de registres, notamment ceux dépendant de l'architecture de la machine, mais aussi sur des aspects indépendants de la machine, comme l'élimination des sous-expressions communes. Nous avons travaillé sur la réduction de la complexité. C'était un mauvais nom ; nous aurions dû l'appeler "différence de Babbage". Autrement dit, lors du calcul d'un indice, à chaque itération de la boucle et incrémentation de "i", par exemple, il suffit d'additionner la dimension de "a" multipliée par "i" pour que l'indice soit mis à jour. Il n'est pas nécessaire de multiplier "i" et de tout calculer. Cela était indépendant de la machine dans la mesure où l'on suppose que la multiplication est plus lente que l'addition.
Étant donné
que vous avez entrepris simultanément le développement du compilateur d'optimisation et la conception de la
machine, les résultats du compilateur ont-ils eu un impact sur la conception de la machine et vice versa ?Oui. Nous avons découvert que nous pouvions faire beaucoup de choses qui nous semblaient initialement irréalisables. Seymour Cray utilisait l'indexation progressive (lorsqu'on chargeait une donnée, on incrémentait le pointeur d'adresse), et nous aussi. Nous pensions que le compilateur aurait du mal à l'implémenter, mais nous avons constaté que ce n'était pas le cas. Nous utilisions le même algorithme pour la réduction de la complexité, etc. Nous avons beaucoup appris du compilateur 704, le premier compilateur Fortran. Il ne comportait pas de sous-programmes, mais il était très optimisé et d'une ingéniosité remarquable. En fait, certains codes qu'il produisait étaient si performants que, en lisant le code objet, j'ai cru à une erreur, avant de réaliser qu'il était tout simplement incroyablement ingénieux.
L'un
des concepts les plus importants d'ACS est le décodage et l'émission de plusieurs instructions par cycle.
Comment en êtes-vous arrivé à cette idée ?Je dois cette idée à Gene Amdahl. Il a publié un article démontrant que la machine à compteur d'instructions unique la plus rapide a une limite supérieure de performance. Je voulais concevoir une machine plus rapide. Nous avons donc étudié son article, qui indiquait qu'on ne peut décoder et exécuter qu'une seule instruction par cycle, et nous avons décidé de contourner cette limitation. Cet article nous a été très utile car, même si nombre de ses hypothèses étaient erronées, il nous a permis de les identifier. Il avait compris que tous les ordinateurs de l'époque présentaient certaines caractéristiques qui les empêchaient d'aller plus vite. Nous avons donc conçu une machine aux propriétés différentes.
4. RISC : 801, RS/6000, PowerPC
Vous avez
également travaillé sur le 801. Je crois qu'il était nommé America en référence à la première Coupe de
l'America au large des côtes du Pays de Galles, et il est largement considéré comme le premier processeur RISC.Oui, c'est moi qui lui ai donné ce nom, inspiré d'une anecdote. Lors de la première édition de la Coupe de l'America, la reine Victoria avait chargé un observateur de suivre la course. Alors que le navire de tête contournait l'île, Victoria demanda : "Qui est premier ?" "L'Amérique", répondit l'observateur. Lorsque la reine demanda qui était deuxième, l'observateur répondit : "Madame, il n'y a pas de deuxième." Voilà pourquoi j'ai choisi ce nom.
Quel était
l'élément déclencheur de ce projet ?À l'époque, IBM et LM Ericsson discutaient d'un projet commun visant à développer un contrôleur pour un central téléphonique. Nous devions concevoir un commutateur temporel et le piloter avec le 801. Finalement, le projet a été abandonné.
L'effort
801 a-t-il été motivé ou influencé par des expériences indiquant quels compilateurs System/360 ne généraient
qu'un sous-ensemble du jeu d'instructions System/360 ?Oui. Avec le RS/6000, nous avons veillé à ce que le compilateur puisse générer facilement toutes nos instructions. Nous avons adopté une approche flexible, comme il se doit. Au départ, chaque instruction était simple : elle faisait quelque chose, n'en faisait pas autre chose, et en faisait plus. Puis nous nous sommes dit : "Tant pis ! Pourquoi ne pas faire des instructions comme un branchement, un comptage et la mise à 1 d'un bit ?" On commence par effacer un bit. Au premier passage dans la boucle, on effectue le comptage et la mise à 1 du bit pour éviter le délai lié au comptage. Au passage suivant, on teste le bit et on effectue le branchement.
Quelle était
la principale différence architecturale entre le 801, le RS/6000 et les processeurs PowerPC qui ont
évolué à partir du 801 ? Qu'est-ce qui a motivé ces changements ?Eh bien, IBM Austin a commencé à développer un système appelé ROMP, issu du projet 801. Nous sommes allés à Austin, et ils nous ont demandé de construire une machine à virgule flottante. Nous avons abandonné ROMP et conçu une machine à virgule flottante qui est devenue le RS/6000.
Outre
l'unité de calcul en virgule flottante, quelles étaient les autres différences architecturales du RS/6000 ?
Pouvait-on effectuer différents calculs multiples, différents décodages ?Eh bien, les codes d'opération étaient très différents. Nous avions une machine à triple adressage et 32 registres. Nous avions également appris de Stretch à éviter l'indexation par registres.
On peut dire
que Stretch et ACS présentaient une grande complexité matérielle ; ils implémentaient également des
instructions assez complexes. Les processeurs 801 et RS/6000 étaient beaucoup moins complexes sur le
plan matériel, implémentaient des instructions bien plus simples et s'appuyaient de plus en plus sur
les capacités des compilateurs. On observe donc une évolution allant de machines complexes et de compilateurs
semi-intelligents vers des instructions simples et des compilateurs très intelligents. Pouvez-vous nous
dire comment votre réflexion a évolué au fil de ces trois ou quatre machines et compilateurs ?Nous avons constaté que nous pouvions créer - et nous avions, au moment de l'arrivée du RS/6000 - un très bon compilateur. Aujourd'hui, tous les étudiants de master suivent un cours sur la programmation de compilateurs. Ces cours couvrent désormais tous les types d'optimisation, y compris beaucoup de choses que nous n'avions pas abordées. Nous n'avons pas effectué de profilage, ce que nous aurions dû faire avec le recul. Le profilage implique le système d'exploitation ; il faut aller au-delà du compilateur. L'objectif est de compiler, d'exécuter et de compter les fréquences d'erreurs, puis de déterminer où concentrer les efforts d'optimisation.
Voulez-vous
dire que la conception d'un compilateur implique réellement une évolution parallèle du compilateur, du
matériel et du système d'exploitation ?Pour des opérations comme le profilage, la coopération du système d'exploitation est indispensable. Or, beaucoup souhaitent que cette coopération intègre l'interprétation. On interprète, on compte, puis on compile. Les avis divergent sur ce point, et de nombreuses approches sont possibles. On peut analyser le programme à chaque fois, l'exécuter, ou l'analyser et le traduire dans un langage intermédiaire, puis interpréter ce langage. Une fois l'interprétation effectuée, la compilation peut commencer.
Compte tenu
de cet éventail d'approches, laquelle soutenez-vous ?Je privilégie la traduction dans une langue intermédiaire, l'interprétation, le décompte, puis la compilation.
5. Calcul parallèle
Certains dans
le secteur vous prêtent l'ambition de concevoir le monoprocesseur le plus rapide possible. D'autres suggèrent
même que vous pourriez être partagé quant à la conception et à la mise en oeuvre d'ordinateurs parallèles.
Quel est votre point de vue sur la conception parallèle ?Lorsque l'on couple étroitement des machines, on observe de nombreuses interférences, et l'ajout d'une deuxième machine est loin de doubler les performances. Avec des machines couplées de manière étroite plutôt que serrée, la charge sur le matériel est moindre. Les SP2 parviennent assez bien à atteindre un pourcentage raisonnable des performances combinées de deux machines. Ramesh Agrawal a programmé une transformée de Fourier multidimensionnelle qui offre de meilleures performances à mesure que l'on passe à des dimensions de plus en plus élevées. Il a également mis au point cet excellent tri par compartiments qui offre des performances presque linéaires sur plusieurs machines. Mais toutes ces améliorations ne s'obtiennent pas facilement.
Quelles
conclusions tirez-vous de cette situation ? Qu'il s'agit simplement d'une programmation algorithmique
intelligente ?Si nous parvenons à mettre en place une communication adéquate entre les mémoires des différents processeurs, nous obtiendrons à terme de bonnes performances. Mais au final, tout repose sur les algorithmes : prenons l'exemple de la transformée de Fourier rapide, dont la complexité est passée de N² à N log n. Il est impossible d'améliorer l'architecture informatique de manière comparable.
Pensez-vous
que le parallélisme, par exemple dans les paires de multiplicateurs, soit utile ?Eh bien, l'utilité du second multiplicateur est bien moindre que celle du premier. Je ne me souviens plus des chiffres exacts, mais ils ne sont pas bons.
6. Architectures futures
Alors,
comment résumeriez-vous cette situation ? Peut-on espérer des améliorations architecturales de 10 à 20%
ou, si nous sommes très chanceux, de 50% par génération ?Si, par exemple, vous améliorez le compilateur et obtenez un gain de performance de 10 à 15%, vous considérez cela comme un très bon résultat. Vous pourriez obtenir un gain de performance bien supérieur au niveau matériel en augmentant considérablement la fréquence du processeur. Je pense que nous allons y parvenir dans les prochaines années.
Quelle sera
selon vous l'évolution des fréquences d'horloge dans les prochaines années ?Jusqu'à 100 gigahertz.
Nous sommes
actuellement proches d'un gigahertz, vous prévoyez donc une amélioration de deux ordres de grandeur ?Dans 15 ans, nous y arriverons. Ce n'est encore qu'un multiple, pas un grand nombre. Le plus difficile sera d'obtenir une distribution d'horloge de 100 picosecondes sans décalage, mais nous avons de bonnes idées sur la façon de procéder.
IBM utilise le câblage en cuivre. Il y a quelques années, j'ai vu une photomicrographie d'un câblage qui ressemblait à la structure d'un gratte-ciel, les fils étant suspendus dans le vide. Nous aurons recours à la lithographie aux rayons X, ce qui nous permettra d'obtenir des résultats optimaux en termes de miniaturisation. Plus la puce est petite, plus la miniaturisation et le refroidissement sont performants, ce qui nous permettra d'augmenter la densité de puissance grâce au refroidissement. Ainsi, nous aurons une capacité et une résistance réduites, donc des constantes de temps RC très faibles, ce qui permettra d'améliorer considérablement les performances. Nous disposerons également de bons logiciels d'optimisation des circuits ; il est évident que plus les circuits sont rapides, plus il est facile de les rendre encore plus rapides.
Imaginons que j'utilise la lithographie aux rayons X pour fabriquer une puce de 3 mm², ce qui me donne un processeur quadricoeur avec un cache de 3 mm². Je devrai alors me préoccuper de l'évolution des performances de la mémoire principale, mais si je transpose cette puce de 3 mm² sur une puce mémoire d'un ou deux centimètres de côté, j'obtiens 256 Go. J'ai donc une grande capacité de mémoire et je peux effectuer des accès rapides, par exemple en 5 ns (50 cycles). Cela sollicite un peu le cache, mais c'est acceptable. Ensuite, je lis les données entrelacées, etc., et j'utilise ce qu'on appelle un cache non bloquant (une file d'attente pour mon cache), ce qui améliore encore les performances. Je ne dis pas qu'IBM y parviendra immédiatement, mais cinq ou dix ans, c'est très long en informatique.
7. informatique reconfigurable
Quel
avenir pour les systèmes informatiques reconfigurables ?J'y crois beaucoup, car c'est le moyen le plus rapide de construire un simulateur. Mais si je considère le domaine et l'image, disons que j'ai un mot de 32 bits : combien de fonctions ai-je ? La réponse est approximativement 2 70, ce qui est énorme. Prenons un additionneur 32 bits classique : quelles sont ses fonctions ? Addition, soustraction, multiplication, division. C'est le principe des mathématiques. Alors, comment envisager 2 70 combinaisons binaires utiles ? La reconfiguration ne sera pas utilisée dans l'unité fonctionnelle, pour calculer une racine carrée, mais elle sera utile pour un système de hachage ou de chiffrement : 70 bits constituent une clé suffisamment longue.
La reconfigurabilité est également un atout pour le contrôle. Imaginons que je veuille exécuter une machine de traitement de flux de données. Je dispose d'une machine, comme un évaporateur ou un graveur, pilotée automatiquement. Si je vous donne les instructions, combien de temps vous faut-il pour construire un ordinateur ? Mais si je dispose de cette machine reconfigurable, que je la débogue, l'assemble et que je demande à une autre machine de la construire, et que la construction de cette machine prenne deux semaines, quel est le problème ? Les problèmes complexes de ce type prennent beaucoup plus de temps.
8. Informatique quantique
Qu'en
est-il de l'informatique au niveau moléculaire ?Je crois que la situation est la suivante : dans les ordinateurs quantiques, P est égal à NP. Pour l'instant, ce n'est qu'un résultat théorique, et personne ne sait comment construire ces ordinateurs quantiques, mais on travaille d'arrache-pied pour y parvenir. J'ai lu un article dans Physics Today qui expliquait comment utiliser un laser pour moduler la fonction d'onde d'un électron. Quelqu'un finira bien par trouver la solution. souvenez-vous que Kelly, chez Bell Labs, avait suggéré de construire un transistor, et Shockley, Bardeen et d'autres l'ont fait. Je ne sais pas comment cela se passera, mais les chercheurs sont aujourd'hui bien plus compétents, et nous aurons donc, un jour, des ordinateurs quantiques.
Si P est égal à NP, la différence est énorme. Avec un vérificateur de preuves, par exemple, je parcours la preuve, je la vérifie et je m'assure de sa validité. Or, la différence entre un vérificateur de preuves et un démonstrateur de théorèmes correspond à la différence entre P et NP, n'est-ce pas ? C'est fantastique ! Imaginez qu'on commence par essayer de tout prouver dans tous les sens, et que chaque fois qu'on trouve une preuve vérifiée, on la valide. Mais avec un ordinateur moléculaire, je prouve tout, n'est-ce pas ? C'est une machine de Turing.
9. Par simple curiosité
On vous
décrit comme une personne dotée d'un esprit très fertile, qui inspire et guide ses collègues, tant
au sein qu'à l'extérieur d'IBM. Quels conseils donneriez-vous à ceux qui jouent un rôle de mentor ou
de catalyseur dans l'industrie et les universités ?Je fais ce que je fais simplement parce que l'informatique m'intéresse. Je n'ai pas de stratégie particulière pour être efficace. Presque rien dans le domaine informatique n'échappe à mon attention, y compris les personnes qui s'y intéressent. Je ne peux pas dire que j'aie une idée précise de la façon de faire avancer les choses.
Vous
considérez-vous comme une personne motivée ?Non. Je me débrouille simplement avec une curiosité normale.
Est-ce là
votre principale motivation ? La curiosité ?Eh bien, je ne sais pas. Mon père, après avoir obtenu son diplôme de droit vers l'âge de 18 ans, est allé travailler dans le cabinet d'avocats de son oncle. Il ne pouvait pas passer le barreau car il était trop jeune. Il était donc un peu garçon de bureau, et on se moquait beaucoup de sa curiosité. Un jour, il est passé devant une pharmacie, a vu une boîte noire avec un trou et s'est demandé à quoi elle servait. Il y a mis le doigt et s'est fait une vilaine coupure. Il s'avère que cette boîte servait à couper les bouts de cigares - une chose que mon père a apprise à ses dépens. Je crois que j'ai hérité de sa curiosité. J'espère toutefois ne pas avoir eu une aussi mauvaise expérience.
Auriez-vous
des conseils à donner aux architectes informatiques de la prochaine génération ?Je ne sais pas. Je fais ce que je fais, sans me soucier de la façon dont je devrais le faire. Je ne l'ai jamais fait. Je ne crois pas à la rigidité. Si une opportunité se présente, je m'affranchis de toutes les règles, même si c'est probablement une erreur.
Remerciements
Nous remercions Vicky Markstein de SilverMark, Chris Sciacca de Technology Solutions, Takako Yamakura d'IBM et Robert Godfrey des archives d'IBM pour leur aide dans la localisation des images.
Bruce Shriver est consultant pour Genesis 2 Inc. Il est professeur invité à l'Université de Tromsø en Norvège et professeur honoraire à l'Université de Hong Kong. M. Shriver est membre de l'IEEE et ancien président de la Computer Society. Vous pouvez le contacter à l'adresse suivante : b.shriver@computer.org.
Peter Capek est chercheur au centre de recherche IBM TJ Watson et membre de l'IEEE. Vous pouvez le contacter à l'adresse capek@us.ibm.com.
|
