Retour au site
Connexion :
Abonnement NewsletterOk
 

Intel: aider les développeurs à penser multi-coeurs

Brève Processeur

IDF - Wafer Polaris (le retour) -Jerry Bautista
Parallèlement aux annonces en matière de photonique, Intel réaffirme en cette journée de pré-ouverture de l'IDF sa volonté d'aider les développeurs à programmer leurs logiciels pour tirer profit des processeurs double ou quadri-coeurs. Afin de promouvoir ses différents outils de développement logiciel auprès de la communauté des développeurs, le fondeur a mis en ligne courant août un nouveau site Web baptisé Whatif.intel.com. Celui-ci contient des liens vers les compilateurs et autres débuggueurs maison mais également des liens vers les blogs de certains ingénieurs d'Intel.

Intel annonce également, et c'est probablement nettement plus significatif, la disponibilité d'un compilateur, encore à l'état de prototype, implémentant le STM ou Software transactional memory ou encore mémoire transactionnelle en français dans le texte. Il s'agit ici d'accélérer la création d'applications parallèle en évitant au maximum les locks ou blocages de certaines régions de la mémoire. Les locks consistent à un blocage de certaines zones mémoire, blocage définit par le développeur, afin d'éviter des collisions qui pourraient survenir lorsque deux processus souhaitent accéder à des données identiques. La collision ayant pour effet un crash du système. Rendus nécessaires donc de par la progression des applications multi-threadées, les locks ont pour effet négatif de réduire la bande passante mémoire. La solution préconisée par Intel est d'ajouter un nouveau logiciel système qui gère automatiquement les accès parallèle à la mémoire et suit les différents états de cette dernière. Lorsqu'une collision est sur le point d'intervenir, le système réinitialise automatiquement l'état de la mémoire, laisse le processus se terminer et reprend une exécution normale.

Intel STM


Dans la foulée, Intel évoque Ct afin de rendre la programmation multi-coeurs toujours plus facile en ajoutant des opérateurs et des structures de données parallèles aux langages C et C++ tout en conservant l'utilisation des compilateurs C et C++ actuels. Enfin, dans le cadre de ses recherches sur les processeurs Terascale, Intel envisage un nouveau modèle de programmation des accélérateurs. Rappelons pour commencer que les accélérateurs sont ses cartes dédiées à l'accélération matérielle d'une tâche spécifique comme peut l'être par exemple une carte graphique ou une carte dédiée à la physique. Aujourd'hui, l'ensemble de ces accélérateurs utilisent pour leur fonctionnement des pilotes intégrés étroitement au système d'exploitation. L'idée d'Intel serait de faire apparaître ces accélérateurs comme une partie du processeur afin de faciliter le développement de logiciels tirant profit des accélérateurs, ceux-ci se programmant alors comme de simples extensions à l'architecture Intel. Baptisée Exo, pour exosquelette, la technologie d'Intel n'est pas tout à fait innocente puisqu'elle concerne là encore le projet de processeur terascale. Intel précise en effet que son processeur à 80 coeurs pourrait être doté de coeurs aux fonctions hétérogènes : Exo est ici un excellent moyen de les programmer le plus simplement possible.

Intel EXO
Actu précédente
Brève suivante
Les Commentaires des lecteurs
_
Continuer sur le forum
44 messages
1
2
3
>
 
le 18 Sept. 07 à 03h23
Edition
 
haha, Intel fait le travail de MS, 1 logiciel pareil aurai du etre inclus dans l'OS.
 
le 18 Sept. 07 à 03h31
Edition
 
LaTeamClubic a écrit:

