Discussion :

[schousso]

Bonjour,

Je viens de developpez une application en delphi 5. Je viens de m'appercevoir que sur un coeur I5, l'application n'utilisait que 25% du processeur (soit 1 seul sur les 4 processeur).

Est-il possible avec delphi d'utiliser toutes les capacités du processeur ?
Si oui, quelle version de delphi peut le faire ?
Si non connaissez vous un autre langage proche du pascal permettant de faire d'utiliser les capacités de tous le processeur?

Merci d'avance.

[Linkin]

Le seul moyen est de programmer en multi-thread, il faut savoir si ton traitement est parallélisable afin de "profiter" de tous les coeurs de ton processeur.

[schousso]

Donc il est possible avec delphi 5 de paralléliser mon traitement.
Est-ce qu'il y a un petit exemple afin que je vois si il possible de paralléliser mon application ?

J'ai vu que ceratins compilateur peuvent gérer automaquement la gestion du multi-coeur. J'imagines que ce n'est pas le cas de delphi?

[Paul TOTH]

Donc il est possible avec delphi 5 de paralléliser mon traitement.
Est-ce qu'il y a un petit exemple afin que je vois si il possible de paralléliser mon application ?

J'ai vu que ceratins compilateur peuvent gérer automaquement la gestion du multi-coeur. J'imagines que ce n'est pas le cas de delphi?

avec GetProcessAffinityMask tu détermines le nombre de coeurs, puis tu crées un Thread par coeur

[Mac LAK]

Donc il est possible avec delphi 5 de paralléliser mon traitement.

Delphi permet de créer des applications multithread, mais ça ne veut pas dire que ton traitement est parallélisable...

Est-ce qu'il y a un petit exemple afin que je vois si il possible de paralléliser mon application ?

Si tu n'es pas familier avec la notion de programmation parallèle, il vaudrait en fait mieux que tu nous décrives l'algo qu'exécute ton programme, il sera alors plus simple de te répondre "oui" ou "non".

J'ai vu que ceratins compilateur peuvent gérer automaquement la gestion du multi-coeur. J'imagines que ce n'est pas le cas de delphi?

Par défaut, Delphi utilise tous les coeurs disponibles, et tes threads seront donc répartis directement par Windows sur les coeurs libres.

[schousso]

Et en admettant que mon application ne pas "parallelisable", quelle solution ai-je? un autre language?

[Linkin]

Pas d'autre solution:

Utiliser plusieurs coeurs d'un processeur veut dire que l'on a plusieurs threads qui tournent en même temps. Donc que le traitement a été parallélisé (au moins partiellement).

[Mac LAK]

Et en admettant que mon application ne pas "parallelisable", quelle solution ai-je? un autre language?

Linkin a parfaitement résumé : c'est l'algorithme qui doit être parallélisable, l'implémentation (=le programme écrit dans un langage donné) peut ensuite l'être quel que soit le langage utilisé, du moment que le couple OS/langage supporte le concept de thread.
Et c'est le cas de tous les langages couramment utilisés actuellement...

[Paul TOTH]

Linkin a parfaitement résumé : c'est l'algorithme qui doit être parallélisable, l'implémentation (=le programme écrit dans un langage donné) peut ensuite l'être quel que soit le langage utilisé, du moment que le couple OS/langage supporte le concept de thread.
Et c'est le cas de tous les langages couramment utilisés actuellement...

il faudrait peut-être l'inventer, ce langage multithread, comme on a inventé le langage Objet ... il existe aussi des langages vectoriels

[Mac LAK]

il faudrait peut-être l'inventer, ce langage multithread, comme on a inventé le langage Objet ... il existe aussi des langages vectoriels

J'ai bien parlé de "couple OS/langage", Paul.

Support natif ? T'as déjà l'ADA, le Java, et sûrement pas mal d'autres qui supportent nativement la notion de tâche / thread. Support par API ? Threads POSIX, threads Win32, OpenMP, pour les plus connus.

Ensuite, du moment que ton langage supporte les appels système et que le système, lui, supporte les threads, alors ton langage supporte le multithreading... Et ça ne changera pas le fait que passer d'un langage compatible MT à un autre langage compatible MT ne permettra pas de paralléliser un algo de façon "magique" !!

[Paul TOTH]

J'ai bien parlé de "couple OS/langage", Paul.

Support natif ? T'as déjà l'ADA, le Java, et sûrement pas mal d'autres qui supportent nativement la notion de tâche / thread. Support par API ? Threads POSIX, threads Win32, OpenMP, pour les plus connus.

Ensuite, du moment que ton langage supporte les appels système et que le système, lui, supporte les threads, alors ton langage supporte le multithreading... Et ça ne changera pas le fait que passer d'un langage compatible MT à un autre langage compatible MT ne permettra pas de paralléliser un algo de façon "magique" !!

il me semble pourtant que lors des dernières TechDays de MS, C# 4 permet de paralléliser les séquences ForEach de façon très simple.

et c'est bien là l'idée...image le code suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
var
  cIndex : Integer;
begin
  for cIndex := 0 to List.Count - 1 do
   List[cIndex].CalculeSalaire;
  EffectuerVirements;
end;
 
// version MT
begin
// lancement d'une tache multithread
  ForEach List do CalculeSalaire;
// ici on est certain que tous les calculs sont terminés
// que ce soit dans une simple boucle ou sur plusieurs coeurs, on s'en fout !
  EffectuerVirements;
end;

[Mac LAK]

il me semble pourtant que lors des dernières TechDays de MS, C# 4 permet de paralléliser les séquences ForEach de façon très simple.

Oui, c'est bien sûr possible de faire quelque chose dans ce genre de façon plus ou moins automatique, c'est d'ailleurs ce qu'il se passe en OpenMP avec les barrières. D'autres API MT supportent également le concept de barrière de façon native, au pire ce n'est pas horrible à réimplémenter à partir de sémaphores/mutex/events.

Mais aucun langage ne fera ça automatiquement sans la garantie absolue que la fonction threadée est réentrante et indépendante, tout comme le stockage des résultats d'ailleurs. Typiquement, il est impossible de paralléliser un calcul de suite par exemple, vu que chaque itération est dépendante du résultat précédent ! L'exécution séquentielle (monothread) est impérative.

Certes, on peut définir des primitives / modificateurs / identificateurs permettant de dire au compilateur "Je sais que cette fonction est compatible MT, tu peux l'optimiser au besoin", mais il ne peut pas le déterminer par lui-même en dehors des cas bêtement évidents (fonction sans effet de bord notamment), et c'est hélas loin d'être le cas le plus courant...

[Paul TOTH]

Oui, c'est bien sûr possible de faire quelque chose dans ce genre de façon plus ou moins automatique, c'est d'ailleurs ce qu'il se passe en OpenMP avec les barrières. D'autres API MT supportent également le concept de barrière de façon native, au pire ce n'est pas horrible à réimplémenter à partir de sémaphores/mutex/events.

Mais aucun langage ne fera ça automatiquement sans la garantie absolue que la fonction threadée est réentrante et indépendante, tout comme le stockage des résultats d'ailleurs. Typiquement, il est impossible de paralléliser un calcul de suite par exemple, vu que chaque itération est dépendante du résultat précédent ! L'exécution séquentielle (monothread) est impérative.

Certes, on peut définir des primitives / modificateurs / identificateurs permettant de dire au compilateur "Je sais que cette fonction est compatible MT, tu peux l'optimiser au besoin", mais il ne peut pas le déterminer par lui-même en dehors des cas bêtement évidents (fonction sans effet de bord notamment), et c'est hélas loin d'être le cas le plus courant...

je ne suis pas d'accord avec toi

c'est comme si, ne connaissant pas les variables locales, tu disais qu'il est impossible de garantir qu'une fonction ne vas pas taper dans la variable d'une autre.

c'est comme si, ne connaissant pas la portées des membres d'un objet, tu disais qu'il n'est pas possible à un objet ancêtre de protéger ses membres de ses descendants.

