Discussion :

[souviron34]

Non... Tu me parle de programmation alors que j'essaie de comprendre le fonctionnement interne d'un multicoeur....

Euh... C'est pas toi qui parlais d'assembleur plus haut ????

L'assembleur est un langage de programmation comme un autre, plus basique, certes, mais néanmoins un langage de programmation...

Tout autre chose que de la programmation est hardware...

Au risque de me répéter au final pour le processeur tout est du code machine le processeur ne distingue pas les threads ni les programmes.

SI.... en tous cas de manière générale...

Je crois que le fond du problème vient de l'ambiguité que tu maintiens depuis le début, et que sous-tend d'ailleurs Mat.M :

salut je crois que tu confonds ring 0 et coeur 1ou 0
Un CPU multitâche possède plusieurs couches ring 0,ring 1....du moins dans l'architecture x86 Intel
l'OS tourne en ring 0 ,les drivers en ring 1 et le code exécutable en ring n...

Ceci prouve que Mat.M et toi parlez ici de processeurs Intel, alors que quand moi je mentionne "threads", "programmes" , ou "paralllélisme", je me fous de l'architecture de la machine...

C'est le PRINCIPE à propos duquel je parlais, et à propos duquel ta question initiale était... ou semblait être, en tous cas, faute de précision , et au vu du forum...


Faut préciser le problème si on veut avoir une réponse claire...

• Un thread n'est PAS équivalent à un programme
• Un ring (dont je ne connais pas la définition exacte) qui ne serait pas un CPU multitâche ou autre, c'est du langage Intel, pas du langage informatique (ou alors ce sont des "token ring", mais qui n'ont rien à voir ici)
• une application sans thread peut être parallèle
• une application avec thread peut ne pas être parallélisable

Pour ce qui est de savoir comment au niveau chipset:hardware on met des blocs de code sur un coeur et non l'autre c.a.d. l'ordonnancement du code il doit certainement exister ( je*suppose*) un contrôleur qui envoit le code soit sur l'un coeur ou l'autre.

C'est pas ce que j'ai dit plus haut ???

Oui il existe beaucoup d'architectures différentes ce qui complique la portabilité et la programmation.

D'où des mécanismes comme MPI (Message Passing Interface) (documentation The Message Passing Interface) et quelques autres, mentionnés dans les discussions citées dans mon premier post, pour justement être portable et ne pas dépendre des architectures

[PyNub]

premièrement : j'avais posté au début sur le forum hardware mon post a été déplacé ici.

deuxièmement :

L'assembleur est un langage de programmation comme un autre, plus basique, certes, mais néanmoins un langage de programmation...

Alors peux tu nous donner une instruction assembleur qui crée des threads ?

SI.... en tous cas de manière générale...

ah oui ? peux tu préciser ?

je me fous de l'architecture de la machine...

C'est pourtant de cela qu'on parle... j'ai bien précisé :

ce que je voudrais comprendre avant tout c'est les mécanismes internes au processeur pour assigner les threads à chaque coeur.

Je crois que ce qui fait que tu réponds à côté depuis le début et que tu vois uniquement le problème du point de vue des language de haut niveau... Le problèmes c'est que ces languages utilisent la couche d'abstraction matérielle proposé par l'OS.

Donc, un programme ne veut rien dire pour un OS en matière d'ordonnancement et de synchronisation, celui-ci ne distingue que des processus. Les OS modernes ne distinguent plus les processus mais les threads noyau en ce qui concerne l'ordonnancement.

De plus les concept de threads, de programmation concurrente existent depuis bien avant ceux d'architecture parallèle et d'hyperthreading.

[souviron34]

premièrement : j'avais posté au début sur le forum hardware mon post a été déplacé ici.

Ok, désolé mais je ne savais pas...

deuxièmement :
..
Alors peux tu nous donner une instruction assembleur qui crée des threads ?
..
ah oui ? peux tu préciser ?
..
Je crois que ce qui fait que tu réponds à côté depuis le début et que tu vois uniquement le problème du point de vue des language de haut niveau... Le problèmes c'est que ces languages utilisent la couche d'abstraction matérielle proposé par l'OS.

Donc, un programme ne veut rien dire pour un OS en matière d'ordonnancement et de synchronisation, celui-ci ne distingue que des processus. Les OS modernes ne distinguent plus les processus mais les threads noyau en ce qui concerne l'ordonnancement.

