Threads: signifikante Unterschiede Lazarus - Delphi?

[photor]

Hallo Forum,

ich muss jetzt einfach mal hier nachfragen, weil ich es einfach nicht verstehe. Vielleicht weiß hier ja jemand mehr als ich.

Folgendes: "ich lerne gerade Threads". D.h. ich habe hier @Home auf meinem kleinen Lappy (Lazarus auf ArchLinux) ein Programm von alles linear rechnen auf Threads umgebaut. Das funktioniert auch in Grenzen.

Da mein Lappy nur 4 Kerne hat kann ich also nur bis zu 4 Threads parallel vergleichen. Die Ergebnisse sind jetzt nicht sooo doll (4 Threads brauchen gerade mal halb so lange, wie die 1-Thread-Variante), aber es wird schneller und ich sehe, dass wirklich 1, 2, 3 oder 4 Kerne genutzt werden; an der Effizienz kann man bestimmt noch was tun.

So weit, so gut.

Jetzt habe ich dieses Programm auf Delphi (10, Seattle) portiert und lasse es auf dem Büro-24-Kerne-128GB-Windows-Rechner laufen. Aaaaaber leider macht es überhaupt keinen signifikanten Unterschied, ob ich 1 oder 8 Kerne nutze. Die CPU-Auslastung bleibt bei einem Maximum von ~10% (was etwa 2 Kernen entsprechen würde) - entsprechend gering ist der Laufzeitunterschied. (GROßES FRAGEZEICHEN in meinem Gesicht)

Außer ein paar kleineren Anpassung für die Portierungen ist das Programm so geblieben, wie es unter Lazarus lief (also Erzeugung und Start der Threads, Abarbeitung, Datenstrukturen etc). Ich verstehe nicht, warum der nahezu identische Code so unterschiedlich reagiert.

Daher Frage ich einfach mal, ob jemand eine Idee hat, woran das liegen kann? Gibt es irgendeinen Haken, eine Einstellung, einen Bug, ein sonstwas, was dieses Verhalten bezüglich der Threads bzw. der Parallelisierung erklären könnte?

Vielleicht gibt es hier ja auch Delphi-wissende. Bin dankbar für jede Anregung.

Code kann ich leider nicht zeigen, da einerseits zu viel und andererseits wg. vertraulich.

Ciao,
Photor

[Winni]

Hi!

Ich weiß nicht, was Delphi mit den Threads treibt.

Aber ein paar grundlegende Überlegungen bzw. Erfahrungen.

Das Starten eines Threads ist zeitaufwendig - der Overhead vergrößert sich.
Deshalb sollte man die Threads möglichst so gestalten, dass sie möglichst lange laufen:

Beispiel Bildbearbeitung: Der Thread bearbeitet jede Zeile n des gesamten Bildes, wobei n die Anzahl der Theads ist.
Eine große Verlangsamung ist: Starte für jede Bildzeile einen Thread.

Wenn Du jetzt auf der Super-Duper-Maschine den Job in 128 Threads aufteilt, so erhöht sich der Overhead massiv, da
1. Die Anzahl der gestarteten Threads durch den Vorteil der Anzahl durch den Overhead aufgefressen wird
2. Die Länge der Jobs wird ja durch die große Anzahl massiv kürzer, so dass das Verhältnis Overhead zu produktiver Zeit im Thread deutich schlechter wird.


Vorschlag zu einem Test, der mich auch persönlich interessiert, da ich keine 128-Kern-Mascine zur Verfügung habe:

Mach doch mal eine Versuchsreihe, bei dem Du die Anzahl der Threads von 2 bis 128 in Zweier-Potenzen durchlaufen lässt. Gleichzeitig muss natürlich Last pro Thread um diesen Faktor geürzt werden. Und dann stoppe mal die Zeit. Das würde mich echt interessieren. Und auch mal einen Anhaltspunkt geben, wieviel Threads noch sinnvoll sind.

Ein Trick noch, wenn de Länge der zu verarbeitenden Daten nicht so übersichtlich ist, wie bei einem Bild. Habe ich angewendet für die Projektion von Geo-Daten (Ländergrenzen), die sehr verschiedene Länge haben:

Starte immer einen Thread mehr, als Du Kerne hast. Dieser Thread bekommt dann nur minimale Rechenzeit, aber wenn ein anderer Thread fertig ist, bekommt der sofort die volle Rechenzeit. Dann sofort den nächsten Thread starten .....

