Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   mehr als 1 Prozessorkern verwenden (https://www.delphipraxis.net/160172-mehr-als-1-prozessorkern-verwenden.html)

gelöschterBenutzer 30. Apr 2011 18:38

mehr als 1 Prozessorkern verwenden
 
hi zusammen,

ich möchte für mein Programm mehr als 1 Prozessorkern verwenden. Habe gehört, dass es über Threading möglich ist. Allerdings berechnet mein Programm nur Primzahlen und ein 2ter Thread wäre dafür bestimmt unsinnig, da ich nur eine Prozedur habe.

Diese Frage wurde bestimmt schon sehr oft gestellt. Ich bräuchte nur ein Anstoß wonach ich suchen muss.

Gruß gelöschterBenutzer

Satty67 30. Apr 2011 18:52

AW: mehr als 1 Prozessorkern verwenden
 
Selbst wenn eine Aufgabe nicht teilbar ist, kann ein "ArbeitsThread" sinnvoll sein, weil das Hauptprogramm besser auf Eingaben reagiert.

Für mehr als ein ArbeitsThread müsste man schauen, ob die Primzahlsuche eine teilbare Aufgabe ist.

Ein Thread-Beispiel ist übrigens seit mind. Delphi 5 im Demo-Ordner dabei...

gelöschterBenutzer 30. Apr 2011 19:49

AW: mehr als 1 Prozessorkern verwenden
 
Das es über Threads möglich ist weis ich ja ;) Aber gibt es nicht einen anderen Weg mehr Kerne anzusprechen?

Luckie 30. Apr 2011 19:51

AW: mehr als 1 Prozessorkern verwenden
 
Wie soll das gehen? Überlege doch mal. Du haste EINEN Thread, wie soll der auf mehreren Kernen sinnvoll laufen? Soll das Betriebssystem den EINEN Thread ständig eine anderen Kern zuweisen?

Bummi 30. Apr 2011 19:52

AW: mehr als 1 Prozessorkern verwenden
 
passiert ja eh ....

mschaefer 30. Apr 2011 20:28

AW: mehr als 1 Prozessorkern verwenden
 
Wenn der Thread "Parallele Primzahlberechnung" heissen sollte, dann hätte ich hier was Paralleles Programmieren mit Java.

Grüße in die Runde

Sir Rufo 1. Mai 2011 00:38

AW: mehr als 1 Prozessorkern verwenden
 
Zitat:

Zitat von Luckie (Beitrag 1097959)
Wie soll das gehen? Überlege doch mal. Du haste EINEN Thread, wie soll der auf mehreren Kernen sinnvoll laufen? Soll das Betriebssystem den EINEN Thread ständig eine anderen Kern zuweisen?

Zitat:

Zitat von Bummi (Beitrag 1097960)
passiert ja eh ....

Aber abwechselnd und niemals gleichzeitig ;)

@gelöschterBenutzer

Um sich das mit den Threads und CPU besser vorstellen zu können:

Mit einem Eimer (Thread) soll eine Person (CPU) Wasser von A nach B transportieren (Aufgabe).
Auch wenn du mehrere Personen hast, kann immer nur eine Person die Aufgabe erfüllen, da es ja nur einen Eimer gibt.
Hast du nur eine Person und viele Eimer, dann muss sich die Person sich ganz schön abrackern.
Optimal ist pro Person einen Eimer zur Verfügung zu stellen, dann hat man die beste Auslatung.

Manchmal machen aber auch mehr Eimer Sinn:

Angenommen das Befüllen und Ausleeren der Eimer geht autonom, dann kann es sinnvoll sein 3 Eimer pro Person zu haben
  • Eimer 1 beim Befüllen (z.b. Daten aus Datenbank lesen)
  • Eimer 2 beim Transport (Daten verarbeiten)
  • Eimer 3 beim Ausleeren (Ergebnis speichern/übertragen)

generic 1. Mai 2011 02:39

AW: mehr als 1 Prozessorkern verwenden
 
Zitat:

Zitat von gelöschterBenutzer (Beitrag 1097942)
hi zusammen,
Programm nur Primzahlen und ein 2ter Thread wäre dafür bestimmt

Also Primzahlen werden meist in einer Schleife berechnet.
Warum teilst du nicht die Datenmenge der Schleife und verteilst die gleichmäßig auf die CPUs.

Suche mal nach der Omnithreadlibrary (Parallel.ForEach) alternativ geht auch TThread. In der Omni sind sogar die meisten Demos mit Primzahlen-Berechnung.

In einer den nächsten Entwickler-Magazin Ausgaben, wird ein Artikel über die Omni-Lib und Multithreading sein.

Bummi 1. Mai 2011 08:28

AW: mehr als 1 Prozessorkern verwenden
 
Zitat:

Aber abwechselnd und niemals gleichzeitig
ist mir schon klar, die Antwort bezog sich auf Luckies Post....


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:47 Uhr.

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