De plus les concept de threads, de programmation concurrente existent depuis bien avant ceux d'architecture parallèle et d'hyperthreading.

Je pense que simplement tu as trop fait confiance aux sites français (peut-être Wiki ??) sur l'histoire et la réalité.

La page Wiki anglophone donne un tout autre aspect que la page francophone :


http://en.wikipedia.org/wiki/Parallel_computing

There are several different forms of parallel computing: bit-level, instruction level, data, and task parallelism. Parallelism has been employed for many years, mainly in high-performance computing, but interest in it has grown lately

(en français c'est formulé :

Les architectures parallèles sont devenues le paradigme dominant pour tous les ordinateurs depuis les années 2000.

ce qui ne recouvre pas les mêmes notions
)

De même :

en anglais :

Parallel computing, on the other hand, uses multiple processing elements simultaneously to solve a problem. This is accomplished by breaking the problem into independent parts so that each processing element can execute its part of the algorithm simultaneously with the others. The processing elements can be diverse and include resources such as a single computer with multiple processors, several networked computers, specialized hardware, or any combination of the above.

en français :

Un programme parallèle est divisé en plusieurs tâches séquentielles s'exécutant simultanément, habituellement appelées processus et peuvent être de plusieurs types selon le système d'exploitation ou la machine virtuelle.

Un tel parallélisme de tâche correspond à une architecture MIMD. En Anglais, on parle de TLP (Thread Level Parallelism).

Certains processus sont dits légers, les anglophones utilisant plutôt le mot Thread, qui peut se traduire par fil d'exécution. Les threads plus légers encore utilisés par certaines architectures sont appelés fibers en anglais, c'est-à-dire fibres en français.

Ce qui n'est PAS DU TOUT la même chose...



D'autre part, en anglais figure un chapitre qui ne figure pas du tout en français :

Types of parallelism

• Bit-level parallelism
  
• Instruction-level parallelism
  
• Data parallelism
  
• Task parallelism

Reflétés dans un chapitre ne figurant égalment pas en français :

Classes of parallel computers

• Multicore computing
  
• Symmetric multiprocessing
  
• Distributed computing
  
  
  • Cluster computing
    
  • Massive parallel processing
    
  • Grid computing
  
  
• Specialized parallel computers
  
  
  • Reconfigurable computing with field-programmable gate
    
  • General-purpose computing on graphics processing units (GPGPU)
    
  • Application-specific integrated circuits
    
  • Vector processors

qui circonscrit bien ce dont on parle, ce qui n'est pas le cas en français.

Enfin, ce qui n'est pas sans intérêt quand tu dis :

De plus les concept de threads, de programmation concurrente existent depuis bien avant ceux d'architecture parallèle et d'hyperthreading

On peut trouver :

In 1969, US company Honeywell introduced its first Multics system, a symmetric multiprocessor system capable of running up to eight processors in parallel.[47] C.mmp, a 1970s multi-processor project at Carnegie Mellon University, was "among the first multiprocessors with more than a few processors".[44] "The first bus-connected multi-processor with snooping caches was the Synapse N+1 in 1984."[44]

SIMD parallel computers can be traced back to the 1970s. The motivation behind early SIMD computers was to amortize the gate delay of the processor's control unit over multiple instructions.[49] In 1964, Slotnick had proposed building a massively parallel computer for the Lawrence Livermore National Laboratory.[47] His design was funded by the US Air Force, which was the earliest SIMD parallel-computing effort, ILLIAC IV.[47] The key to its design was a fairly high parallelism, with up to 256 processors, which allowed the machine to work on large datasets in what would later be known as vector processing.

mais aussi, concernant les langages de programmation :

Parallel programming languages

Concurrent programming languages, libraries, APIs, and parallel programming models (such as Algorithmic Skeletons) have been created for programming parallel computers. These can generally be divided into classes based on the assumptions they make about the underlying memory architecture—shared memory, distributed memory, or shared distributed memory. Shared memory programming languages communicate by manipulating shared memory variables. Distributed memory uses message passing. POSIX Threads and OpenMP are two of most widely used shared memory APIs, whereas Message Passing Interface (MPI) is the most widely used message-passing system API.[39] One concept used in programming parallel programs is the future concept, where one part of a program promises to deliver a required datum to another part of a program at some future time.