Winni

[af0815]

WIe WInni es schon gesagt hat, ist die Aufgabe für den Thread geeignet ? Nicht das auf der Supermachine, das gerade das Hemmnis ist. Einfach auch die Lebenszeit des Threads bei den Versuchen mit dokumentieren. Nicht umsonst wurde gerade unter Windows auch die Aufteilung in sogenannten Fibers schon diskutiert.
Die modernen Prozessoren können sehr viel Code direkt auf der CPU in den schnelle Cache halten. Der Overhead für den Threadwechsel kann da schon mal den Gewinn fressen. Auch überprüfen ob der Thread in sich optimal schnell ist, nicht das der irgendwas aus anderen Bereichen (Festplatte ist da so ziemlich der worst Case) braucht. Synchronisation mit anderen Prozessen kann da auch alles auffressen.
Ach ja, Linux und Windows haben da andere Konzepte. Damit kann das natürlich auch in die Effizienz stark hineinspielen.

Und wenn du vielleicht etwas Testcode zum probieren hast, dann sind wir alle beschäftigt und schreiben keinen Schwachsinn (SCNR)

[Warf]

Das Hauptproblem bei threads ist normalerweise Synchronisation. Um irgendwas mit dem ergebnis der threads machen zu können muss das ergebnis übergeben werden und das benötigt normalerweise eine Form der Synchronisation (z.B. über Snychronize, TThread.Queue, Critical sections oder sonstiges). Was dabei passiert ist das die entsprechenden Threads angehalten werden um die Synchronisation durchzuführen.
Stell dir das vor als wenn du auf der Autobahn mit einem anderen Auto Passagiertausch machen willst, damit der Passagier in einem Stück rüber kommt ist das beste was man tun kann das man zur Haltebucht Fährt, den Passagier ablädt und dann das andere Auto kommt bei der Haltebucht anhält und den Passagier aufnimmt.

Wenn du jetzt mehrere threads hast die versuchen alle zu synchronisieren, dann ist das wie in der Analogie wenn viele Autos Passagiere tauschen wollen, es gibt aber nur eine Haltebucht. Also bildet sich eine Schlange vor der Haltebucht, und alle autos warten darauf das der vorrige seinen Passagier abgeladen hat. Da ist egal das es 4 Spuren gibt, wenn alle auf die selbe Haltebucht warten, wurde der Verkehr auf eine Spur gezwengt.
Genau das passiert auch dann mit den threads. Wenn du viel synchronisation hast dann bringen dir die Threads gar nichts, denn im endeffekt verbringen die die ganze Zeit dann nur mit warten. Die threads werden damit zwangsserialisiert.

Verschiedene Synchronisationsmethoden sind dabei unterschiedlich schlimm. Synchronize ist die schlimmste von allen Sünden. Das hält beide Threads an (den aufrufenden und den Main thread), bis die Synchronisation fertig ist. Das ist vergleichbar mit man stellt sich in die Haltebucht, und wartet bis das andere Auto auch in der haltebucht ist, dann wird die Person erst ausgetauscht, und beide autos fahren weiter.
Deutlich besser ist da TTHread.Queue, wobei nur eine "Message" abgesendet wird, die der Mainthread dann irgendwann abarbeitet. In der Metapher wäre das wenn man in die Haltebucht fährt, den Passagier grad rauswirft und direkt weiter fährt, und irgendwann kommt dann das Auto vorbei was die person abholt. Währendessen können aber schon andere autos weitere personen abwerfen.

Gleichzeitig hat die Synchronisation auch einen gewissen statischen overhead. Generell, alles was den Scheduler involviert ist ziemlich langsam (bis zu mehreren Milliskeunden). Der Scheduler ist involviert sobald sich der Thread schlafen legt. Deshalb gibt es häufig auch so genannte spin locks, die bis zu ein paar millisekunden spinnen (einfach nur die CPU auslasten ohne dabei den thread schlafen zu legen), damit für potentiell sehr kurze wartezeiten von ein paar nanosekunden nicht der Thread für mehrere millisekunden schlafen gehen muss.

Der unterscheid zwischen Delphi und Lazarus könnte also z.B. daher rühren das die Synchronisation anders implementiert ist. Entweder logisch anders (siehe Synchronize vs TThread.Queue beispiel oben), oder einfach andere art des Lockings mit größerem Statischen Overhead. Vielleicht ist es auch einfach das Betriebsystem was anders ist.