il y a donc de nouveaux concepts à inventer (à moins qu'ils n'existent déjà...je n'en sais rien) qui garantissent qu'un code donné soit multithreadable...ou pas. De la même façon qu'on sait sans erreur si un membre est privé ou pas, une variable globale ou pas

dans le même ordre d'idée, avec le polymorphisme, tu ne sais jamais avec certitude ce que fait la méthode d'un objet...et pourtant ça fonctionne Avec un garbage collector, tu ne sais jamais quand un objet est réellement détruit...et bien là tu ne serais jamais réellement quand la procédure est invoquée

[Mac LAK]

C'est en fait exactement la même chose que des modificateurs comme "const" : c'est le développeur qui indique au compilateur qu'un objet ne doit/peut pas être modifié.

De même pour le MT : si on laisse le compilateur agir seul pour déterminer si une fonction est thread-safe ou pas, il va falloir :

• Mettre un tag "thread-safe" (TS) (oui ou non) sur TOUTES les fonctions runtime, ainsi que sur les fonctions de l'API Win32 importées.
• Par défaut, une fonction non renseignée est donc impérativement non-TS.
• Une fonction utilisateur est TS si et seulement si elle respecte les points suivants :
  • La fonction n'utilise aucune fonction non-TS.
  • Aucun paramètre n'est passé par adresse/référence.
  • Aucun paramètre n'est un pointeur.
  • La fonction n'utilise aucune variable globale, inclus la récupération d'un handle quelconque via le biais de l'OS.
  • La fonction n'utilise que ses paramètres et ses variables locales.
  • Le résultat de la fonction n'est pas stocké à un emplacement qui serait celui d'un paramètre d'une fonction TS, inclus la fonction elle-même.
• Une telle fonction déterminée comme TS est alors parallélisable librement par le compilateur.
• Dans tous les autres cas, sauf mention explicite d'un état TS par le développeur, le compilateur ne devrait JAMAIS threader automatiquement une fonction qui n'est pas garantie TS.

Et tout ça se résume en "réentrante et indépendante", ce que j'ai dit au post précédent... Et encore : je n'ai pas parlé de l'overhead de création des threads, qui risque probablement de rendre l'algo parallèle "automatique" plus lent que la version séquentielle mono-thread !!

Paralléliser un algo n'est pas automatique, quoi qu'il en soit : cela demande parfois à carrément partir à contre-sens de l'algo "naturel" (séquentiel), et ça, un compilateur ne peut pas l'inventer tout seul. Au mieux, il peut rendre "transparent" la création/gestion du thread, mais guère plus. Le développeur devra malgré tout indiquer si c'est judicieux ou pas.

Exemple typique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Function DoAnOperation ( Const Parameter : Real ) : Real ;
Begin
     Result:=Sqrt(Parameter);
End ;

Va threader ça, et tu vas perdre des performances par brouettes entières... Ce genre d'algo n'est parallélisable que via des processeurs SIMD, donc du SSE sur une archi Intel. Passer par des threads est la pire des solutions, il faut penser différemment pour réussir à paralléliser efficacement un algo qui effectuerait cette opération sur un tableau.


L'erreur que tu fais est de comparer la parallélisation d'appels de fonction avec des procédés "automatiques" qui ne sont pas comparables : typiquement, le GC, par exemple. Oui, on ne sait pas "quand" c'est libéré, et alors ? De toutes façons, on ne se sert plus de la donnée (=> destruction asynchrone), et en plus, la donnée est forcément "libre" (=> compteur de référence, donc destruction autonome)... Où est le problème d'automatiser ça, tant que les fonctions d'allocation / libération / copie sont "câblées" sur le GC ?

Paradoxalement, l'exécution parallèle d'un algo EXIGE la plupart du temps une forme de synchronisation, et ça, c'est presque impossible à automatiser de façon optimale.

[Paul TOTH]

en fait je pense qu'on ne parle pas de la même chose

tu insistes sur le fait que le parallélisme n'est pas chose simple, et je suis d'accord.

mais je pense qu'il doit être possible d'inventer un nouveau langage proposant de nouveaux concepts qui permettent de tirer pleinement parti de la programmation parallèle.

c'est pour cela que je fais le parallèle () avec la POO. Un programmeur "procédural" qui se lance dans la programmation objet et événementielle est un peu largué au début...car il ne maîtrise pas bien les concepts et se demande à la fois pourquoi l'enchaînement des traitements n'est pas linéaire (événementiel) et pourquoi il ne peux pas lancer deux traitement en même temps (barre de progression)

Ensuite je ne dis pas que tout est parallélisable, ou que cela à toujours un intérêt...d'ailleurs Delphi, contrairement à Java, permet de faire aussi bien du procédural que de l'objet...il ne lui manque plus que le MT

Evidemment, on n'a pas "besoin" d'un nouveau langage pour faire de la programmation multithreadée...mais des mots clés comme threadvar simplifient les choses tout de même

[Mac LAK]

Ce que tu demandes, c'est en gros la même chose que ce qui est fait avec OpenMP, donc... Mais cela reste de "simples" directives de création d'objets liés au MT (threads, synchros, etc.), pas plus, pas moins. Le moteur du système reste encore et toujours le jus de cerveau...

[Franck SORIANO]

mais je pense qu'il doit être possible d'inventer un nouveau langage proposant de nouveaux concepts qui permettent de tirer pleinement parti de la programmation parallèle.

Ca existe déjà.
Tu as [ame="http://fr.wikipedia.org/wiki/LACATRE"]LACATRE[/ame] par exemple.

Evidemment, ce sont des langages spécialisés qui ne permettent pas nécessairement de tout faire.
Enfin dans le cas de LACATRE, tu génères un code C qui traite toute la partie "Multi-tâche" et tu ajoute le code fonctionnel au milieu.