Intel annonce également, et c'est probablement nettement plus significatif, la disponibilité d'un compilateur, encore à l'état de prototype, implémentant le STM ou Software transactional memory ou encore mémoire transactionnelle en français dans le texte. Il s'agit ici d'accélérer la création d'applications parallèle en évitant au maximum les locks ou blocages de certaines régions de la mémoire. Les locks consistent à un blocage de certaines zones mémoire, blocage définit par le développeur, afin d'éviter des collisions qui pourraient survenir lorsque deux processus souhaitent accéder à des données identiques. La collision ayant pour effet un crash du système. Rendus nécessaires donc de par la progression des applications multi-threadées, les locks ont pour effet négatif de réduire la bande passante mémoire. La solution préconisée par Intel est d'ajouter un nouveau logiciel système qui gère automatiquement les accès parallèle à la mémoire et suit les différents états de cette dernière. Lorsqu'une collision est sur le point d'intervenir, le système réinitialise automatiquement l'état de la mémoire, laisse le processus se terminer et reprend une exécution normale.

Rien compris, je comprends pas de quel locks ils parlent ...
Si ils parlent des memory lock en C++ que l'on utilise en multithread (style EnterCriticalSection/LeaveCriticalSection) ou autre, ça n'a jamais crashé un programme, encore moins le système, puisque c'est prévu pour ça dans le kernel, donc je vois vraiment pas de quoi ils parlent... :neutre:
Si une zone mémoire est bloquée par un thread, le thread suivant qui veut y accéder attend simplement que le premier thread en sorte, et bloque à son tour la mémoire pour le suivant, l'attente des threads à l'entrée de ces zones est prévue et inévitable...:neutre:
Edité le 18/09/2007 à 03:32
 
le 18 Sept. 07 à 04h56
Edition
 
1coeur 2coeur 3coeur 4coeur 5coeur 6...
au putin jose mmem pas imaginer les nombre de coeur qu il i aura en 2015

non mais franchement messieurs de intel vous n en avait pas marre des multi coeur , a croire qu il sont plus facil a faire les processeceur monocoeurs....
 
le 18 Sept. 07 à 06h36
Edition
 
catseye:
"Rien compris, je comprends pas de quel locks ils parlent ...
Si ils parlent des memory lock en C++ que l'on utilise en multithread (style EnterCriticalSection/LeaveCriticalSection) ou autre, ça n'a jamais crashé un programme, encore moins le système, puisque c'est prévu pour ça dans le kernel, donc je vois vraiment pas de quoi ils parlent... :neutre:"

Justement, le lock *évitent* les crash. C'est quand on ne les utilise pas que ça crash (écriture simultanée)

"Les locks consistent à un blocage de certaines zones mémoire, blocage définit par le développeur, **afin d'éviter des collisions** qui pourraient survenir lorsque deux processus souhaitent accéder à des données identiques."
 
le 18 Sept. 07 à 06h49
Edition
 
"1coeur 2coeur 3coeur 4coeur 5coeur 6...
au putin jose mmem pas imaginer les nombre de coeur qu il i aura en 2015

non mais franchement messieurs de intel vous n en avait pas marre des multi coeur , a croire qu il sont plus facil a faire les processeceur monocoeurs...."

bah comme il le disent la dessus il sont deja a 80 coeurs donc .... ^^

belle innovation je trouve bon franchement
qui pour un 80 coeur extreme edition a 60ghz et 160 mo de cache ?

si sa donnera ca ^^Oo^^
 
le 18 Sept. 07 à 07h25
Edition
 
Pas mieux Kurouele :) ;)
 
le 18 Sept. 07 à 07h29
Edition
 
voilà pour ceux qui ont encore faim www.presence-pc.com...

www.generation-nt.com...

www.clubic.com...
 
le 18 Sept. 07 à 07h30
Edition
 
kuroueie a écrit:
catseye:
"Rien compris, je comprends pas de quel locks ils parlent ...
Si ils parlent des memory lock en C++ que l'on utilise en multithread (style EnterCriticalSection/LeaveCriticalSection) ou autre, ça n'a jamais crashé un programme, encore moins le système, puisque c'est prévu pour ça dans le kernel, donc je vois vraiment pas de quoi ils parlent... :neutre:"