Generell allerdings kannst du als Faustregel auch nehmen, wenn beim Threading der Performance gain nicht Linear zur Anzahl an threads ist, hast du irgendwo eine form der Zwangsserialisierung drin. Am besten überprüfst du alle deine Synchronisierungsmechanismen, schaust wie oft die getriggert werden (kannst ja einfach eine simple variable hochzählen über ne gewisse zeit), und wie viel Wartezeit dabei drauf geht.
Ich würde schätzen das der größte teil der Performance verluste bei Threads da her rühren, das man einfach viel zu oft Synchronize, TThread.QUeue oder EnterCriticalSection aufruft.

Generelle Faustregel, ein thread lohnt sich nur wenn er um Größenordnungen mehr rechenarbeit ausführt als synchronisation benötigt.

[photor]

Moin Winni,

Ich weiß nicht, was Delphi mit den Threads treibt.

Naja. Nicht viel anderes, als unter Lazarus auch. Nicht optimal, weil ja die Beschleunigung nicht so dolle ist (Faktor 4 mehr Threads um einen Faktor 2 bei der Geschwindigkeit zu bekommen). ABER ich sehe, dass tatsächlich mehrere (nämlich genau die spezifizierte Anzahl) Cores arbeiten. Der Verwaltungsaufwand ließe sich bestimmt noch reduzieren.

Mach doch mal eine Versuchsreihe, bei dem Du die Anzahl der Threads von 2 bis 128 in Zweier-Potenzen durchlaufen lässt. Gleichzeitig muss natürlich Last pro Thread um diesen Faktor geürzt werden. Und dann stoppe mal die Zeit. Das würde mich echt interessieren. Und auch mal einen Anhaltspunkt geben, wieviel Threads noch sinnvoll sind.

Naja. Genau das habe ich ja mit 1,2,3,4,6,8 Threads schon probiert. Erfolg: der Geschwindigkeitsgewinn liegt bei knapp 10% (wenn überhaut) zwischen 1 und 8 Threads. Den Unterschied schreibe ich wirklich der Thread-Verwaltung zu.
Maximale CPU-Auslastung dabei: 10% (entspricht ca 2 Kernen, die maximal gleichzeitig werkeln ). Noch mehr Threads bringen wahrscheinlich dann auch nichts.

Das sieht für mich so aus, als würde gar nichts wirklich parallel laufen. Das war der Punkt, an dem ich dachte ich frag mal nach.

Nein, stimmt nicht ganz: ich habe natürlich ein bisschen im Netz gelesen und bin über Meldungen zu Bugs bezüglich Threads und so bei Delphi gelesen - aber alles entweder bei den neuen (jünger als mein Seattle) oder wesentlich älteren Delphi-Versionen - Gründe und ab wann und ob gefixt stand da nicht bei. Eigentlich war DAS der Punkt, an dem ich hier nachgefragt habe (ich habe den Verdacht, dass da bei Delphi wirklich nichts parallel läuft).

Wenn es unter Lazarus ja auch nicht tun würde, würde ich an meinem Konzept als ganzes zweifeln. ... Aber so?

Ciao,
Photor

[af0815]

Bei D7 habe ich Konzepte mit Threads sehr wohl verwendet und die laufen wirklich parallel. Das kann mit den Beobachtungen (im Netz) nicht ganz zusammstimmen. Kritisch wird es wie Winni gesagt hat, wenn es um Synchronisation geht, dort kann alles ins Gegenteil kippen. Mann kann sich über 3 Ecken auch sehr gut komplett blockieren.

[Socke]

Das Hauptproblem bei threads ist normalerweise Synchronisation. Um irgendwas mit dem ergebnis der threads machen zu können muss das ergebnis übergeben werden und das benötigt normalerweise eine Form der Synchronisation (z.B. über Snychronize, TThread.Queue, Critical sections oder sonstiges). Was dabei passiert ist das die entsprechenden Threads angehalten werden um die Synchronisation durchzuführen.

Das ist ein nicht zu unterschätzendes Thema: Hier hast du möglicherweise weniger mit FPC vs. Delphi sondern viel mehr mit Linux vs. Windows zu kämpfen.

[TSchnuckenbock]

Hast du mal überlegt, das Projekt auch auf Windows mit Lazarus umzusetzen und dann zu vergleichen?

Mit den neueren Delphis kann man eventuell auch nach Linux compilieren. Hab ich so dunkel im Hinterkopp.

