Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Multithreading et multicoeur
Bonjour,
Suite à un article de Eric Grange (bien connu pour GLScene) sur les performances de Delphi face à Javascript, j'ai rédigé un article montrant une application pratique du multithreading dans le calcul d'un ensemble de Mandelbrot.
Multithreading : à quoi ça sert d'avoir plusieurs coeurs ?
L'article propose notamment le source d'une classe TParalellizer qui facilite la mise en oeuvre du multithreading.
Ah vraiment très bien, et intéressant.
Merci.
Alors, juste une précision (que j'ai ajouté en fin d'article)
Suite à la publication de ce billet, j'ai contacté Eric (je trouve ça normal vu que je parle de sa page), et en fait il me dit que Javascript n'est pas multithreadé ... et à la vu de l'activité de ma CPU je pense qu'il a en effet raison...ceci dit la démo reste intéressante.
Enfin !
Un article pour exploiter intelligemment les architectures multicoeurs.
Merci !
Un truc un peu décevant quand même, c'est que les performances ne sont pas directement proportionnelles au nombre de Threads:
- on gagne beaucoup en passant de 1 à 2 Threads
- en revanche, passer de 3 à 4 Threads n'apporte pas grand'chose.
Peut-être un goulet d'étranglement dû à la carte graphique ? [c'est une question.]
Joli article !
J'ignorais que le JS était pré-compilé !
Ils sont fort les développeurs de script quand même pour optimiser à ce point un code (et cela sans multi-thread)
Delphi
Si j'ai le courage, faudrait que je convertisse le code en C++Builder XE3 ! Par Curiosité
Sympa, ton exemple et la démarche aboutissant au TParalellizer
Ce qui est intéressant aussi c'est l'échange sur DelphiTools !
Mon anglais n'est pas terrible mais bcp certains se sont focalisés sur le Bitmap et merci de l'avoir remarqué pour nous, le fait que cela concerne purement le calcul
J'ai souri lorsqu'un dénommé Victor a fait remarquer qu'en Delphi, ScanLine(), un ‘special trick’, serait moins "connu" que l'équivalent getImageData() du JavaScript alors que j'ai l'impression que ScanLine() revient souvent sur le forum
Et que dirait Victor de SetDIBitsToDevice ?surtout que ce n'est plus de la VCL mais directement une API !
Entre la version JS et la version Delphi de Eric Grange, c'est 2x à 3x plus lent sur mon i5-3750 (3.40HGz) !
Au moins Delphi n'est pas le dernier, reste IE9, j'espère pour MS qu'il n'est pas codé en C#
EDIT :
Si tu évoques le code de Paul Toth et son TParalellizer, l'unité Mandelbrot utilise un gros tableau de cardinal en mémoire, juste de la manipulation de "nombre" qui transforme une coordonnée en une couleurEnvoyé par Caribensila
Paul Toth a justement isolé le plus que possible sont calculs d'éléments parasites comme le dessin !
le temps mesuré n'inclu pas l'affichage via SetDIBitsToDevice + TImage
Mais c'est vrai que le gain entre 3 et 4 est assez mininime, peut-être lié à la répartition des taches propres à windows et au fonctionnement de Interlock... dont l'utilisation est très intéressante et change de celle du TInterfacedObject
Pour Info sur i5-3750 (3.40HGz)
1 - 150 à 167 ms
2 - . 84 à . 97 ms
3 - . 59 à . 70 ms
4 - . 39 à . 63 ms
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Eric a fait d'autres tests de performance ici.
Pour l'étranglement, je pense pas qu'on puisse faire mieux...sauf peut-être à répartir d'office les tâches, avec autant de pixels pour chaque tâche en évitant du coup l'interlock....
Mise à jour de l'article avec des tests comparatifs Delphi 6, XE2 32 et 64 bits,
en fait ça dépote sous XE2 64bits
N'y aurait il pas une erreur dans les mesures à la fin?
Delphi 6 32 bits, 1 thread 190ms
Delphi XE2 32 bits, 1 thread 190ms
alors qu'en début d'article il y a ces mesures :
1 seul thread : 450ms
2 threads: 250 ms
3 threads: 190 ms
4 threads: 180 ms
non, ce n'est pas la même image
en début d'article j'utilise un zoom sur une partie plus complexe afin d'avoir des temps plus parlants, sur la fin c'est l'image de base qui prend moins de temps à calculer.
Répondre avec citation
Partager