Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi MultiThreading Bei mir ca. 40x Langsamer bei IntegerBerechnu (https://www.delphipraxis.net/75381-multithreading-bei-mir-ca-40x-langsamer-bei-integerberechnu.html)

Hallo_Thomas 18. Aug 2006 22:44

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Hallo,

vorab ich Schliesse zu 100%, dass Synchronize in diesem Beispiel an der Verlangsamung Schuld ist, da es bei Beiden Zeitmessungen eingesetzt wird, MUSS die Verzögerung durch diesen Befehl bei beiden Zeitmessungen gleich sein!


Die Problematik der Single,Dual Prozessoren & HTT möchte ich hier Bitte nicht besprechen!!!!!!!!!!!!!!!!!!

Denn diese MultiThreading Anwendung ist bei Single & Mehr Cpu's langsamer!!!


Mir geht es darum, wie kann ich diese Rechenintensive Integer Anwendung beschleunigen, dass ich auf einer SingleCore CPU langsamer bin, ist klar.

Mir geht es darum, wenn ich Varibalen mehrmals übergeben muss,zwischen den Threads,wie kann ich das effizent tun, wenn der Thread immer wieder angesteuert wird!


Meiner Meinung nach gute Ansetze:

Zitat:

Overhead von Threads, bei der Mini-Berechnung fällt der ganze Threadkram
Zitat:

Zudem solltest du nur einen Thread pro CPU verwenden
Ich weis! Aber hierzu möchte ich nix sagen, das Thema ist zu Interessant & sobald ich ich die Thread Performance hier gesteigert habe werde ich hierzu wohl ein neues Thema aufmachen!

Zitat:

Habe das Beispiel mal auf meiner AMD X2 laufen lassen. Der Multithreading Test ist bei mir 80x langsamer.
Nun weis der letzte auch, wieso ich hier KEINE Diskusium über Single oder Dual Cpu hier möchte!


Zitat:

Ich würde einen oder mehrere Threads für die Berechnung erstellen und diese so lange laufen lassen, bis sie beendet sind, so hast du den Rechenaufwand für die Erstellung der Threads nur einmal.
Guter Ansatz, wie übergebe ich an den Thread die Mehrmals die Daten & wie bekomme ich sie mehrmals zurück?

Luckie 19. Aug 2006 00:01

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Zitat:

Zitat von Hallo_Thomas
Denn diese MultiThreading Anwendung ist bei Single & Mehr Cpu's langsamer!!!

Logisch. So lange du deinen Threads nicht explizit eine CPU zuweist, wenn du ein mehrprozessorsystem hast, laufen beide Threads auf der gleichen CPU. Windows kann nicht hellsehen und wissen, was du vor hast.

alzaimar 19. Aug 2006 06:49

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Solange Du zwischendurch kein langsames I/O machst, bringt doch mehr als ein Thread pro CPU rein gar nichts.

Ermittle also die Anzahl der CPUs, Teile deine Aufgabe in gleich große Häppchen, sodaß eben pro CPU ein Happen übrig bleibt, verteile die Aufgaben und lehne dich zurück.

Bist Du Dir sicher, das die Berechnung hinreichend optimiert wurde? Meistens liegt das Performanceproblem nicht in der Menge der Daten, sondern im Design des Algorithmus.

Hallo_Thomas 19. Aug 2006 09:14

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
@ alzaimar

Gibt es dafür ein Beispiel,mit der Übergabe der Variablen?

jbg 19. Aug 2006 12:12

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Zitat:

Feld1[x]:=Feld1[x]+1*2 div 2;
Was wird denn das? Da Punkt vor Strich gilt steht da effektiv: Feld1[x]:=Feld1[x]+1

Und weil du das 14 mal (0..13) durchläufst, kannst du gleich statt der +1 eine +14 hinschreiben und dir die äußere Schleife ersparen. Das SumInt() kannst dabei auch gleich in deine Schleife integrieren.

Synchronize: Synchronize stoppt den Thread und wartet auf den Hauptthread, bis der in der Messageloop "vorbeischaut". Das kann je nach umständen recht lange dauern. Dann doch lieber mit PostMessage() an das Formular eine eigene Botschaft schicken. So wird der Thread nicht ausgebremst.

Hallo_Thomas 19. Aug 2006 13:34

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
@JbP

Es geht hier nicht um den Sinn Der Formel, Sie soll nur als Beispiel dienen und Rechenleistung kosten!

Zum Zweiten mal!!!!!!

Es kann nicht an Synchronize liegen, nehmt es raus aus dem Programm und ihr werdet es merken!!!!!!!!!!!!!!!!!

xaromz 19. Aug 2006 13:49

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Hallo,
Zitat:

Zitat von Hallo_Thomas
Es geht hier nicht um den Sinn Der Forme1, Sie soll nur als Beispiel dienen und Rechenleistung kosten!

Was ist eigentlich der Zweck dieser Übung? Festzustellen, dass Threads das System durch Overhead belasten? Ich habe das Gefühl, hier kennen sich einige mit Threads kein bisschen aus.

Also 'mal ganz langsam zum Mitschreiben:
  • Ein Thread verursacht alleine durch sein Vorhandensein eine Menge Arbeit für den Prozessor. Synchronisation, Wechsel des Threads (incl. Zustandssicherung), ganz zu Schweigen vom Verwaltungsaufwand beim Erstellen.
  • Bei einem Single-Prozessor-System ist ein Programm mit mehreren Threads immer langsamer als ohne. Ich klammere hierbei HT aus, das kann unter bestimmten Umständen was bringen.
  • Ein Thread lohnt sich erst, wenn die zu leistende Arbeit auch langwierig genug ist. Sonst frisst nämlich der Overhead die Ersparnis auf Multi-Prozessor-Systemen auf. Hier ist auch das Problem dieses Beispiels zu suchen.
  • Delphi-Referenz durchsuchenSynchronize bremst einen Thread aus, und sollte nur dort verwendet werden, wo es unumgänglich ist. Das ist hier kein Problem.
Zitat:

Zitat von Hallo_Thomas
Es kann nicht an Synchronize liegen, nehmt es raus aus dem Programm und ihr werdet es merken!!!!!!!!!!!!!!!!!

Siehe oben.

Gruß
xaromz

Hallo_Thomas 19. Aug 2006 14:17

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
@xaromz

Richtig,xaromz Synchronize stellt hier kein Problem dar.


Was WILL ich, ich will das 2 Threads, die in einer Schleife immer wieder aufgerufen werden,so zügig arbeiten, dass sich bei einem Dualcoresystem der Aufwand lohnt, siehe erster Beitrag und Titel, da dieses Beispiel auch bei Dualkern-Systemen Langsamer läuft!


Ohne Frage ein Problem:
Ein Thread lohnt sich erst, wenn die zu leistende Arbeit auch langwierig genug ist. Sonst frisst nämlich der Overhead die Ersparnis auf Multi-Prozessor-Systemen auf. Hier ist auch das Problem dieses Beispiels zu suchen.

Meine Meinung ist ja, dass das ewige erstellen zu viel Zeit kostet, dass müsste man doch um gehen können?

Meine Theorie war:

Den Thread erstellen

Dann ab in die Schleife Werte Übergeben, abarbeiten, Werte zurückgeben, Thread anhalten,
Werte übergeben, Werte abarbeiten.................


Schleife zu Ende, Thread schliessen

Christian Seehase 19. Aug 2006 16:13

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Moin Thomas,

Zitat:

Zitat von Hallo_Thomas
da dieses Beispiel auch bei Dualkern-Systemen Langsamer läuft!

hast Du schon mal versucht, einem zweiten Thread mit MSDN-Library durchsuchenSetThreadAffinityMask eine andere CPU zuzuordnen?
Ich habe nämlich den "bösen" verdacht, dass dies nicht automatisch geschieht, so dass sich zwei Threads eine CPU teilen, wie auf einem Einzelprozessor-System.

Wie mit der Funktion genau umzugehen ist, kann ich Dir allerdings leider auch nicht sagen. :?

xaromz 19. Aug 2006 18:28

Re: MultiThreading Bei mir ca. 40x Langsamer bei IntegerBere
 
Hallo,
Zitat:

Zitat von Hallo_Thomas
Was WILL ich, ich will das 2 Threads, die in einer Schleife immer wieder aufgerufen werden,so zügig arbeiten, dass sich bei einem Dualcoresystem der Aufwand lohnt, siehe erster Beitrag und Titel, da dieses Beispiel auch bei Dualkern-Systemen Langsamer läuft!

Du hast offensichtlich nicht richtig gelesen. Das Problem, warum Dein Code auch auf Multi-Prozessor-Systemen langamer ist, liegt (zum Teil) daran, dass nicht nur das Erstellen, sondern auch das Verwalten von Threads seine Zeit benötigt.

Abgesehen davon habe ich mir jetz doch mal Deinen Quellcode angesehen. Ein Konzept konnte ich da leider ebenso wenig entdecken wie einen einheitlichen Stil.

Deine Versuche, einen Thread zu erzeugen, der dann wieder eigene Thread erzeugt, und zwar nach einem wie auch immer gearteten Schlüssel, sind irgendwie komisch :gruebel: .

Statt eines akademischen Aufbaus wäre eine konkrete Anwendung besser, dann kann Dir sicher auch geholfen werden.

Gruß
xaromz


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:57 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz