Salut.
des fonctionnalités d'amélioration de performances pour mieux tirer partie à la fois des processeurs multi-coeurs (Grand Central) et des cartes graphiques en tant qu'unité de calcul (OpenCL)
Contrairement à ce que le gens pensent, openCL ne sert pas (seulement tout du moins) à utiliser la puissance des GPU.
OpenCL est un framework (et un langage) qui facilitent la programmation parallèle en environnement hétérogène.
L'objectif est de répondre à un problème simple : Comment écrire un code unique et optimisé pour des architectures différentes.
En effet, on ne conçois pas un programme de la même façon si il doit être exécuté par exemple, sur un GPU en lieu et place d'un CPU.
Une autre problématique est la suivante, si demain j'écris un programme et le commercialise, celui-ci sera exécuté sur des machines totalement différentes. Certains utilisateurs vont utiliser le dernier Mac Pro (8 cores physiques, 16 processeurs logiques, potentiellement un gros GPU), d'autres un simple Mac mini dual core avec un GPU intégré.
Comment concevoir mon programme pour qu'il soit optimisé (autant que possible) pour ces deux configurations ? OpenCL apporte des éléments de réponse mais Apple semble vouloir aller plus loin. C'est là que GrandCentral entre en jeu.
L'objectif est d'intercepter les flots d'instructions, les analyser, les découper et les rediriger vers les différentes unités de calcul disponibles (CPU ou GPU). Il y a un point sur lequel je n'ai pas réussi à trouver d'information, est-ce que GrandCentral est capable d'identifier les traitements qui peuvent être mis en parallèle. Je m'explique, imaginons que j'ai écrit un programme qui est totalement séquentiel (pas de traitement parallèle). Dans les faits, en analysant un peu mon programme, il y a de grande chance que je puisse identifier des morceaux de traitements indépendants (qui peuvent donc être traités en parallèle). GrandCentral est-il capable de faire, à la volée, ce travail ? Si c'est le cas, une application non prévue pour fonctionner en parallèle pourrait tout de même profiter des avantages des processeurs multicore.
Ces deux technologies soulèvent cependant un problème. Actuellement, quand j'ai terminé mon programme il faut que je le compile. En d'autres termes, je transforme mon code (un ensemble de fichiers texte) en un ensemble d'instructions compréhensibles par un processeur.
Tous les processeurs ne comprennent pas les même instructions. En effet ils sont prévus pour exécuter un jeu d'instructions spécifique, x86 pour les processeurs intel, PowerPC pour IBM. Ceci est également vrai pour nos GPU, ils disposent d'un jeu d'instruction qui leur est propre (qui n'est pas le même chez ATI et NVidia).
Si vous avez bien suivi, quand je compile mon programme, je le lie de facto à une architecture particulière. Ce problème est bien connu des utilisateurs Mac, le parc de machine étant équipé à la fois de processeurs intel (x86), IBM (PowerPC) et Motorola/Freescale (PowerPC). L'Universal Binary est la réponse à ce problème (en fait, on compile deux fois le programme et on obtient deux exécutables, un pour les x86 et un pour les PowerPC).
Avec OpenCL et GrandCentral ce problème devient encore plus complexe. En effet, l'unité de calcul (CPU ou GPU) qui sera utilisée pour exécuter le code que j'ai créé ne sera déterminée qu'au moment de l'exécution. Comment compiler mon code pour qu'il soit à la fois exécutable par un processeur PowerPC, x86 ou encore un GPU NVidia ou ATI ?
La solution Universal Binary ne suffira pas (et de toute façon ne conviendra pas) ici.
Pour faire face à cette problématique, Apple a eu la bonne idée d'utiliser le compilateur LLVM (Low Level Virtual Machine).
En vulgarisant (beaucoup
) LLVM est composé de deux éléments principaux, un compilateur et des machines virtuelles de bas niveau. Le compilateur de LLVM se contente en réalité de traduire un programme (écris dans un langage quelconque) en un jeu d'instructions à destination d'un processeur virtuel (à la manière du ByteCode Java). Lorsque l'on va exécuter le programme, les instructions virtuelles seront exécutées par une machine virtuelle qui se chargera de traduire les instructions virtuelles en "vraies" instructions compréhensibles par le processeur (intel par exemple) de la machine (on parle de compilation à la volée, ou JIT = "Just In Time"). Il suffit alors pour Apple de créer une machine virtuelle optimisée pour chaque type de processeur. LLVM se chargera de choisir la bonne machine virtuelle au moment de l'exécution. Si vous me suivez toujours (et que vous avez eu le courage d'arriver jusqu'ici) vous devriez comprendre tout l'intérêt de LLVM si il est utilisé conjointement avec GrandCentral (au passage, Universal Binary devient complètement inutile).
Si je résume, voici comment vont interagir les différentes nouveautés de Snow Leopard.
En m'appuyant sur OpenCL, je peux écrire plus facilement une application profitant de la programmation parallèle.
En compilant avec LLVM, je m'assure que mon programme pourra fonctionner sur des environnements hétérogènes (jeu d'instructions virtuelles).
À l'exécution, GrandCentral se chargera de répartir les différents flots d'instructions vers les unités de calcul appropriées (CPU ou GPU).
Cette répartition effectuées, LLVM utilisera alors la bonne machine virtuelle pour compiler à la voler les instructions virtuelles et les faire exécuter par l'unité de calcul désignée par GrandCentral.
Au final, ce qu'il faut retenir, c'est que les nouveautés apportées par SnowLeopard ne sont pas dissociables. On ne peut pas parler de GrandCentral sans parler d'OpenCL ou de LLVM. C'est la synergie entre toutes ces technologies qui devraient permettre à Snow Leopard de se distinguer.
@+
iota