CAPS entreprise and Pathscale are also coordinating their effort to make HMPP (Hybrid Multicore Parallel Programming) directives an Open Standard denoted OpenHMPP. The OpenHMPP directive-based programming model offers a syntax to efficiently offload computations on hardware accelerators and to optimize data movement to/from the hardware memory. OpenHMPP directives describe remote procedure call (RPC) on an accelerator device (e.g. GPU) or more generally a set of cores. The directives annotate C or Fortran codes to describe two sets of functionalities: the offloading of procedures (denoted codelets) onto a remote device and the optimization of data transfers between the CPU main memory and the accelerator memory.

Et maintenant, finlement, en ce qui concerne les threads en particuliers :

http://en.wikipedia.org/wiki/Thread_...Multithreading

Threads differ from traditional multitasking operating system processes in that:

• processes are typically independent, while threads exist as subsets of a process
• processes carry considerably more state information than threads, whereas multiple threads within a process share process state as well as memory and other resources
• processes have separate address spaces, whereas threads share their address space
• processes interact only through system-provided inter-process communication mechanisms
• Context switching between threads in the same process is typically faster than context switching between processes.

Systems like Windows NT and OS/2 are said to have "cheap" threads and "expensive" processes; in other operating systems there is not so great a difference except the cost of address space switch which implies a TLB flush.

Je réitère donc que threads et programmes / processes sont des choses différentes, éventuellement vus différemment par les processeurs, en général..

Maintenant je me retire de la conversation, ne connaissant pas les particularités des appels sur Intel.. Mat.M me semble une bonne référence sur ce sujet..


PS: pour info, dans la communauté hors Windows, le terme "thread" était inconnu avant 2005, bien que l'on fasse du parallèlisme depuis belle lurette, et dans la communauté Windows il était inconnu avant 2001...

[PyNub]

Je pense que simplement tu as trop fait confiance aux sites français (peut-être Wiki ??) sur l'histoire et la réalité.

Non j'ai des livres de référence en matière d'OS... Par contre du point de vue des architectures (et non pas programmtion) parallèles ma seule source (comme je l'ai dit...) et la documentation d'Intel (en anglais...).

Je réitère donc que threads et programmes / processes sont des choses différentes, éventuellement vus différemment par les processeurs, en général..

Je n'ai jamais dit le contraire, juste que pour le processeur il n'y a pas de threads. Le processeur lit et décode l'instruction incrémente le compteur ordinal et passe à l'instruction suivante pointée par le nouveau contenu du CO. Il existe des instructions pour changer le contenu du compteur ordinal : les branchements (Jmp,jne etc...), les appels de procédures (Call, Ret...), les interruptions (par instruction avec INT directement par le matériel). Un threads, un processus ce n'est jamais que cela à ma connaissances.

La série de citations dont tu me fais part ne concerne que les OS (MULTICS est un OS) évidemment lié au matériel puisque l'OS fournit une couche d'abstraction au dessus du matériel et en dessous des programmes utilisateurs. Il n'est jamais dans tout ce que tu as collé dans ton post que les threads sont gérés par le matériel comme tu l'as affirmé...

peuvent être de plusieurs types selon le système d'exploitation ou la machine virtuelle.

Je crois que c'est clair...

Mat.M me semble une bonne référence sur ce sujet..

Même si il a été moins "aggressif" et a fini par comprendre que je parlais d'architecture et non de programmation il a lui aussi un point de vue de développeur, et il ne m'a pas apporté de réponse. Le seul que je peux remercier c'est mewtow. Je t'invite à relire ses contributions.

pour info, dans la communauté hors Windows, le terme "thread" était inconnu avant 2005, bien que l'on fasse du parallèlisme depuis belle lurette, et dans la communauté Windows il était inconnu avant 2001...

On est en 2012 et à ce propos bonne année à toi et tout le monde sur ce forum.

[Mat.M]

Je crois que c'est un contrôleur d'interruptions...

salut et bonne année 2012
Je ne suis pas certain mais le contrôleur d'interruptions Programmable Interruption Controller il sert à gérer les interruptions vers le hardware comme la mémoire, la carte vidéo,la carte son donc je doute qu'il gère la programmation en parallèle.
A vérifier

Même si il a été moins "aggressif" et a fini par comprendre que je parlais d'architecture et non de programmation il a lui aussi un point de vue de développeur, et il ne m'a pas apporté de réponse.

oui mais tu ne connaissais pas les biblios d'INTEL
Ceci dit c'est un peu exact j'ai apporté une réponse d'un point de vue programmeur.
A ce niveau là la frontière entre le hardware et le code machine est ténue.
Et puis je pense que c'est très difficile de répondre à tes questions je n'ai pas évidemment la prétention d'apporter une réponse très précise.
Il faut que tu épluches le site et les docs d'Intel.
Certainement qu'il y a des infos classées confidentielles chez Intel qui ne sont pas divulguées à tout le monde, secret tech oblige.
Donc on ne peut pas répondre à ta question certainement

[Mat.M]

C'est pas ce que j'ai dit plus haut ???

salut J. tant pis pour le QC
Oui tu as raison bonne année 2012

Maintenant je me retire de la conversation, ne connaissant pas les particularités des appels sur Intel.. Mat.M me semble une bonne référence sur ce sujet..

.

merci mais je ne prétends pas connaître grand chose dans ce domaine
j'ai des notions de base de l'assembleur
Mais je suis loin de posséder la science infuse à ce sujet

[PyNub]

Non il ne gère pas la programmation parallèle...

Mais que fait une interruption ? Elle déclenche une sauvegarde du contexte puis fait pointer le compteur ordinal vers la première instruction de la procédure d'interruption.

Aussi imaginer un système à base d'interruption déclenchant des saut du compteur ordinal c'est ce qui se fait déjà avec une interruption classique pourquoi ne pas imaginer cela avec une mise à jour d'un registre (ou d'un mot mémoire centrale) avec un pointeur vers une instruction et le déclenchement d'une interruption déclenchant le chargement du compteur ordinal avec ce pointeur.

