Snow Leopard : pas de miracle en vue ?

Arnaud de la Grandière |
Avec l'arrivée prochaine de Snow Leopard, et de ses deux technologies phares, à savoir OpenCL et Grand Central, on parle de plus en plus de parallélisme.

Les processeurs en ont en effet terminé avec la progression verticale : au lieu d'augmenter la puissance brute des processeurs, on augmente leur nombre. On obtient ainsi, du moins potentiellement, un bien meilleur rapport puissance/consommation. Le problème c'est qu'il faut désormais bâtir les logiciels très différemment pour en tirer parti. Ainsi, il faut couper les tâches en petits morceaux afin de les faire exécuter simultanément par les différents processeurs et leurs multiples cores. L'opération n'est résolument pas aisée, et nécessite une refonte de l'architecture des logiciels. Si Grand Central a pour vocation de veiller à éviter les embouteillages et permettre aux multiples opérations de se dérouler sans encombre, il ne permet pas pour autant de faire des miracles, et les développeurs devront malgré tout déterminer eux-mêmes quelles tâches se plient le mieux au parallélisme.

Ne nous leurrons pas : le parallélisme n'est qu'un pis aller. S'il permet de mieux tirer parti de nos multicores, toutes les opérations ne s'y plient pas pour autant, et nécessiteront une refonte des logiciels, alors qu'une augmentation de la puissance brute des processeurs était directement exploitable sans rien changer du côté logiciel. On voit déjà bien peu d'applications qui tirent parti des biprocesseurs, alors que les Macs utilisent ce type d'architecture depuis bien longtemps. Les choses ne vont pas aller en s'arrangeant, car la multiplication des processeurs n'ira qu'en augmentant. Imaginez le casse-tête quand nous aurons pas moins de 32 processeurs dans nos machines!

Pourtant, l'industrie informatique a une longue expérience du multiprocessing, dans le champ d'application des serveurs notamment. Mais il y a un univers entre une application pour plusieurs utilisateurs et plusieurs applications pour un seul utilisateur, caractéristique essentielle qui différencie l'environnement serveur de celui que nous côtoyons quotidiennement. En effet, les applications serveur se prêtent par nature au parallélisme, chaque utilisateur étant susceptible de lancer une tâche qui s'exécute simultanément aux autres. Après tout, plusieurs processeurs dans une seule machine, c'est un peu comme si vous utilisiez plusieurs ordinateurs simultanément, et encore, ça n'en a pas tous les avantages, puisqu'on conserve une seule allocation mémoire vive, et la plupart du temps un seul disque dur, qui font figure de goulot d'étranglement en entrée et en sortie des processeurs. Les logiciels qui fonctionnent sur nos Mac se contentent, la plupart du temps, d'utiliser de la mémoire et quelques cycles processeur ici ou là lorsqu'elles sont en tâche de fond : ça n'est pas tous les jours qu'on lance plusieurs opérations simultanément. Le parallélisme sur l'ordinateur personnel s'attache donc à découper les opérations monolithiques en petits morceaux à exécuter concomitamment. Seulement voilà, nombre de ces opérations sont linéaires, chaque résultat dépend d'une opération précédente.



Il ne faut donc pas s'attendre à voir votre Mac mini se prendre pour un Mac Pro comme par magie avec le passage à Snow Leopard. Il faudra mettre les logiciels à jour pour qu'ils exploitent Grand Central et OpenCL. Les seuls cas d'accélération "spontanée" concerneront les appels au commandes du système qui auront été réécrites avec Grand Central et OpenCL. Certes, les beta-testeurs de Snow Leopard ont pu s'atteler à la tâche depuis la finalisation de ses API (voir notre article Snow Leopard : les API finalisées), on peut donc avoir bon espoir de voir nombre de mises à jour disponibles à la sortie du félin. Mais à bien y regarder, tout ceci ne rend l'augmentation de puissance de nos machines que bien théorique : s'il est si délicat d'en tirer toute la substantifique moelle, on finit par gâcher plus de puissance qu'on en exploite, et il semble bien que la stratégie n'avait d'autre objectif que de ne pas faire mentir la loi de Moore, si ce n'est de maintenir la dynamique du marché hardware.

Quoi qu'il en soit, le mal est fait et il faut bien composer avec. Et Grand Central présente un réel avantage une fois qu'un logiciel a été "parallélisé" : c'est le système qui se charge de gérer la répartition des opérations, quel que soit le nombre de processeurs disponibles et le nombre de tâches en cours d'exécution. Voilà qui présente un vrai bénéfice puisque c'est autant de travail que les développeurs n'ont pas à faire, et à vrai dire c'est bien au système d'exploitation de prendre en charge cette partie puisque chaque logiciel ne peut prétendre de contrôler ce que les autres font, ou encore d'intégrer tous les cas de figure matériels, de 2 à x processeurs. Pour résumer, il ne faut pas s'attendre à ce que Snow Leopard ouvre les vannes des logiciels qui exploitent les multiprocesseurs : il y a peu de chances d'en voir bien plus qu'avant, mais ceux qui seront conçus dans ce sens le feront mieux. Et l'avantage sera d'autant plus notable à mesure que le nombre de processeurs augmentera dans nos machines.