Und dann fällt mir zu Threads noch ein, daß man denen irgendwie ggf. höhere/niedrigere Priorität zuordnen kann.

Im Job habe ich mindestens ein Projekt, was ich mit XE5 erzeuge und was mehrere Threads hat. Das läuft alles tacko. Aber die Synchronisation war frickelig.

[Winni]

Hi!

Also wenn Du nur so wenig Geschwindigkeitsgewinn erzielst, dann läuft was falsch. Wie schon oben erwähnt: Synchronisierst Du mit der GUI? Schreibst Du was auf Platte?

Also meine Erfahrung mit den Geo-Koordiaten war so:

Ich hab nur von einem Array of TPointF (Geo Länge/Breite) auf ein anderes Array of TPointF (virtuelle Bildschirmpunkte) geschrieben. Teilweise aufwendigere Berechnungen der Projektion sowie "ist der Punkt sichtbar?". Dabei hab ich im Sekundentakt die CPU-Belastung aus /proc ausgelesen. Typischerweise wurden 7 Kerne zu 100% ausgelastet, der erste nur zu 96%. Reserviert das OS wohl noch eine Reserve für sich, damit auch noch etwas anderes passieren darf. Machmal brach die Auslastung in einem Kern etwas ein --> das war dann das Ende eines Threads und der Start des nächsten.

Die berechneten Daten wurden erst angezeigt, wenn alle Threads brechnet waren.

Zeig doch mal ein bischen Code, damit wir weiter kommen.

Keep on hackin'

Winni

PS.: AMD Ryzen 5 2400G, Suse Tumblewed

[photor]

Hast du mal überlegt, das Projekt auch auf Windows mit Lazarus umzusetzen und dann zu vergleichen?

Lazarus auf dem Firmenrechner wird nicht gehen. Ich kann/darf da nichts selbst installieren und bei der Einstellung in der Firma zu Open Source schon mal sowieso nicht. Iss so; kann ich leider nicht ändern.

Mit den neueren Delphis kann man eventuell auch nach Linux compilieren. Hab ich so dunkel im Hinterkopp.

Und dann fällt mir zu Threads noch ein, daß man denen irgendwie ggf. höhere/niedrigere Priorität zuordnen kann.

Im Job habe ich mindestens ein Projekt, was ich mit XE5 erzeuge und was mehrere Threads hat. Das läuft alles tacko. Aber die Synchronisation war frickelig.

Das mit der Synchronisation (und Windows) könnte tatsächlich anders laufen als bei Linux. So gesehen ist die Übertragung von Lazarus (Linux, @Home) nach Delphi (Windows, Büro) vielleicht wirklich keine gute Idee (auch wenn das zuvor immer recht gut geklappt hat).

Ich überlege, ob ich eines meiner relativ einfachen Test-Progrämmchen unter Delphi teste. Muss ich nur die Zeit zu finden.

Danke für den Input,
Photor

[photor]

Also wenn Du nur so wenig Geschwindigkeitsgewinn erzielst, dann läuft was falsch. Wie schon oben erwähnt: Synchronisierst Du mit der GUI? Schreibst Du was auf Platte?

Genau. Deshalb meine Anfrage hier

Also in die GUI wird erst geschrieben, wenn alle Threads durch sind. Die Ergebnisse werden in eine Liste (TObjectList) gepackt; der Zugriff darauf wird mit einer CriticalSection geregelt (kann ich abschalten, macht auf Lazarus aber kaum einen Unterschied). Erst ganz zum Schluss wird die Liste in ein TStringGrid auf der GUI sortiert.

Auf Platte wird weder geschrieben noch wird davon gelesen - nicht zu dieser Zeit.

Also meine Erfahrung mit den Geo-Koordiaten war so:

Ich hab nur von einem Array of TPointF (Geo Länge/Breite) auf ein anderes Array of TPointF (virtuelle Bildschirmpunkte) geschrieben. Teilweise aufwendigere Berechnungen der Projektion sowie "ist der Punkt sichtbar?". Dabei hab ich im Sekundentakt die CPU-Belastung aus /proc ausgelesen. Typischerweise wurden 7 Kerne zu 100% ausgelastet, der erste nur zu 96%. Reserviert das OS wohl noch eine Reserve für sich, damit auch noch etwas anderes passieren darf. Machmal brach die Auslastung in einem Kern etwas ein --> das war dann das Ende eines Threads und der Start des nächsten.