Justement, le lock *évitent* les crash. C'est quand on ne les utilise pas que ça crash (écriture simultanée)

"Les locks consistent à un blocage de certaines zones mémoire, blocage définit par le développeur, **afin d'éviter des collisions** qui pourraient survenir lorsque deux processus souhaitent accéder à des données identiques."

J'en connais un qui avait bien besoin d'aller dormir :paf:
 
le 18 Sept. 07 à 08h12
Edition
 
mkey a écrit:
haha, Intel fait le travail de MS, 1 logiciel pareil aurai du etre inclus dans l'OS.


bah non justement, qui mieux qu'intel sait comment piloter le bouzin ? Quand à MS... bah tu n'es surement pas sans savoir qu'il y a d'autres OS... au moins Intel développe une solution non dépendante de l'OS :sarcastic:

les trolls à 3h du mat' c'est chaud :ane:
 
le 18 Sept. 07 à 08h35
Edition
 
dark neo genesis : leur 80 coeurs est quand meme hyper symplifier par rapport aux proc habituels.

ils sont specifique a certain calcul donc ne sont pas comparable.

c'est comme comparer 80 fours a biscuits d'un cote et 2/4 usines de gateaux de l'autre. oui ca va plus vite a faire les biscuits mais nonca ne se compare pas. ca authorise juste a dire , ou va arriver dans une aire ou le nombre de coeur va se multiplier.

c'est pas bete le raisonnement de intel. pour reprendre mon example : c'est comme si 2 usine se partageaient le meme parking, si le reponsable logistique dit va te garer la, alors qu'il y a deja un camion, il faut un autre responsable qui gere specifiquement le parking. meme si les chauffeurs de camions ne se rentre pas dedans (lock) dans le cas d'une utilisation d'une meme place. genre un logicielle de gestion de parking (heu non de memoire ;) )
 
Contacter le membreVoir profil
KoV
le 18 Sept. 07 à 09h21
Edition
 
C'est plus que du logiciel. C'est une facon d'utiliser un couple processeur/mémoire qui est à revoir.
Je trouve dommage que ce système ne soit pas intégré directement dans le processeur.
 
le 18 Sept. 07 à 09h34
Edition
 
+1 Kov, c'est gérer en logiciel les défauts matériels...
ça devrait être géré nativement par les procs puisque c'est une contrainte connue du multiproc
 
le 18 Sept. 07 à 09h59
Edition
 
LaTeamClubic a écrit:

Intel annonce également, et c'est probablement nettement plus significatif, la disponibilité d'un compilateur, encore à l'état de prototype, implémentant le STM ou Software transactional memory ou encore mémoire transactionnelle en français dans le texte.

Non, pas dans le texte, a moins qu'Intel se soit exprime en Francais a ce moment precis. Exemple :
"We'd like to unveil the brand new mémoire transactionnelle implementing compiler."
 
le 18 Sept. 07 à 10h05
Edition
 
Geppeto > en même temps faut voir le nombre de coeurs nécessaires pour cette tâche logicielle. Si c'est juste un ou deux, je comprends qu'ils aient pas envie de se prendre la tête à intégrer un contrôleur spécifique.
 
le 18 Sept. 07 à 10h17
Edition
 
catseye a écrit:

Rien compris, je comprends pas de quel locks ils parlent ...
Si ils parlent des memory lock en C++ que l'on utilise en multithread (style EnterCriticalSection/LeaveCriticalSection) ou autre, ça n'a jamais crashé un programme, encore moins le système, puisque c'est prévu pour ça dans le kernel, donc je vois vraiment pas de quoi ils parlent... :neutre:
Si une zone mémoire est bloquée par un thread, le thread suivant qui veut y accéder attend simplement que le premier thread en sorte, et bloque à son tour la mémoire pour le suivant, l'attente des threads à l'entrée de ces zones est prévue et inévitable...:neutre:

