Version imprimable
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.
http://lookinside.free.fr/img/mandelbrot2.jpg
:fleche: 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)
Citation:
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 ! :ccool:
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 :cry:
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 :mouarf:
Et que dirait Victor de SetDIBitsToDevice ? :roll: 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) ! :cry:
Au moins Delphi n'est pas le dernier, reste IE9, j'espère pour MS qu'il n'est pas codé en C# :mouarf:
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 couleurCitation:
Envoyé 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
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 :)Citation:
Envoyé par tenpigs
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.
Penses-tu Paul, que la piste pour améliorer le parallélisme consistant à mettre en œuvre opencl permettrait de rendre le calcul des Julia'set encore plus performant ?
(En s'appuyant sur les capacités du GPU)
oui sans doute...je ne connais pas bien OpenCL, je sais juste que ça permet de gagner plus de Bitcoin qu'avec la seule CPU ^^Citation:
Envoyé par Pascal Jankowski