Die berechneten Daten wurden erst angezeigt, wenn alle Threads brechnet waren.

Zeig doch mal ein bischen Code, damit wir weiter kommen.

Wie schon im anderen Post geschrieben: ich schau mal, ob ich die Zeit finde, eines meiner Thread-Lern/Übe-Progrämmchen im Büro auf Delphi zu packen und will sehen, ob ich das Verhalten nachgestellt bekomme. Dann komme ich wieder. Ich sehe ein, dass man ohne Code schlecht was sagen kann (konkrete Fehlersuche war aber auch nicht der Sinn der Frage hier; es ging mir eher darum, auszuschließen, dass es da ein Bug oder so gibt, das mich grundsätzlich ausbremst.

Keep on hackin'

Jup,
Photor

[Warf]

Genau. Deshalb meine Anfrage hier

Also in die GUI wird erst geschrieben, wenn alle Threads durch sind. Die Ergebnisse werden in eine Liste (TObjectList) gepackt; der Zugriff darauf wird mit einer CriticalSection geregelt (kann ich abschalten, macht auf Lazarus aber kaum einen Unterschied). Erst ganz zum Schluss wird die Liste in ein TStringGrid auf der GUI sortiert.

Auf Platte wird weder geschrieben noch wird davon gelesen - nicht zu dieser Zeit.

Du könntest dir auch mal Synchronisationsfreie (lockless) datenstrukturen anschauen, mit hilfe von interlocked exchange (Atomare swap instruktion).
Damit wird kein locking benötigt sondern allerhöchstens ein paar nanosekunden gespinnt, und das kann die performance massiv verbessern

https://stackoverflow.com/questions/172 ... less-queue

[hum4n0id3]

Ein Vergleich mit unterschiedlicher Technologie, ist hier tatsächlich schwierig. Man müsste auf dem Büro-Rechner ebenfalls ein Arch-Linux mit Lazarus installieren. Delphi und Lazarus sind nicht gleich, Windows und Linux ebenfalls.

In meinem kleinen Hardware-Zoo befindet sich ein schicker Macbook Pro von 2012. Mein PC hat einen i7 und sonst techisch einfach überlegen. Aber PHP läuft auf Macbook 8 mal schneller als unter Windows. Das fand ich spannend und für den Windows PC eher enttäuschend.

Irgendwann habe einen Test mit Virtueller Maschine gemacht. Host Windows mit VmWare (vielleicht auch VBox, weiß nicht mehr), VHost Linux mit Lamp (Apache, PHP, etc..). Die VM (Linux) mit PHP war deutlich schneller als der Host (Windows) mit PHP.

PHP ist für Linux/Unix optimiert, während es für Windows eher für Entwickler verfügbar gemacht wird.

Daher würde eher ein Test mit Arch und Lazarus mehr Sinn ergeben, als Windows und Delphi. Ich habe mir auch Delphi angesehen und von Verhalten, schien es schneller als Lazarus zu laufen. Aber was sagt das schon...

Edit: vielleicht eine tragbare SSD mit installiertem Arch + Lazarus an den Büro Rechner anschließen, davon booten und Test machen?

[Mathias]

Ich habe auch kürzlich mit mehreren Threads gespielt, ich habe bei einem Mandelbrot meine Kerne ausgenutzt.
https://github.com/sechshelme/Lazarus-D ... Mandelbrot
Das Ergebnis lässt sich sehen.

Code: Alles auswählen

Thread Count: 1
Calc Time:     14.203
Thread Count: 2
Calc Time:      7.354
Thread Count: 4
Calc Time:      3.746
Thread Count: 8
Calc Time:      2.425
Thread Count: 16
Calc Time:      2.291
Thread Count: 32
Calc Time:      2.351
Thread Count: 64
Calc Time:      2.265

Einzig was mich beeindruckt, ist der Sprung von 4+. Mein "Intel Core i7-3770" hat nur 4 echte Kerne.
Als OS Linux 64Bit.

[Winni]

Einzig was mich beeindruckt, ist der Sprung von 4+. Mein "Intel Core i7-3770" hat nur 4 echte Kerne.
Als OS Linux 64Bit.

Hi!

Was meinst Du mit "echte Kerne".

Den Ergebnissen nach hast Du 8 Hyperthreads.

Winni

PS.: Hab ich richtig geraten. Sagt Intel: https://www.intel.de/content/www/de/de/ ... tions.html