Il me semble que la mémoire dont parle Intel dans cette article est la mémoire cache L1 et L2 des processeurs, pas la mémoire ram. Il ne me semble pas que cette mémoire est gérée par le kernel et comme elle est partagée par les différents noyaux, imagine si un noyau modifie celle utilisée par un autre ce que ça peut donner.
 
le 18 Sept. 07 à 10h20
Edition
 
Dralexe a écrit:
1coeur 2coeur 3coeur 4coeur 5coeur 6...
au putin jose mmem pas imaginer les nombre de coeur qu il i aura en 2015

non mais franchement messieurs de intel vous n en avait pas marre des multi coeur , a croire qu il sont plus facil a faire les processeceur monocoeurs....

La solution n'est pas forcement mauvaise. Il y a quelques annees pour jouer il fallait arreter son lecteur audio, sortir de Office etc. Aujourd'hui tu peux jouer en ecoutant ta musique, voir en faisant une analyse anti-virus. Le fait de traiter differentes taches en parallele rends l'approche de coeurs multiple bien plus interessante.
 
le 18 Sept. 07 à 10h34
Edition
 
LaTeamClubic a écrit:
Lorsqu'une collision est sur le point d'intervenir, le système réinitialise automatiquement l'état de la mémoire, laisse le processus se terminer et reprend une exécution normale.

Collision ?

Il doivent parler de problème d'interbloquage non ? une ressource RA qui est verrouillée par un processus A qui besoin d'une ressource RB verrouillée par B qui a besoin de RA.

Dans ce cas la, on arrête tout, on déverrouille tout, et on laisse un des processus A s'exécuter complètement puis B.
Edité le 18/09/2007 à 10:35
 
le 18 Sept. 07 à 10h37
Edition
 
Sun aussi travaille sur ce sujet: leur prochain cpu Sparc "Rock", prévu pour 2008, l'intégrera en hard.

research.sun.com...

"Of particular importance, teamwork between Sun Labs and Sun Microelectronics has resulted in the first implementation of Hardware Transactional Memory for a general-purpose processor (Rock)."

The problem, in a word, is concurrency. In the emerging world of multi-processor systems, multi-core chips, multi-threaded applications, and massive parallelism, it becomes more and more difficult to synchronize concurrent access to shared memory by multiple threads. This makes it more difficult to ensure that the right operations are taking place at the right time, without interference or disruption, at high performance. For many organizations, the net result is that applications written for multi- processing workloads are currently achieving only 5-10% of the theoretical peak performance of the system.
Edité le 18/09/2007 à 10:39
 
le 18 Sept. 07 à 10h38
Edition
 
daroyce a écrit:
Dralexe a écrit:
1coeur 2coeur 3coeur 4coeur 5coeur 6...
au putin jose mmem pas imaginer les nombre de coeur qu il i aura en 2015

non mais franchement messieurs de intel vous n en avait pas marre des multi coeur , a croire qu il sont plus facil a faire les processeceur monocoeurs....

La solution n'est pas forcement mauvaise. Il y a quelques annees pour jouer il fallait arreter son lecteur audio, sortir de Office etc. Aujourd'hui tu peux jouer en ecoutant ta musique, voir en faisant une analyse anti-virus. Le fait de traiter differentes taches en parallele rends l'approche de coeurs multiple bien plus interessante.

Oui sauf qu'il y a des limites.
Le nombre de programmes exécutés par l'utilisateur ne va pas continuer à croître aussi vite que la multiplication des noyaux. Ensuite, certaines applications sont difficilement parallélisable. Et enfin, ça va être très vite une usine à gaz à programmer.
 
Continuer sur le forum
44 messages
1
2
3
>
 



 
Clubic.com
 
Achetez-facile.com
 
Jeuxvideo.fr
 
neteco.com
 
mobinaute.com