[ad_1]

Sur la liste de diffusion AGI, il y a plusieurs fils de discussion intéressants, et récemment une demande d’Eliezer Yudkowsky a attiré mon attention, demandant la source d’une citation, que j’ai transmise à Geordie Rose de D-Wave, qui a en effet répondu rapidement et en profondeur.

La demande était de soutenir que

“Un ordinateur de l’ère 1974 exécutant des algorithmes de 2007 battrait un ordinateur moderne exécutant des algorithmes de 1974”

et c’est apparemment le cas.

J’ai demandé il y a environ un an à Marvin Minsky s’il voyait une augmentation exponentielle du pouvoir des logiciels pour résoudre les problèmes, tout comme le matériel, et il a dit qu’au cours des décennies, il avait effectivement vu une tendance positive, mais son évaluation serait celle d’une augmentation linéaire au plus. Nous aurions besoin de bien plus de points de données que deux seulement pour confirmer qu’il a raison ou tort. (Je suppose qu’il a tort et que l’augmentation est plus que linéaire. Voir également ci-dessous.)

Ce que nous voyons dans le matériel, c’est l’application incessante par des ordinateurs via des systèmes de CAO automatisés des possibilités d’une architecture donnée. Quand il y a un saut, c’est parce qu’à mesure que la technologie actuelle s’épuise, l’un des groupes explorant des alternatives a de la chance et c’est leur solution qui redevient la base de la planification matérielle de la prochaine génération par les ordinateurs. Le développement de logiciels, en revanche, est rarement automatisé : les générateurs de code ne se sont pas répandus, car leur sortie était difficile à optimiser davantage, et la réécriture était considérée comme un meilleur choix à la place. Cela signifie qu’il y a une exploitation moins ordonnée de toute architecture logicielle actuelle et de ses possibilités, et des augmentations plus espacées sont plus susceptibles d’être des sauts dans de nouveaux paradigmes.

Je me demandais pourquoi appliquerait-on l’exercice masochiste consistant à exécuter un algorithme plus lent sur un matériel plus rapide, ou un algorithme plus rapide sur un matériel plus lent. La seconde est courante dans le changement de plate-forme, où des considérations de consommation énergétique imposent l’utilisation de CPU moins gourmands en énergie : par exemple lors du déplacement d’un ensemble d’applications donné vers une plate-forme mobile depuis le PC. Le premier est un événement encore plus important à mon avis, car l’ensemble de solutions relativement moins bien optimisé conduit souvent à une meilleure lisibilité par les humains, un ensemble plus riche d’outils de programmation et de débogage, d’EDI, etc. Les langages de dernière génération, comme Ruby , en témoigne, et leur expressivité et leur lisibilité élargissent leur cercle d’adoption, même s’ils ne sont pas optimaux. Parfois, il est en fait possible d’obtenir à la fois une exécution hautement optimisée et une expressivité et une lisibilité élevées, comme dans Mathematica par exemple. Ce que des logiciels fiables et largement utilisés peuvent faire et rester gérable, a certainement augmenté au fil des ans. Certainement pas exempt de bugs, et maintenant souvent caché derrière une balise “bêta” permanente, mais le seuil de quelques millions de lignes de code comme maximum possible vu il y a 10-15 ans a été largement dépassé.

À titre d’anecdote, parmi ceux qui ont été occupés à penser à aider la productivité et la fiabilité des logiciels, il y a Jaron Lanier, l’inventeur du terme «réalité virtuelle» dont la société vendant des gants et des lunettes pour la réalité virtuelle immersive s’appelait VPL Research. “VPL” signifiait Visual Programming Languages, car il pensait que pour obtenir un meilleur débit logiciel, nous avions besoin de nouvelles interfaces et que la réalité virtuelle immersive serait nécessaire. (Ce n’est pas de la création d’objets à la Second Life, car là le code est encore écrit traditionnellement, alors que Jaron voyait le programmeur jongler avec les algorithmes en 3d…)