Hallo,

ich stelle gerade erstmalig ein Programm auf mehrere Threads um, damit moderne Mehrkernprozessoren aus genutzt werden können.

Mein Programm besteht grob aus aus:

A. Datensätze (32 Bytes) gemäß Programmcode Schritt für Schritt berechnen (kein Datei-I/O, pure CPU-Arbeit)
B. Jeden neu berechneten Datensatz speziell analysieren und in einer Paintbox im Hauptformular als Punkt in einem x-y-Diagramm darstellen.
Auf einem Ein-Kern-Rechner brauchen A und B ingesamt etwa die gleiche Zeit.

Umsetzung auf zwei Threads:
A ist der Haupt-Thread, B ist ein von A erzeugter Thread. A schreibt mit Writefile jeden Datensatz in eine (anonyme) Pipe, B liest per Readfile und arbeitet.
Das lief, aber langsamer als wenn alles im Haupthread gemacht wird.

Also habe ich Versuche auf einer (übersichtlicheren) Ein-Kern-Maschine gemacht und ein für mich unverständliches Ergebnis gefunden. Ich habe erwartet, dass die Threadumschaltung Zeit kostet, und deshalb einen großen Pipebuffer als vorteilhaft gesehen. Aber das Gegenteil ist der Fall!?

Pipebuffer = 1000 Aufträge = 32 kB: 470 ms, 30-60 neue Aktivierungen des Threads B
Pipebuffer = 100 Aufträge = 3 kB: 170 ms, um 75 neue Aktivierungen des Threads B
Pipebuffer = 10 Aufträge = 320 B : 180 ms, um 602 neue Aktivierungen des Threads B
Pipebuffer = 2 Aufträge = 64 B : 210 ms, um 1800 neue Aktivierungen des Threads B

(ohne Aufteilung auf zwei Thraeds werden 100 ms Zeit gebraucht.)

Hat da jemand eine Erklärung? (Windows XP SP3).

Gruß GuaAck

Moin,

GuaAck hat folgendes geschrieben :

moderne Mehrkernprozessoren

Das ist sowas wie ein weißer Schimmel, oder?

GuaAck hat folgendes geschrieben :

Hat da jemand eine Erklärung? (Windows XP SP3).

Pipes in Windows sind schnarchlangsam. Das hat irgendwas mit dem Windows-eigenen Locking darauf zu tun, den Artikel dazu (irgendwas auf CodeProject...) suche ich seit Jahren. Das war eine Gegenüberstellung der verschiedenen Kommunikationswege (Pipes, Mailslots, Sockets, WM_COPYDATA, diverse SharedMemory Implementationen), die man in Windows so für IPC hat. Ich find ihn zwischen den ganzen SharedMem-Implementationen, die seit ich den das erste mal gesehen habe entstanden sind einfach nicht wieder...

Spricht irgendwas dagegen, die Daten selbst in einem Ringpuffer zu verwalten? Eine feste Satzgröße macht das ja gradezu einfach, da du nur ein Array und je einen Lese-/Schreibzeiger brauchst.

GuaAck hat folgendes geschrieben :

(ohne Aufteilung auf zwei Thraeds werden 100 ms Zeit gebraucht.)

Lohnt sich das dann überhaupt? Im besten Fall kostet ein neuer Thread (Setup, mindestens ein Context-Switch) um die 20ms, da müsste die Ersparnis schon magisch sein um das wieder rauszuholen.

Grüße,
Martok

Wenn die Threads innerhalb eines Prozesses liegen, würde ich auf IPC komplett verzichten. Die ist ja dafür da, um mehrere Prozesse miteinander reden zu lassen.

Ich würde MainThread A einfach die Blöcke berechnen lassen und in eine TQueue schieben (Thread-Safety beachten !). Thread B fischt anschließend einen Block aus der Queue heraus und grübelt daran weiter. So können beide Threads unabhängig voneinander an den Daten herumrechnen und Thread B wartet sogar von ganz allein auf neue Daten, weil MeinThread A ja noch mehr am Hals hat (Message-Queue bearbeiten, Paintbox zeichnen etcpp).

Da Thread A und B jeweils gleiche Laufzeiten haben, lohnt sich mehr als ein B-Thread eh nicht - der A-Thread bekommt gar nicht schnell genug Daten bereitgestellt für mehr als einen B-Thread.

Wie sieht denn deine Synchronisation mit dem Formular zur Anzeige aus? Denn da liegt oft der Hund begraben.

Mit Pipes hatte ich was die Geschwindigkeit angeht bisher weniger Probleme, da deren Verwaltung in der Regel trotzdem um Größenordnungen unter der der Aufgaben lag. Es gibt aber auch schnellere Lösungen, klar.

Hallo und Danke an Alle,

a) Danke für den "weißen Schimmel".... stimmt schon.

b) TQueue: TQueue.pop wartet bei mir nicht, sondern ergibt eine Fehlermeldung, wenn die Queue leer ist. (Ich habe Delphi 7.)

c) Ringpuffer war mein erster Ansatz. Der Puffer ging gut, aber das Problem, den Lese-Thread zu aktivieren, wenn es Arbeit gibt (ohne da bei jedem Schreiben zu machen) klappte nicht.

d) Synchronisation mit Formular: Synchronize usw. nutze ich nicht. Außerdem, damit kann ich mir das unerwartete Zeitverhalten nicht erklären.

Jaenicke: Genau Dein Argument veranlasste mich zu der Erwartung, dass eine "lange" Pipe, in der erst einmal vieles gespeichert wird bevor ein Threadwechsel gemacht wird, schneller sein müsste, als wenn man nur eine sehr kurze Pipe hätte. Aber genau das Gegeteil habe ich ja beobachtet.


Ich werde die Ringpufferlösung noch einmal aufgreifen.

Danke nochmals,
Gruß
GuaAck

Zum einen kann man die TQueue.POP-Exception abfangen und dazu benutzen, den Thread schlafen zu legen. Zum anderen kann man mit TQueue.Count nachschauen, ob was drin ist

Noch besser wäre ein Event. Thread A stellt den Event auf Signalled, nachdem Daten in die Queue geschoben wurden. Thread B wartet auf Signalled und bearbeitet die Aufgaben so lange, bis TQueue.Count = 0 ist. Dann wartet er wieder auf Signalled.

Lässt sich daraus vielleicht ein Beispielprojekt machen, das einfach Dummydaten erzeugt (z.B. einfach nen Sleep statt echter Berechnung)? Dann könntest du da nur die relevanten Teile drin lassen ohne dein echtes Projekt posten zu müssen, und wir könnten dir konkret helfen...