Il est d'ailleurs assez ironique de constater que, en regard de cette mise en parallèle des tâches avec les multiprocesseurs, une autre poussée va dans le sens radicalement opposé avec les GPGPU, qui seront gérés par OpenCL. Quand l'un s'attache à découper les opérations pour les répartir sur plusieurs processeurs, l'autre les unifie pour les traiter en une seule passe. C'est sans doute ce qui permet de mieux appréhender la différence fondamentale entre un CPU et un GPU. L'un dispose d'une multitude de portes étroites, quand l'autre n'en propose qu'une seule, mais béante. Jerry Harris, responsable scientifique au sein de l'équipe de développement de Photoshop, l'explique en termes imagés dans cette interview : le multiprocessing, c'est comme si on travaillait avec un troupeau d'ânes : on peut se débrouiller avec deux, mais à partir de quatre ou cinq, ça devient invivable, car ils n'en font qu'à leur tête (c'est justement là où Grand Central donnera toute sa mesure). Alors qu'un GPU se comporte plus comme un banc de poissons ou une volée d'oiseaux : plus il y en a, et mieux ça se passe.

Les GPU sont entièrement voués à traiter de larges amas de données de manière très véloce. Mais cette approche n'est pas exempte d'inconvénients. Il faut déjà que les données et les opérations s'y prêtent, ce qui n'est pas le cas de toutes. Mais même dans ce cas, les GPU étaient jusqu'ici conçus pour être autonomes : une fois qu'on leur a envoyé les données et la nature des opérations à effectuer dessus, on ne s'en préoccupe plus, le GPU les garde dans son coin, par exemple pour afficher une texture à l'écran, sans repasser par la case processeur. L'utilisation d'un GPU comme coprocesseur implique qu'on récupère le résultat pour en faire autre chose, et comme le GPU peut appliquer une seule et même opération sur un lot hétérogène de données, on est susceptible de n'en demander qu'une partie à un instant T. Or, cette opération fait figure de goulot d'étranglement, la récupération de données étant plus lente que le calcul !

Russel Williams, un autre ingénieur d'Adobe, n'est pas en reste en matière de métaphore imagée pour illustrer le cas de figure : c'est comme si vous souhaitiez imprimer un journal local pour San Jose, mais que vous le fassiez imprimer à New York, et livrer par un vieux coucou.

Comme on le voit, Grand Central et OpenCL ne sont pas des solutions miracles, mais elles sont des réponses adaptées à un environnement matériel donné. On le sait depuis longtemps, le micro-processeur à base de silicium arrive en bout de course. On réduit la résolution de gravure d'année en année, vaille que vaille, mais viendra un moment où on ne pourra pas aller au-delà. La frontière ultime et indépassable, c'est la taille de l'atome. Alors que les nanotechnologies font parler d'elles dans d'autres industries, voilà bien longtemps que, d'une certaine manière, l'informatique en est une représentante de taille. Il faudra, tôt ou tard, changer de paradigme, ce qui représentera une révolution à bien des égards. S'il y a différentes pistes de recherche qui sont très prometteuses (processeur optique, processeur quantique, supraconductivité…), elles sont pour l'heure bien loin d'être mises en application et pour certaines font plus figure de science-fiction. D'ici là il faudra bien composer avec les moyens dont nous disposons. C'est ce qu'Apple fera avec Snow Leopard.
avatar Jerry Khan | 
On savait depuis le début que SL n'allait pas apporter de réels gains de vitesse immédiats. Seuls les gogos (qui abondent ici et ailleurs) pensaient que ce serait le cas. La derniere build de snow leopard n'apporte pas grand chose de plus qu'un leopard fraichement installé en terme de vitesse tant au niveau du lancement des programmes qu'au niveau de leur execution. Bref, seules des fonctions cachées dévoilés la semaine prochaine pourront justifier l'achat de cet OS, sinon il devra etre offert gratuitement ou pour une somme symbolique.
avatar biniou | 
@Dr_cube : de pouvoir commencer des threads de manière synchrone et de pouvoir garantir leur exécution de manière synchrone.
avatar totorino | 
La solution raisonnable serait d'arrêter la course au hardware et de concentrer uniquement sur la qualité et l'efficacité du soft.
avatar RDBILL | 
Pas grand chose de vraiment neuf ou formidable dans Snow Leopard, j'entend du point de vue de l'utilisaeur moyen... C'est bien ce qui me semble au vu des différentes brèves sur les différents sites Mac... Question : Qu'est ce qu'Apple et Steve vont nous sortir en argument marketing pour réussir à nous faire cracher 129€ ??? Bon en même temps on peut leur faire confiance pour ce qui est des trouvailles marketing... Et il se pourrait bien que je "craque" finalement, moi aussi...
avatar Anonyme (non vérifié) | 
Tout d'abord merci pour l'article que je trouve excellent. Ensuite, si une meilleure exploitation d'un logiciel par Grand Central nécessite sa réécriture ça veut dire qu'en réécrivant leur logiciel, les devs les rendront plus rapides, mieux exploitables? Ils n'ont donc pas naturellement intérêt à les réecrire ? Evidemment, pour les petits Freewares, c'est autre chose...
avatar proulix | 
ça dépend des apps. Pour un soft de rendu 3D, le parrallelisme et open cl c'est le grand pied
avatar Le Gognol | 
Faut pas être trop défaitiste non plus, il était déjà possible de profiter des avantages du biprocesseur sous OS... 9, avec certaines applications (Digital Performer par exemple), et quand Mac OS X est apparu sa gestion du multitâche a démontré instantanément le bien-fondé de ce genre de solution. Même si les applis ne profitent pas toutes individuellement de la multiplication des coeurs, elles sont quand même de plus en plus rares à ne pas en tenir compte dans les domaines "lourds" (son, image, vidéo), et la demande toujours plus massive d'applications tournant simultanément et de processus tournant en tâche de fond, font que les multiples coeurs de nos machines n'ont pas tant que ça le temps de s'ennuyer...
avatar NikonosV | 
c'est Cuda qui arrive sur mac avec 2 ans retard par rapport au pc sur pc avec un soft tv gratuit, on peut choisir le codec H264 qu'on veut utiliser pour décoder la TNT HD on coche la case utiliser Cuda et hop 5% de cpu pour décoder la TNT HD sur mac y a que quicktime qui peut profiter du décodage hardware j'espère qu'ils penseront à mettre dispo rapidement les techno pour les autres softs puissent les exploiter parce que un finder boosté, on ne passe pas ça vie dessus le finder :o)
avatar misterbrown | 
Je suis curieux de voir la politique tarifaire de Snow Leopard... bon apres, personne nous force a l acheter..
avatar biniou | 
@ NikonosV: Cuda existe sous Mac et depuis plus d'un an. Cuda n'est pas un standard mais est spécifique à NVidia et ce pour certaines versions de leurs cartes graphiques. Ici on parle de deux choses fort différentes au niveau du fonctionnement : - D'un côté l'utilisation des puces graphiques massivement parallèles avec openCL. Cela permettra de faire du calcul comme par exemple diviser une image en bloc et analyser ces blocs séparément pour calculer un histogramme. On peut alors par exemple faire 128 calculs en parallèle en coupant l'image en au moins 128 blocs. Le problème principal des cartes graphiques est qu'elles disposent de peu de mémoire et que si on est trop gourmand, le temps gagné avec la parallélisation est perdu en lecture/écriture sur les I/O. - D'un autre côté (Grand Central), si j'ai bien compris, une meilleure répartition des threads (ou fils dans le moniteur d'activité) sur les différents coeurs (core) et/ou processeurs. Mais aussi une nouvelle API (interface de programmation) qui a pour but de simplifier la vie des programmeurs pour l'utilisation des différents coeurs du processeur/des processeurs. Donc OpenCL est plus générique que Cuda puisque non limité à un seul fabricant et devrait devenir un standard de fait dans les années qui viennent. Ce qui implique que Microsoft va dévéloper une openCL à sa sauce : buggé et dont l'API change de version en version (bon d'accord, je suis mauvaise langue).
avatar philus | 
Article intéressant, mais j'y mettrais un bémol. Ce que va nous apporter vraiement le multi-processeur, c'est de la réactivité plus que de la puissance brute. Je pense que nous allons dans les années qui viennent changer notre façon de percevoir un micro-ordinateur. Beaucoup ont tendance à lancer un programme et attendre que le résultat vienne. D'où la nécessité d'avoir des processeurs à la puissance unitaire de plus en plus importante. Comme nous allons arriver aux limites de la technologie et que le développement multithread ne permet pas tout, c'est cette solution qui devrait émerger. Avec l'augmentation énorme de la ram, la mise en place des SSD (temps d'accès réduits), nous allons vers des systèmes où l'on lance un calcul quelconque, puis un autre, le tout simultanément avec des encodages divers, la gravure d'un DVD tout en surfant, chargeant ses mails, écoutant de la musique et gardant un micro très disponible. On devrait enfin retrouver le multi-tâche très efficace des Amiga (si,si, les connaisseurs apprécieront...) et devrions commencer à oublier les sablier et autres roues multicolores. Pour la plupart des applications, on se moque complètement de savoir si elle va faire son boulot en 10 ou 15 minutes si l'on peut faire autre chose simultanément sans aucune gêne. Il arrive encore actuellement que le chargement d'une page web me bloque un peu dans l'utilisation de mon macbook pro 17 pouces, cela devrait changer...
avatar Dr_cube | 
@ philus : Je ne suis pas entièrement d'accord avec toi. Le parallélisme permet aussi d'accélérer la réalisation des calculs. En répartissant les calculs sur différentes unités d'exécution, on accélère d'autant un calcul. Si on peut zipper un gros dossier en 20 secondes au lieu de 10 minutes, c'est mieux. Si on peut appliquer des filtres sur des images plus rapidement, c'est mieux. Mais je suis d'accord que le plus important c'est de réduire le temps d'apparition de la roue multicolore. Mais là c'est clairement le disque dur qui bloque. Quand on aura des disques dur plus rapides en lecture, on diminuera de facto le temps d'apparition de la roue multicolore. On la retrouve en effet lorsqu'une application se charge en mémoire, et lorsqu'une application a été swappée sur le disque, et qu'elle doit être rapatriée en mémoire.
avatar fixfix | 
MacGé et l'électroménager Les mac, les PC, les iPhone, c'est de l'électroménager, au même titre qu'un grille-pain, un lave-linge; etc. D'ailleurs Steve Jobs avait défini le concept d'origine du Mac comme un "home appliance". Sans doute trouvez vous beaucoup plus commode d'avoir un lave-linge avec 3 boutons (ou même un seul) plutôt que 47 voyants, 4 sélecteurs tournants, 25 boutons, etc. Heureusement que Microsoft ne fabrique pas de lave-linge .... Tout le talent des concepteurs d'un lave-linge est de cacher la complexité, en rendant la machine plus "intelligente" : un lave-linge moderne peut détecter le type de fibres, le poids du lnge, si c'est de la couleur, le degré de salissure, le degré de calcaire de l'eau, etc. Au final, autant de "choix" que l'utilisateur n'a plus à faire. De même, un lave-linge grand public ne fait pas "tout" (ici s'impose la comparaison avec par ex. MS Office s'impose), Faire "tout" rend beaucoup plus compliquée la tâche de l'utilisateur. Il suffit que le lave-linge remplisse, par ex., 99% des besoins. Pour les besoin restants, s'adresser aux prestataires spécialisés. Nos machines électroménagères (je veux parler de nos Mac) sont hélas encore bien trop compliquées. D'où le besoin ressenti par certains de "comprendre comment ça marche", et l'excellent article d'Arnaud (décidément très doué ! Quand faites vous, par ex., une émission télé ?). Quand nos (arrière-)arrière-grand mères ont appris à conduire, elles devaient également apprendre "comment ça marche", la mécaique, etc. Depuis, la complexité des automobiles a été "cachée", et tout le monde peut conduire. Tant mieux ! Re-très grand merci à Arnaud. Même si on n'a plus BESOIN de savoir, reste la curiosité, l'ouverture d'esprit. Cela s'appelle la culture
avatar melaure | 
"Je pense que nous allons dans les années qui viennent changer notre façon de percevoir un micro-ordinateur. Beaucoup ont tendance à lancer un programme et attendre que le résultat vienne. D'où la nécessité d'avoir des processeurs à la puissance unitaire de plus en plus importante." @Philus : c'est une remarque pour ceux qui ont grandi qu'avec Mac OS avant OS X ;) Mais sur Amiga ou Be OS, ça fait longtemps (1987) qu'on attend pas qu'un programme envoie des résultats. Sinon intéressant article qui met en lumière que c'est avant tout une optimisation poussée du système, et qu'Intel fait pas mieux que Motorola en piétinant sur place à son tour ... On sort un jour un proc qui fait faire un bond (G3/G4, Core2Duo) puis après pendant 5 ans, ça plafonne ...
avatar XiliX | 
Il y a beaucoup de "nerds" ici qui oublient que MacGé est lu [b]aussi[/b] par des personnes qui ne connaissent rien en techno parallélisme. Des personnes qui pourraient aussi s'intéresser à ce genre d'information. Il ne s'agit pas ici de descendre SL, mais expliquer pourquoi le parallélisme n'est qu'une solution pour pouvoir exploiter au maximum une architecture multicores/multiprocesseurs. Le gain peut être impressionnant si le processus est entièrement parallélisable... ou pas. Très bon article Arnauld.
avatar ispeed | 
Article très réaliste. En gros on vous propose pour votre voiture, des jantes en alliage avec de plus gros pneus et vous aurez l'impression de rouler plus vite et d'avoir plus de stabilité. Je pencherai pour plus de stabilité :))
avatar Dr_cube | 
@ ispeed : Pas du tout ! Ce serait plutôt : Au lieu d'avoir un gros moteur qui fait tourner les 4 roues de ton 4x4, tu as 4 petits moteurs indépendants qui font tourner chacun une roue. Du coup le 4x4 consomme moins alors qu'il est plus puissant. Le problème c'est que pour avancer tout droit il faut que les moteurs se synchronisent et partagent des informations, ce qui a un coût en communication.
avatar philus | 
@melaure 'c'est une remarque pour ceux qui ont grandi qu'avec Mac OS avant OS X ;) Mais sur Amiga ou Be OS, ça fait longtemps (1987) qu'on attend pas qu'un programme envoie des résultats.' Nostalgie des vrais noyaux temps réels ;-) Il reste QNX...
avatar kotek | 
Très belle image Dr_cube ! Sinon, concernant l'article, je le trouve un ton en dessous de [url=https://www.macg.co/unes/voir/127129/apple-tire-le-jus-des-processeurs]celui-ci[/url]. Ça sent les espoirs déçus, dommage. Evidemment, tout le monde dira "je le savais, 'faut être un nioube pour croire que ça irait plus vite !". Il n'empêche que beaucoup y ont cru, surtout avec ce genre d'article dithyrambique.
avatar biniou | 
@philus : Pour moi ni AmigaOS, ni BeOS sont des OS temps réel à l'instar de QNX. J'avais oublié. Il n'existe pas que QNX comme OS temps réel ...
avatar Psylo | 
Je me souviens d'un article sur des modifs incluant le realtime pour le kernel d'OSX. Un truc devellopé spécifiquement sur les sources de XNU/Darwin par une équipe de cinglés qui avaient un gros cluster de Xserve G5 pour des calculs scientifiques particuliers. Impossible de remettre la main dessus.
avatar BeePotato | 
@ melaure : « Mais sur Amiga ou Be OS, ça fait longtemps (1987) qu'on attend pas qu'un programme envoie des résultats. » Ah bon ? Tu utilsais déjà Be OS en 1987, toi ? Bravo, tu étais vraiment un précurseur. :-P
avatar Goldevil | 
Article intéressant. Pour moi, la migration de 10.4 vers 10.5 a été normale car il y avait plusieurs nouvelles fonctionnalités disponible et en particulier Time Machine qui est vraiment un gros bonus. J'espère que Snow Leopard apportera quand même des choses en plus qui donneront envie d'y passer. Savoir que mon nouvel OS comporte un Grand Central génial n'est pas intéressant si pour moi cela se résume à accélérer PhotoShop que je n'utilise pas. Par contre, si je constate que la suite iLife est sensiblement accélérée (iPhoto/faces, génération iMovie...), c'est déjà beaucoup plus intéressant. En résumé j'attends que l'expérience utilisateur soit améliorée. Je m'en fout que cela fonctionne avec Grand Central ou avec Transcodeur Libzo-luminique. PS: en fait, je ne m'en fout pas car je suis développeur mais je me mets à la place des utilisateurs ;-)
avatar philus | 
@ biniou: eh si, Amiga OS était temps réel. On pouvait par un timer HARD lancer (via le mode superviseur du 68000) une tâche donnée (il faut bien entendu que la tâche ne dure pas plus longtemps que sa périodicité...). C'est même pour ça qu'il était utilisé, par exemple, pour diriger la rotation des télescopes. Beaucoup ne voient l'Amiga que comme une console de jeux, alors que sont OS était une merveille. Le seul truc qui manquait était une MMU correcte, mais c'était quasi impossible à cause du lien avec les chipset et leur ram dédiée, d'où une mauvaise stabilité si on y mettait des programmes pourris.
avatar biniou | 
@philus: Alors pourquoi Amiga a approché QNX fin des années 90 pour faire un OS multimédia temps réel (je parle bien de RTOS) s'ils avaient déjà un réel système d'exploitation temps réel ? Le point sur lequel on pourrait être d'accord, c'est qu'ils étaient visionnaires chez Amiga mais trop en avance...
avatar benouwa | 
J'ai une petite question perso en lisant ceci ... Je compte monter mon PC (je ne parle pas de mac ici) ... vaut-il mieux un processeur à 2 core plus rapide ou un à 4 core mais plus lent ! Je penchais pour le 4 core mais en lisant l'article je me rend compte qu'on dirait que c'est l'inverse (surtout dans un futur proche !)
avatar benouwa | 
voici les liens des deux procos ! (meme prix !) le 2 core : http://fr.alternate.be/html/builder/proddetail.html?class=cpu&artno=HPHI47&source=builder/listingFrame&source2=needed Le 4 core : http://fr.alternate.be/html/builder/proddetail.html?class=cpu&artno=HPHI4D&source=builder/listingFrame&source2=needed Merci pour vos avis :D
avatar Psylo | 
Je me suis posé cette dure question récement. Le Q8200 est le plus petit des quads cores actuels, vu le peu d'applis et d'OS réellement optimisée, j'opterai plutot pour un E8400 qui est un très bon cpu, réputé pour ses performances étonnantes en overclock, et qui me semble plus efficace. Au final j'ai décidé d'attendre encore quelques mois, mon dualcore 4300 tenant encore largement la route.
avatar françois bayrou | 
"c'est qu'ils étaient visionnaires chez Amiga mais trop en avance... " Oui en particulier Carl Sassenrath, père de l'amiga os, passé rapidement chez apple, et qui a developpé un génialissime language, le Rebol. A essayer absolument.
avatar melaure | 
"Ah bon ? Tu utilsais déjà Be OS en 1987, toi ? Bravo, tu étais vraiment un précurseur. :-P " Tu avais surement bien compris Amiga puis BeOS ;) Enfin bon aujourd'hui OS X n'a rien à voir avec Mac OS Classic même s'il aura fallu plus de dix ans à Apple pour rattraper sur le vrai multi-tâche ;) Quand au gain des multiples core, ce n'est pas encore gagné, on est loin de tous programmer en ce sens (en tout cas pas dans ma boite :p )
avatar XiliX | 
@philus Ben justement c'est le problème... plus tu lance d'appli, plus le timer sera utilisé, moins sera la précision du timer. Or sur un "vrai" système temps réel, ce temps réel doit être assuré quelque soit le nombre de taches exécutées. Amiga OS c'est du temps partagé. (Je l'ai toujours mon Amiga A1200) L'exemple que tu as donné indique justement que Amiga OS n'est pas temps réel. La durée d'exécution d'une tache [b]ne peut[/b] dépasser la périodicité de l'ordonnanceur, au risque d'empiéter sur le temps d'exécution des autres taches. Donc ralentissement des autres taches. Donc plus de temps réel... Je connaissais VRTX et QNX comme système RTOS
avatar XiliX | 
@Melaure... Le premier ordinateur grand public avec un OS multitache était le [url=http://fr.wikipedia.org/wiki/Sinclair_QL]Sinclair QL[/url].J'en avais un avant le A1200.
avatar philus | 
Aucun système multitâche ne peut être temps réel si l'on lui demande plus de travail que le processeur ne peux en exécuter. Un système temps réel est un système qui fait une tâche AU MOMENT où l'on le souhaite quelque-soit le travail en cours. Le timer n'était pas utilisé pour toutes les applis, il y avait un beau petit scheduler pour ça. On pouvait même régler avec précision la priorité des tâches. Je me souviens avoir lancé des calculs dans POV durant 24 heures sans avoir le moindre ralentissement ou la moindre hésitation du système à effectuer autre chose. C'était absolument transparent. Mais il était possible, en outre, de régler certaines tâches temps réelles ( petite par conséquent au vu de ma première ligne ) sur n'importe quelle interruption. En fait , on programmait un chip indépendant (Agnus ou Gary de son petit nom je crois) qui pouvait gérer 256 niveaux d'interruption et arrêter le processeur principal sur timer, réception de données séries, appuie sur touches clavier ou même collision de sprites ( interruption en provenance de - je crois - Denise, si,si) qui était de cette façon parfaitement efficace. Si Commodore a (peut-être, je n'ai pas vérifié l'info) contacté QNX, c'est qu'ils ont laissé partir les cerveaux, mourrir l'OS et appliqué la pire politique commerciale jamais vu en Info. J'ai eu et ai encore un Sinclair QL, il faudrait que je le remonte, il est un peu en vrac, mais avec 512 ko de RAM, attention...
avatar xuyss | 
Si snow se contentait de corriger les bugs amenés avec la X.5, ce serait déjà une bonne chose... Je connais plusieurs entreprises qui ont rétrogradé des machines en X.4...
avatar biniou | 
@XiliX : merci pour ces précisions. Le seul avec lequel j'ai travaillé en travaux dirigés, c'est µC/OSII. @philus : "Un système temps réel est un système qui fait une tâche AU MOMENT où l'on le souhaite quelque-soit le travail en cours." Pour moi, c'est pas du tout ça car l'instantanéité n'existe pas même en informatique temps réel. Rien que la propagation de l'information n'est pas instantanée. Une bonne définition : "Un système temps réel est une association logiciel/matériel où le logiciel permet, entre autre, une gestion adéquate des ressources matérielles en vue de remplir certaines tâches ou fonctions dans des limites temporelles bien précises". Cette notion de déterminisme temporel caractérise les systèmes temps réel. Au contraire de nos OS actuels qui sont non déterministes : il n'y a pas de vérification qu'une tâche soit exécutée dans un délai imparti. De ce que j'ai lu Amiga a approché QNX parce qu'ils voulaient utiliser les meilleur des deux mondes et proposer un OS multitâche multimédia solide. Ce qu'ils n'ont jamais pu faire car Amiga Inc. s'est alors tourné vers le noyau Linux (http://obligement.free.fr/articles/amiga_histoire_1999.php).
avatar YannK | 
Je pense surtout que cet article vise un peu les développeurs. Quand on sait que quasiment personne n'optimise son soft pour du Quad Core, même chez certains gros pros, l'article prend tout son sens. C'est bien qu'intel nous vende du quad, mais encore faut il que des solutions optimisées pour 4 coeurs soient proposées par les développeurs. De l'autre côté, on voit Adobe qui va demander à Nvidia d'utiliser Cuda pour améliorer Flash ( soit une fonction de base la plupart du temps chez l'utilisateur final qui pense que flash = streaming )... les mecs qui codent pour Adobe sont quand même la honte de la profession... Déjà qu'ils ne connaissent pas Core Image... alors imaginer Open CL. Ho mais attendez... il faudrait déjà qu'ils passent leur CS en full cocoa et en 64 bits, ensuite ils pourront peut être se rendre compte qu'il existe des processeurs à 4 coeurs...
avatar erom | 
le but de SL est peut être moins d'apporter des nouveautés directement visibles et utilisables par l'utilisateur que des nouveautés exploitables au travers des applications qui en tirent parti. A défaut d'apporter une ou deux grosses nouveautés "qui déchire", on peut espérer que SL soit optimisé sur de très nombreuses fonctions et détails. Perso j'attend plus de facilité à personnaliser SL. J'imagine que cela pourrait être possible à travers un store dédié?
avatar 6ix | 
@philus : "Un système temps réel est un système qui fait une tâche AU MOMENT où l'on le souhaite quelque-soit le travail en cours." Comme le dit biniou, un système n'est [b]justement pas[/b] ça! Il s'agit bien d'un système multi-tâches où celles-ci respectent des contraintes temporelles. Rien ne dit qu'une tâche démarre forcément au moment où elle est appelée.
avatar XiliX | 
@biniou C'est exactement ça... on confond souvent le temps réel et l'instantanéité. C'est du temps réel, si on demande à une tache d'attendre 5 mnt, elle attendra 5 mnt. Qu'elle soit seule ou plusieurs @philus [quote]Aucun système multitâche ne peut être temps réel si l'on lui demande plus de travail que le processeur ne peux en exécuter. Un système temps réel est un système qui fait une tâche AU MOMENT où l'on le souhaite quelque-soit le travail en cours.[/quote] Un système temps réel possède un nombre fini de taches qui peut se lancer en même temps. Ce nombre fix est nécessaire afin de déterminer la durée maximale l'exécution d'une tache par l'ordonnanceur (scheduler). De ce fait, qu'il y ait une tache ou 10 taches (par exemple c'est le nombre max défini par l'OS), chaque tache a la même durée de vie. Dans un système temps réel, aucun tache ne peux s'exécuter plus que le temps attribué par l'ordonnanceur. Sauf pour le "monitor" A l'opposé, un OS temps partagé divise ou ajoute le temps du processeur en fonction de taches actives. Donc une tache exécutée prendra la totalité du temps processeur. On lance une deuxième tache, elle récupère une part du temps de la première tache... et ainsi de suite. Et si on quitte une application, son temps sera réattribué aux autre taches actives.
avatar Psylo | 
@Yannk [i]il faudrait déjà qu'ils passent leur CS en full cocoa et en 64 bits[/i] (mode troll on) En même temps, le kernel de leopard n'étant toujours pas du "vrai" pure full 64 bits....(mode troll off) Vivement Snow Leopard.
avatar poco | 
Perso, ce qui m'intéresse le plus (pour mon usage Particulier et Professionnel) c'est que le système démarre "instantanément" (comme les TV d'il y a 10 ans ;-) ou comme un iPhone), que je puisse lancer Mail, Safari, OpenOffice et FileMaker en même temps sans avoir le temps d'aller prendre un café... Après celà, si Mail ou OpenOffice savent écrire plus vite que moi au clavier, tant mieux pour eux :-) Blague à part, il me semble que plus on dispose de puissance brute dans les machines modernes plus on perde du temps à .... les attendre. Par exemple, un Powerbook une fois utilisé depuis plus de 6 mois est poussif au démarrage (même avec Onyx hebdomadairement). Ma Télé écran plat ne s'allume plus ni change de chaîne "instantanément" comme les anciennes TV à écran bêtement "pas plat", le lecteur BlueRay met 3 plombes à charger un disque, alors que le lecteur DVD en mettait 1/2 heure et la bonne vieille K7 vidéo 30 secondes (j'exagère à peine; là...). On a pourtant dans chaque foyer plus de puissance de calcul que dans les Fusées Apolo qui sont allées sur la Lune il y a plus de 40 ans. Mais que se passe-t-il? Windows 3.5 était incomparablement plus véloce sur les mobylettes à sa disposition que Vista sur les fusées atomiques que sont les PC actuels. Ma 205 GTI 1.6 des années 80 avec 105 CV accélérait plus et freinait aussi court que des "GTI" (équivalents) actuelles avec 200CV et plus. Toute ces avancées ont été noyées dans de la cosmétique, du gonflage d'hélice (comme on dit dans l'Armée de l'Air), du pur Marketing (wouaaa, super l'icone en 3D animée). Pas ou peu de "vraies" innovations qui utilisent réellement la puissance des technologies actuelles au profit du Marketing. Just my $0.02
avatar Sékiltoyai | 
Alors je suis désolé de contredire la majorité des commentaires mais oui c'est une très grosse avancée, et sur de très nombreux points. Je ne sais pas exactement en quoi Apple a décidé d'exploiter le parallélisme, mais imaginons que les fonctions sort ou strcmp se font sur le GPU, c'est déjà pas mal, quand ce genre de fonctions sont utilisées (directement ou indirectement) dans une très grosse majorité de programmes. De même, si le noyau fonctionnait en parallélisé sur les différents algorithmes de calcul, ce pourrait être un gain de perfs significatif (à part bien sûr le temps de comminucation). Après je doute qu'ils soient allés jusque là… Je suppose donc qu'ils n'ont dû s'occuper que des applications Apple, mais là aussi franchement, un iLife qui fait les calculs d'image en parallélisé, un iWork qui fait ses recherches de texte en parallélisé, un iTunes qui lit la musique en parallélisé, ils tireraient pleinement partie de la puissance su GPU. Même le Finder peut être plus rapide. Il y a énormément d'algorithmes qui moyennant adaptation, tirent partie de la puissance du parallélisme. Après, oui, c'est vrai, il faut programmer différemment, mais c'est notre boulot hein… Quant aux nouvelles API, oui c'est aussi très significatif. Comment voulez-vous inciter des gens à utiliser le multi-processing/multi-core quand c'est galère à gérer ? Peut être que les applis multithread sont encore peu répandues (et encore, c'est faux, les grosses applications le sont). Mais avec une API simple d'utilisation, de telles pratiques se répandront. En définitive, c'est pour moi une révolution aussi bien à court terme qu'à long terme. A court terme, cela promet des vrais gains de performance, et c'est la première fois qu'un OS important se lance clairement dans le multi-quelquechose. A long terme, c'est un véritable appel aux développeurs, pour adapter leurs algorithmes à la programmation parallèle ou pour utiliser pleinement le multhreading. Donc -1 pour cet article…
avatar Manu | 
N'ayant pu lire tous les commentaires, je voudrai néanmoins faire remarquer ceci. La plus grande exploitation des architectures multicores c'est pas vraiment les applications elles même mais plutôt la Virtualisation. En effet au lieu de raisonner en disant je vais exploiter les processeurs en divisant mon application et paralleliser les traitements. On va plutôt diviser l'application pour faire executer chaque composant dans une machine virtuelle. Au système de me permettre à mes composants d'utiliser des ressources partageables elles même éventuellement virtualisées.
avatar philus | 
@XiliX @Biniou Si je suis bien d'accord avec votre description d'un système 'pure' temps réel, vous oubliez que nous parlons ici d'informatique personnelle ou de bureautique pro. Les OS que vous décrivez sont plutôt des OS de type informatique industrielle, régulation ou informatique embarquée (avionique). Comment pouvez-vous demander à un micro-ordinateur de ne pouvoir effectuer que 10 tâches (avec une faible charge pour chacune) simultanément afin d'être sûr qu'elles le seront dans les temps impartis? Le téléchargement d'une page web dépend de la vitesse de son navigateur, mais aussi de toute une chaîne de transmission des informations. Si l'on reprend votre définition, il est impossible d'encoder un film en h.264 sur un os 'temps réel'... Votre définition est très 'académique' et théorique. En micro-informatique, que demande l'utilisateur ? Il veut que l'os réagisse à ses demandes. Celles-ci ne sont pas 'je veux que 'mon fichier soit encodé en tant de mn', mais plutôt: si un fax arrive, mon modem décroche tout de suite. Si je clique sur une icône, elle doit 's'enfoncer' sur le champ, si je détecte par domotique un ouverture de porte, je dois allumer la lumière instantanément. La plupart de ces actions 'temps réel' sont liée à une action extérieur au micro, et donc gérable par des interruptions. Le pire est que certaines supervisions industrielle (de type Winzcon ou Wincc) sont exécutées sur des PC et devrait l'être sur des OS temps réels car elles sont du type 'temps rée'l que vous décrivez. La notion de 'temps réel' qui n'existe pas à cause du temps de propagation électrique est fallacieuse, si l'on pousse le bouchon un peu loin, on peut se demander si à une échelle suffisamment petite, le temps existe. Alors ne soyons pas universitaires ou doctorants, en micro, de façon pragmatique, le temps réel, c'est juste la capacité d'un OS à réagir (dans des limites raisonnables) aux actions de l'utilisateur ou des périphériques.
avatar biniou | 
@philus: Oui je suis académique et oui je suis doctorant. Et encore plus je suis pointilleux. Quand Amiga parlais de RTOS, il ne parlait pas de ce que tu dis mais d'un vrai RTOS que ce soit du SRT ou du HRT. Pas question de temps réel pur (j'en avais jamais entendu parler). On parle de temps réel en informatique pour tout et rien. Un système temps réel est un système déterministe. C'est quelque chose de clairement défini en informatique. L'informatique est une science et non du bricolage. On a défini des termes précis qui permettent de décrire ce qu'on fait. Et pour moi, sur base de mes travaux de recherche dans le multimédia, je suis convaincu qu'Amiga partait dans le bon sens. Oui, aujourd'hui on n'a pas d'encodeur ou décodeur vidéo temps réel (à ma connaissance), ni de réseau de terrain multimédia permettant le transfert de données importantes. Mais c'est pas parce que ça n'existe pas qu'il n'y a pas de recherche dans ce domaine (et ce depuis plus de 20 ans). Pourtant, que ce soit pour les jeux, des applications multimédias ou industrielles (légères pas le contrôle de toute une chaîne de production, en tout cas pas encore demain), les ordinateurs grands publics ont tout à gagner de l'informatique temps réel. Alors comment faire ? Transformer nos OS en OS temps réel ou faire un système hybride avec plusieurs clock : temps partagé et temps réel ? On a de plus en plus de média à jouer ou enregistrer en même temps (parfois de manière distribuée) et on n'est ni capable de les jouer de manière synchrone (ou en tout cas de s'en assurer car l'OS règne), ni les enregistrer de manière synchrone. Les performances (et tu as vu ma grosse ... bécane) c'est bien mais la qualité c'est encore mieux.
avatar philus | 
J'avais bien flairé l'universitaire, quel pif ! Si tu veux être pointilleux, le Amiga dont tu parles n'a rien à voir avec le Commodore Amiga , machine bien connue. Le Amiga qui est allé voir QNX, c'est un nom de marque qui, rachetée par Escom et n'ayant rien compris à l'Amiga OS, voulait se faire un nouvel OS (avec la même interface utilisateur pour tromper les gogos) à partir de QNX. Un VRAI os temps réel serait à mon avis un gâchis de ressource pour l'utilisateur moyen. Mieux vaut en matière de rapport qualité/prix un OS où certaines tâches s'exécutent quand elles en ont le temps et selon leur priorité, et d'autres, 'temps réels', moins nombreuses et ne nécessitant que peu de ressources, se lançant au moment précis où l'on en a besoin. Je suis ingénieur et donc quelqu'un de pragmatique qui cherche, pour le coût et l'utilisation de ressources le plus faible possible, à donner à l'utilisateur ce qu'il recherche. Pas d'idées préconçues, juste des résultats.
avatar philus | 
PS: ne pas prendre mon message précédent comme agressif, c'est juste que je pense qu'Apple à plus intérêt à produire des millions d'ordinateur réactifs plutôt que quelques prototypes invendables. Mais la recherche fondamentale est bien entendue indispensable...même en info
avatar XiliX | 
@philus [quote]PS: ne pas prendre mon message précédent comme agressif, c'est juste que je pense qu'Apple à plus intérêt à produire des millions d'ordinateur réactifs plutôt que quelques prototypes invendables.[/quote] Don't worry... :) c'est juste un débat passionné et entre passionnés :) [quote]Si je suis bien d'accord avec votre description d'un système 'pure' temps réel, vous oubliez que nous parlons ici d'informatique personnelle ou de bureautique pro. Les OS que vous décrivez sont plutôt des OS de type informatique industrielle, régulation ou informatique embarquée (avionique). Comment pouvez-vous demander à un micro-ordinateur de ne pouvoir effectuer que 10 tâches (avec une faible charge pour chacune) simultanément afin d'être sûr qu'elles le seront dans les temps impartis? Le téléchargement d'une page web dépend de la vitesse de son navigateur, mais aussi de toute une chaîne de transmission des informations. Si l'on reprend votre définition, il est impossible d'encoder un film en h.264 sur un os 'temps réel'...[/quote] Tout à fait d'accord, c'est pour ça que j'ai bien précisé que les OS comme Windows, OS X, Linux (sauf RTLinux)... etc sont des OS multitâches [b]temps partagé[/b]. Ce n'est pas pour être doctorant, mais il est important de différencier ces deux notions, OS multitâches temps réel et OS multitâches temps partagé. Ces deux environnements ne sont pas destinés au même public. L'OS temps réel est plus pour l'industrie et l'OS temps partagé pour une utilisation généraliste.
avatar Arnaud de la Grandière | 
@ Sékiltoyai : j'ai bien peur que quelque chose t'échapppe : les fonctions dont tu parles ne peuvent être transférées au GPU. Il s'agit de fonctions C++, et non d'API de Mac OS X, et le Xcode ne va pas comme par magie transformer ces fonctions en commandes GPGPU automatiquement (d'ailleurs ça impliquerait qu'une simple recompilation suffise pour utiliser le GPU…) Pour pouvoir tirer parti du GPU, il faudra faire appel au jeu d'API spécifique d'OpenCL. Et donc revoir l'architecture du logiciel. Et donc faire face aux problématiques évoquées dans l'article.
avatar biniou | 
@philus : non non je ne le prends comme un message agressif. Je comprends ce que tu dis, je suis aussi ingénieur. Je me place pas dans un contexte de rentabilité mais plus dans un cadre de recherche "fondamentale". Je suis d'accord avec toi qu'Amiga Inc. n'était pas Commodore Amiga ou encore le Amiga Inc. d'origine. Il n'empêche qu'ils avaient d'excellente idée forts de la culture de l'entreprise et de son expertise (qu'Escom puis d'autres ont racheté). Je suis aussi d'accord avec vous sur les ordinateurs grands publics. Mais pour moi dans les années à venir (dans 10-20 ans peut-être), la question d'un système hybride viendra sur le tapis. L'informatique comme on le voit se transforme (doucement mais surement), il suffit de regarder le développement du mobile computing. Quand on sait qu'il existe une variante de symbian qui est presque RTOS, l'industrie a compris depuis un petit temps que le RTOS ne sera peut-être pas toujours cantonné à l'informatique industrielle. Je voulais juste appuyer le fait que parfois pour avancer en informatique, il faudrait arrêter de penser puissance mais plutôt architecture hardware/software. Et on a, comme dans beaucoup d'autres domaines technologiques, une grande expérience dans l'industrie qui pourrait s'avérer utile pour l'informatique de demain.

Pages

CONNEXION UTILISATEUR