C'est ce que semble dire mewtow

Bonne année 2012 à toi

[PyNub]

oui mais tu ne connaissais pas les biblios d'INTEL

Bien sûr que oui je l'ai dit dès le début

Certainement qu'il y a des infos classées confidentielles chez Intel qui ne sont pas divulguées à tout le monde, secret tech oblige.
Donc on ne peut pas répondre à ta question certainement

Il ya de ça ... il y a aussi le fait que ce qui savent sont rares et n'ont aucun intérêt à partager leur savoir... Cependant Intel a tout intérêt à que l'on utilise leur processeurs... Il ne peuvent cacher certaines choses, sinon comment feraient les develloppeurs d'OS multicores...

[PyNub]

J'ai survolé le chapitre de la documentation Intel concernant l'APIC mais c'est assez ardu

Mon premier post...

[Mat.M]

Salut pas trop le temps de me documenter mais si tu en sais plus fais-nous le savoir alors

[PyNub]

Je n'y manquerai pas.

[PyNub]

8.6.3 Executing Multiple Threads on an Intel® 64 or IA-32 Processor Supporting Hardware Multi-Threading

Upon completing the operating system boot-up procedure, the bootstrap processor (BSP) executes operating system code. Other logical processors are placed in the halt state. To execute a code stream (thread) on a halted logical processor, the operating system issues an interprocessor interrupt (IPI) addressed to the halted logical processor. In response to the IPI, the processor wakes up and begins executing the thread identified by the interrupt vector received as part of the IPI.

[souviron34]

the thread identified by the interrupt vector received as part of the IPI

ça n'explique pas comment il détermine cette identification / affectation avant..



Mais c'est intéressant..

[PyNub]

Je ne vais pas te copier les 300 pages de la doc Intel non plus...

[souviron34]

Je ne vais pas te copier les 300 pages de la doc Intel non plus...

Non , mais c'est toi qui posais la question :

Comment un processus est assigné à un coeur particulier ? Est-ce qu'il existe une instruction ? ou sinon quel est le mécanisme qui est utilisé ?

là on a le mécanisme de passage, mais pas celui d'assignation ...

[PyNub]

Le champs vecteur fait 8 bits. Un fonctionnement possible serait de prévoir une procédure qui charge un processus ou un threads depuis la mémoire en positionnant les registres selon le contexte conserver dans la table des processus, puis bascule en mode utilisateur.
Pour la préemption apparement c'est prévu par l'APIC, donc un processeur peut-être interrompu à tout moment par un autre processeur. Il suffit qu'un des processeurs bascule de temps en temps en mode noyau pour exécuter l'ordonnanceur. Cela se fait au moyen d'une interruption de la même façon que sur un monoprocesseur.
Je conjecture encore un peu mais bon...

[PyNub]

