jump to navigation

L’e-learning et le goût du RISC / E-learning and the taste for RISC 1 août 2005

Par Thierry Klein dans : Technologies.
Lu 3 164 fois | trackback

Quand j’étais étudiant à Stanford, j’ai eu la chance de prendre des cours d’architecture des processeurs avec le Pr Hennessy. Le Pr Hennessy (qui est ensuite devenu le doyen de l’Université) est connu de tous les geek (prononcer guiiiik) pour être l’inventeur du processeur RISC. (Souvenez vous, des sociétés comme SUN, MIPS se sont lancées avec des ordinateurs RISC dans les années 80. Tous ces ordinateurs étaient plus rapides et plus faciles à concevoir que les autres grâce aux idées d’Hennessy.

When I was a Stanford student, I attended computer achitecture classes with Pr Hennessy. Pr Hennessy (who later became Stanford Dean) is famous among all geeks as the inventor of the RISC computer. (Remember, in the eighties, companies like SUN or MIPS started up from this idea and started developing processors and computers that were cheaper and quicker thanks to Hennessy’s ideas.

Le but final de cet article étant de traiter d’elearning, ceux que la technologie n’intéresse pas du tout - ou ceux qui connaissent déjà tout sur le RISC - peuvent sauter les paragraphes qui suivent. Mais je trouve qu’il est intéressant d’expliquer les idées d’Hennessy et je vais essayer de les rendre accessibles à tous.

It may not look like it, but the ultimate goal of this article is talk about e-learning. So if you are definitely not interested in computer technology or if you know everythying about RISC, you can just skip the next paragraphs. (But if you are not interested in technology, you probably should not read this blog at all, and if you do know everything about RISC, the next paragraphs may be of interest to you since they are more about THE WAY Hennessy reached his conclusions than about the conclusions by themselves.

Au début des années 80, les processeurs devenaient de plus en plus compliqués, ce qui se traduisait par une explosion du nombre de transistors et de leur temps de conception, qui est d’ailleurs directement lié au nombre de transistors. Les leaders étaient déjà Intel et IBM, avec une gamme de processeurs qui devenait de plus en plus complexe et puissante, en particulier parce que le jeu d’instruction du processeur devenait de plus en plus large et les instructions de plus en plus puissantes. Le jeu d’instruction, c’est le langage du processeur. Evidemment, plus il est large, plus il est facile pour un développeur de développer des applications rapides et puissantes dans le langage de la machine. Toutes les sociétés cherchaient donc à créer le langage le plus évolué possible pour le processeur (concrètement, le langage machine commençait à ressembler à une sorte de langage évolué tel que le langage C, par exemple. J’ai d’ailleurs vu passer, à Stanford, plusieurs projets de recherche visant à concevoir un processeur qui parlerait "nativement" le C).

(Si vous avez survécu à ce premier paragraphe, vous allez aussi survivre aux autres, qui sont plus simples…)

In the beginning of the eighties, processors were becoming more and more complex (which means they contained more and more transistors and they took more and more time to design - design time being very much related to the number of transistors). Intel and IBM were already leading the way, designing processors that were increasingly complex and powerful, in particular because the processor “language” (technical name is “instruction set”) was becoming larger and larger and the instructions of the processors were also becoming more and more powerful. The larger the instruction set of a processor, the easier it is to develop fast running software in “processor language”. Everybody therefore tried to create a processor that would have the most powerful and the largest instruction set (some people had the dream of a processor that would natively understand Basic or C and I actually saw several research projects related to this at that time).

Note: If you have survived to this first paragraph, you will survive the rest of this ticket since it just goes easier and easier…

 

Hennessy a remarqué qu’en augmentant la puissance et la complexité du processeur, on augmentait aussi le temps passé à le développer (c’est normal) mais surtout qu’on ralentissait au final l’exécution des programmes. Pourquoi ? Parce que même si on donne aux développeurs des instructions puissantes telles que "Si A est supérieur à B, additionne A à B, et stocke le résultat dans C", ces instructions ne vont représenter en tout état de cause qu’un faible pourcentage de ce qui va être réellement utilisé par les ingénieurs. Les ingénieurs n’utiliseront toujours à 90% QUE des instructions simples, telles que "Additionne A à B" ou "Met le contenu de A dans C", etc… Pour tout programme un peu long, il est impossible à un ingénieur (par manque de temps) ou à un compilateur de taper dans les instructions les plus compliquées.

Mais ces instructions complexes, que tout le monde cherchait à rajouter dans les nouveaux processeurs, avaient un coût. D’abord, elle ralentissaient le travail de conception (concevoir un processeur peut prendre un an, si on perd 6 mois parce que le processeur est complexe, on perd aussi 25% en vitesse, puisque la vitesse des transistors double tous les 2 ans environ - loi de Moore). Ensuite, elles augmentaient le nombre de transistors et donc le coût du processeur et SURTOUT elles faisaient baisser la vitesse générale d’exécution (ce qu’on appelle le cycle d’horloge) du processeur. La raison est que ce cycle d’horloge est aussi fonction de la complexité et du nombre de transistors. Au final, les programmes développés sur les processeurs complexes étaient plus lents et toute la communauté s’escrimait à faire des processeurs compliqués et moins rapides que ce qu’il était possible d’obtenir.

Hennessy observed that when you increased the power and the complexity of the processor, processor development time actually increased (of course !) but more important, software speed actually could decrease. Why ? Because, even if you give developpers very powerful and complex instructions, they are actually so complex to use that they will only represent a small percentage of the whole program. 90% of the instructions actually used by developpers will always be simple instructions. For any significant piece of software, a developper (because he lacks time)or a compiler (because he lacks intelligence) would not make significant use of complex instructions

So what ? Well, the problem is that those complex instructions don’t come for free. First, they slow down the processor design process (it took about 1 year to design a processor, and if you loose 6 months, you also loose 25% of the speed because transistor speed doubles every 2 years - Moore law).

Second, because of those complex instructions, number of transistors increase - therefore processor cost increases and, most important, general speed of the processor decreases (that’s the “clock cycle”). All things equal, the clock cycle is directly related to processor complexity and increases with number of transistors. So, as complex instructions were not used enough (and actually could not be used enough), software running on complex processors was slower and the whole hardware research community was struggling developping highly complex and slow processors instead of developing simple and fast ones !

Pour nous convaincre, Hennessy faisait des petits calculs tous simples tels que celui-ci.

Supposez que vous ayez un jeu de 100 instructions et que vous cherchiez à en rajouter 10 parce qu’elles sont très puissantes (disons qu’elles permettent de faire 2 choses à la fois). Mais supposons que rajouter ces 10 instructions ait comme conséquence de baisser la vitesse globale du processeur (le cycle d’horloge) de 10%. Disons que ce cycle d’horloge est d’une seconde au départ (évidemment, ce n’est JAMAIS 1 seconde, sinon vous mettriez de longues années, au lieu de longues heures, pour lire ce billet :)

Si vous avez un programme de 1000 instructions, il va s’exécuter sur la première machine en 1000 secondes.

Sur l’autre machine, 900 instructions vont s’exécuter normalement et 100 en la moitié de temps (celles qui font 2 choses à la fois). On aura donc 950 cycles, MAIS les cycles sont maintenant de 1,1 secondes, donc le temps d’exécution est de 950 x 1,1 = 1045 secondes. . Vous avez perdu 5% de performance !

To convince us - the students, Hennessy was always using an interesting kind of small but highly significant computations.

“Suppose you have a processor with 100 instructions and let’s say you are adding 10 new complex instructions to it (let’s say these instructions are so comlpex thta they have twice the power of other instructions). But suppose that by doing this, you will slow down processor speed (clock cycle) by 10%. Let’s say this cycle is 1 second (of course, it is never 1 second. If it were, it would probably take years for you to read this ticket instead of just long hours).

Now suppose you have a piece of software running 1000 instructions. On the first machine, it will run in 1000 seconds, right ? On the second machine, 900 instructions will run normally (that’s 900 cycles), and 100 will take half time to run (that’s the complex instructions: they are twice as powerful). So that’s 950 cycles, but clock cycle is now 1,1 s. So total time is now 950 x 1,1 s = 1045 seconds.

Hey, you’ve just lot 5% performance !”

La conséquence, c’est qu’il faut faire BAISSER le nombre d’instructions. Si vous réduisez ce nombre, vous augmentez la vitesse moyenne d’exécution des programmes, vous diminuez le nombre de transistors, c’est à dire, le coût, la consommation des processeurs. Vous augmentez l’innovation, puisque vous pouvez sortir de nouveaux processeurs plus souvent. C’est magique ! De là, le mot RISC "Reduced Instruction Set Computer.

Quel que soit le bout par lequel vous vous y prenez, le calcul que je vous ai fait ci-dessus représente l’essence du RISC. Evidemment, il y a d’autres calculs, d’autres paramètres et tout ça devient très compliqué quand vous parlez de processeur réel. Mais,quelle que soit la complexité du problème, Hennessy posait toujours de petits calculs d’une ou deux lignes, grâce auxquels il arrivait à prédire 90% des aspects de la performance d’un processeur. Parfois, poser le calcul était très compliqué et nécessitait beaucoup de connaissances et de savoir-faire, mais le calcul lui-même, une fois posé, dépassait rarement 2 lignes, d’où son côté génial ! J’ai sous les yeux quelques exercices donnés par Hennessy à l’époque, je ne les comprends plus aujourd’hui mais les réponses font 2 lignes et un élève de troisième qui raisonnerait (très) bien pourrait les trouver.

What’s the meaning of this computation ? The meaning is you should just simplify the instruction set and reduce the number of instructions. If you reduce it, not only will your software run faster, but the number of transistors - that’s the physical cost of the processor - will also go down and so will processor electric power, by the way.

Moreover, you will reduce processor design time and that also has an effect on speed ! It looks magical ! (I was also taking classes at the Stanford Business School and that’s typically what they were naming a “free lunch”. At that time, the economic theory was coming to the obviously wrong conclusion that “free lunches don’t exist” (I think it still does today) and this proves the superiority of geeks among yuppies).

The simple calculation above represents the essence of RISC (Reduced Instruction Set Computer). You will not find anything deeper to explain it. It does not exist. (You may find longer though: there are lots of books about RISC that just do not explain anything and of course, you may have other more complex computations, other parameters - which can become really very complex when you study real processors). But it did not really matter how complex it was: Hennessy was always solving issues with one or two lines long calculations and from them, he could predict 90% of the performance of any processor.

Sometimes, it was really hard and it took a lot of insight to just write those 2 lines but the calculation was always that easy and that’s where the genius was !

I have my old “Computer Architecture” notebook in front of me now (full of exercices and computations from Hennessy). I don’t understand their meaning anymore but the calculation themselves are 6th grade level !

Aujourd’hui, donc, je ne comprends plus grand chose aux ordinateurs, mais j’essaie toujours d’appliquer ce genre de techniques parce qu’elles permettent souvent de façon très simple d’avoir une idée quantitative sur des points où, en général, le subjectif le plus total est de mise.

 

Je vous livre donc quelques petits calculs qui résument assez bien ma vision de l’e-learning et de certains autres problèmes. C’est là le but de cet article et vous devez me haïr de n’y arriver qu’après 2 pages !

Surtout que, comme il se fait tard, les applications concrètes ci-dessus mentionnées feront l’objet d’un autre billet …

It’s been now fifteen years and I don’t remember much about processors today, but I do remember Hennessy’s “simple but significant” calculations and I often try to apply those techniques in real life situations, because they often let you quantitatively analyse situations where utmost subjectivity is usually applied.

I am going to make some of those small computations for you to share the vision I have of e-learning and of some other topics. This is actually the real goal of this article so all of you probably just hate me now because it took such a long time to come to the point.

And the fact that, as it is now pretty late, real applications of all this stuff will only be developped in another ticket is probably not going to help either.

Billets associés :

Commentaires»

1. Dr House, ou le retour du Religieux - 5 décembre 2008

[...] Tous les médecins acceptent sans rechigner cette solution, ainsi que les parents. Elle ne semble poser de problème éthique à personne. Nous tous, dans la vie de tous les jours, effectuons des compromis de cet ordre (je vous avais un jour parlé, dans un tout autre domaine, du goût du RISC). [...]