Double question : Dual Core et HeapRésolu

Question

Salut !

J'aurais deux questions complétement différentes :

1) Comment fait-on pour gérer les processeurs double coeur (ou plus) en ASM ?

2) J'utilise beaucoup la Heap (le Tas) , pour y mettre des back buffer , et j'aurais voulut savoir si les accés Heap sont plus lent que les accés à la mémoire standard ?

Merci d'avance !

_dune2_ · Accepted Answer

Pour la programmation parallèle, oui bien sûr que tu peux paralléliser tes opérations ;)

Il te suffit de séparer la programmation de l'affichage dans un thread et le reste dans un autre thread par exemple.
Le re-scheduler du système pourra alors répartir la charge sur les 2 CPUs (en fonction de la disponibilité et en tenant compte des autres tâches du système; mais en supposant que seul ton appli tourne, et que un des 2 threads prenne 100% du core, alors automatiquement ton 2ème thread tournera sur le core non occupé ;) ).

Ce qu'il faut retenir, c'est que pour tirer parti de la répartition de charge sur plusieurs cores, il te faut programmer en multi-threads.

(Ensuite, il va de soit que ça implique des tas de contrainte et de rigueur dans la programmation comme la mise en place de mutex car les accées mémoires vont se retrouver REELLEMENT parallèle (on ne parle plus de multiplexage des threads, mais bien de la parallèlisation !))

dune2++

Gentoo... que du bonheur ...

_dune2_ · Answer

Salut,

1) En fait, on ne gère pas directement les 2 coeurs d'un dual-core en asm.
Ceci est complétement transparent pour le programmeur, car c'est le scheduler de l'OS qui gère la disponibilité des ressources sur chaque CPU et donc l'affectation de ta tache à un CPU. Sur certains OS, il est possible de paramétrer une "affinité" entre une tache et un core, ce qui permet au scheduler du noyau de faire tourner la tache sur un core précis (tout en partageant les ressources avec les autres taches bien-entendu).
Si ce fonctionnement ne correspond pas à ton attente, et que tu souhaites maîtriser de manière plus fine les affectations des process sur chaque core, il te faut utiliser des couches Temps-réèls sur ces OS (RTX pour windows, RTAI pour linux) qui te permettront de passer en priorité devant l'OS lui-même ... et donc de t'octroyer un core si le coeur t'en dit (Ôh il est beau ce jeu de mot ;) ), avec les conséquence et sanctions qui s'en suivent ;)

2) Il ne faut pas mélanger les termes ;) En programmation, on distingue plusieurs zones mémoires (data, code, heap ...) qui sont remappées sur des espace de mémoire physique. Ensuite cette mémoire physique est gérée par le controleur de mémoire et le processeur pour optimiser son accés en utilisant les possibilités de cache mémoire.
On comprend donc aisément que le fait d'écrire dans la zone "heap", "data" ou "code" ne changera rien à la vitesse d'accés. Ce qui va changer la vitesse d'accés, c'est la gestion du cache et le pré-chargement du cache par le CPU ... et de ce coté là, je peux t'assurer que c'est performant et efficace !! (utilisation du modèle MESI (Modified, Exclusive, Shared, Invalid) pour la cohérence des données dans le cache, gestion approprié du L1, L2 et optionnellement le L3, gestion du prefetch qui permet de charger en avance de temps les données potentiellement utilisées dans un futur proche et ce en temps masqué, et tout cela dans un memory-management engine (sorte de processeur de gestion de la mémoire dans le processeur ;) ) qui travaille en parallèle avec le CPU).
Bref, tout cela pour dire que c'est pas vraiment toi qui va décider si tes données vont se situer dans la RAM physique ou dans le cache L2 (plus rapide) ou dans le cache L1 (encore plus rapide) , sauf si pour une raison d'optimisation en streaming, tu utilises les instructions SSE3 tels que "prefetchntoa" etc ... Mais surtout pour te dire que le "memory-management engine" qui va le faire à ta place, connait bien mieux que toi l'architecture du système, ses défauts et ses atouts, et que dans 99% des cas, il gèrera ta mémoire de manière optimale en terme de performance.

dune2++

Gentoo... que du bonheur ...

epineurien · Answer

OK, merci !

Pour ce qui des coeurs multiples , c'était plutot pour savoir si il  y a un moyen de parrallèliser le programme ; un exemple bidon : l'affichage graphique géré par un coeur et le reste par l'autre ...

epineurien · Answer

D'accord , donc je doit faire tourner deux process différents ?
Comment on fait pour faire communiquer deux process entre eux ?

_dune2_ · Answer

Pas forcément 2 process ... 1 seul process avec plusieurs threads ;)

Gentoo... que du bonheur ...

cs_foxz · Answer

euh de l'hyperthreading sur un multi core ca donne quoi ??? :-)))

pour information : evite d'utiliser la pile, sous windows elle a une taille definie assez petite
de plus je pense que tu as un probleme de conception de comment utiliser la pile....

perso je ne passe pratiquement que des pointeurs dans la pile.

Il veux mieux utilisé DS que SS.
je ne pense pas qu'il existe un instruction rep movsd (par ex) pour le segment SS.

FoxZ...

_dune2_ · Answer

L'hyperthreading sur un multi-core, ça donne 4 contextes de process simultanés avec 2 core de calcul uniquement (dans le cas du core-duo hyperthreaded). Perso, je ne suis pas impressionné par l'hyperthreading, qui contrairement à ce qu'intel voudrait faire croire, n'est pas l'équivalent de 2 cpus ... mais juste 2 contextes de registres (ça évite juste des switching de contextes).

Pour la pile, je laisse la parole aux utilisateurs de windows.
Par contre, qu'entends-tu par "problème de conception de comment utiliser la pile" ??
Il n'en a nullement été question jusqu'à maintenant ??

++dune2

Gentoo... que du bonheur ...

Double question : Dual Core et Heap

7 réponses

Votre réponse

Discussions similaires