là on a le mécanisme de passage, mais pas celui d'assignation ...

L'assignation se fait par l'OS au moyen de l'APIC. L'OS conserve en mémoire des structures de données en mémoire gardant la trace de tous les processus et threads en cours d'exécution ou en attente d'ordonnancement. L'ordonnancement des processus se fait selon divers algorithme selon l'OS. Mais ça c'est du domaine des système d'exploitation.
L'identification du processeur se fait au moment du démarrage :

8.4.1 BSP and AP Processors
The MP initialization protocol defines two classes of processors: the bootstrap
processor (BSP) and the application processors (APs). Following a power-up or RESET of an MP system, system hardware dynamically selects one of the processors on the system bus as the BSP. The remaining processors are designated as APs.
As part of the BSP selection mechanism, the BSP flag is set in the IA32_APIC_BASE MSR (see Figure 10-5) of the BSP, indicating that it is the BSP. This flag is cleared for all other processors.
The BSP executes the BIOS’s boot-strap code to configure the APIC environment, sets up system-wide data structures, and starts and initializes the APs. When the BSP and APs are initialized, the BSP then begins executing the operating-system initialization code.
Following a power-up or reset, the APs complete a minimal self-configuration, then wait for a startup signal (a SIPI message) from the BSP processor. Upon receiving a SIPI message, an AP executes the BIOS AP configuration code, which ends with the AP being placed in halt state.
For Intel 64 and IA-32 processors supporting Intel Hyper-Threading Technology, the MP initialization protocol treats each of the logical processors on the system bus or coherent link domain as a separate processor (with a unique APIC ID). During bootup, one of the logical processors is selected as the BSP and the remainder of the logical processors are designated as APs.

[PyNub]

là on a le mécanisme de passage, mais pas celui d'assignation ...

Ceci-dit je t'accorde que le termes assignation était plutôt mal venu, passage est en effet plus adapté. En fait les processeurs sont "réveillés" ou interrompus.

[Invité]

là on a le mécanisme de passage, mais pas celui d'assignation ...

Si par mécanisme d'assignation tu veux dire : comment préciser (attention, j'ai dit préciser et pas choisir) le processeur qui va recevoir l'interruption, c'est expliqué dans la section 10.6.1 du system programming developper's guide d'Intel.

En gros, cela se fait avec l'aide d'un registre de 64 bits nommé l'Interrupt Command Register. Pour simplifier, chaque processeur se voit attribuer un Id au démarrage qui permet de l'identifier (en fait, il s'agit de l'APIC de chaque processeur / core physique / core logique HT). Certains bits de ce registre permettent de préciser quel est le type de transfert : doit-on envoyer l'interruption au processeur émetteur, à tous les autres processeurs, à un processeur particulier. Dans le dernier cas, certains bits du registre permettent de préciser l'id du processeur qui va devoir recevoir l'interruption. A charge de l'APIC de faire ce qu'il faut en fonction du contenu de ce registre. Bon, en fait c'est plus compliqué et deux autres registres entrent en jeu, afin de faire la différence entre les cores/processeurs physiques et les cores logiques : cela permet de ne pas exécuter un thread/programme sur le même core physique alors qu'on a des cores physiques inutilisés. Mais l'idée est là.

Bref, il suffit de savoir quoi mettre dans ces registres pour sélectionner un processeur. Reste à savoir quel processeur choisir, et là, c'est à l'OS de faire le travail, comme dit plus haut.

[souviron34]

@PyNub:

Oui.

Mais ta question (plusieurs fois mentionnée) m'avait semblait être l'assignation..

Quelle est l'instruction (ou le mécanisme) du point de vue de l'assembleur qui permet de répartir les trois sections sur chaque processeur ?

Comme l'avait mentionné Mat.M, effectivement cela doit avoir à faire avec "l'affinité" sous Intel, prise en compte par l'algo de l'ordonanceur, un peu comme ce que j'avais mentionné plus haut :

je soupçonne que l'algo est relativement simple : pour N coeurs, si coeur no i non utilisé, alors on l'utilise, sinon, si tous les coeurs sont utilisés, on prend le moins chargé, et on fait agir un scheduler dessus.

et qui semble confirmé par :

For Intel 64 and IA-32 processors supporting Intel Hyper-Threading Technology, the MP initialization protocol treats each of the logical processors on the system bus or coherent link domain as a separate processor (with a unique APIC ID).