Langsames Multithreading

[himitsu]

Eigentlich sollte COINIT_APARTMENTTHREADED ohne Thread-Locking arbeiten, da dort der Programmierer angibt, daß er nichts Threadübergreifend benutzt.

Zitat:

Wenn Sie Apartmentthread angeben, übernehmen Sie die folgenden Garantien:

* Sie greifen auf jedes COM-Objekt von einem einzelnen Thread aus zu. Sie setzen keine COM-Schnittstellenzeiger gemeinsam bei mehreren Threads ein.
* Der Thread weist eine Meldungsschleife auf. (Siehe Fenstermeldungen in Modul 1.)

Aber das sollte natürlich auch nur auf COM-Zeugs Einfluss haben.

[BLin4ik]

@Captnemo

Würde die Dateien etwas kleiner sein, wäre das sicherlich kein Problem, die Datei wird bereits gepuffert,
aber natürlich nicht komplett in den Speicher genommen, da diese über Millionen Zeilen beinhalten kann und
der Zugriff über eine StringList schon etwas an Zeit kosten kann.

@himitsu
Die CSVFile klasse ist eine einfache Reader-Klasse, hier wird die Datei eingelesen und
gepuffert.
Das ReadLine liest die Zeile in eine StringListe ein, sodass man über einen Index an die verschiedenen Spalten
rankommt.

Die Daten liegen alle auf einer Festplatte und zwar auf der SSD.

@Patito
Also der FastMM ist bei mir im Einsatz

@OlafSt
"COINIT_MULTITHREADED" hatte ich bereits schon ausprobiert, ist das selbe Ergebnis.

Der Algorithmus ist natürlich um einiges ausgereifter und so gut wie fertig, deswegen
verwende ich die CoInitializeEx Sachen, da ich mit COM Arbeite.
Aber es scheitert ja schon bereits bei einer einfachen Schleife.

[CarlAshnikov]

Zitat:

Zitat von BLin4ik (Beitrag 1303184)

Die Threads müssen zugewiesen werden, da das in Delphi 5 nicht automatisch passiert und alle nur den ersten Kern verwenden.

Das stimmt nicht, die Verteilung der Threads hat mit Delphi 5 nichts zu tun.

[BLin4ik]

Zitat:

Zitat von CarlAshnikov (Beitrag 1303207)

Zitat:

Zitat von BLin4ik (Beitrag 1303184)

Die Threads müssen zugewiesen werden, da das in Delphi 5 nicht automatisch passiert und alle nur den ersten Kern verwenden.

Das stimmt nicht, die Verteilung der Threads hat mit Delphi 5 nichts zu tun.

Nimmt man die normale TThread-Klasse kriegen die Threads immer den ersten Kern zugewiesen (wurde getestet),
deswegen habe ich eine eigene MultiThread-Klasse erstellt die sich im Kreis dreht, sodass
je nach Anzahl der Threads, alle Kerne gleichmäßig bedient werden.

[himitsu]

Die Zuweisung nimmt Windows vor und nicht TThread.

[BUG]

Zitat:

Zitat von BLin4ik (Beitrag 1303210)

Nimmt man die normale TThread-Klasse kriegen die Threads immer den ersten Kern zugewiesen (wurde getestet),

Windows sollte die Threads migrieren wenn sie mehr als einen Kern auslasten würden :mrgreen:

Zitat:

Zitat von BLin4ik (Beitrag 1303205)

Das ReadLine liest die Zeile in eine StringListe ein, sodass man über einen Index an die verschiedenen Spalten
rankommt.

Und da ist doch schon die Speicherverwaltung (Strings und die Stringlist selbst).
Frage in den Raum: Verwendet Delphi 5 schon einen Speichermanager, den Multithreading nicht sofort in die Knie zwingt?

[BLin4ik]

Juhu!

Ich habe die Lösung gefunden, der FastMM hat mir durch eine Einstellungen einen Strich
durch die Rechnung gemacht! Und zwar musste ich "NeverSleepOnThreadContention" akvieren
dadurch kriege ich volle Leistung, die Threads wurden nämlich immer Schlafen gelegt.


Quelle: http://www.thedelphigeek.com/2011/09...entionnot.html

[Luckie]

Und ich würde die Threads nicht von Hand auf einzelne Kerne zuweise und es dem OS überlassen. Hingegen aller Gerüchte weiß Windows selbst sehr gut wie es mit Speicher und Threads am besten umgeht. Man gewinnt nichts außer zusätzliche, überflüssigen Code, der auch noch fehlerhaft sein kann. Und sollte Microsoft in Zukunft was am Threadhandling ändert, schießt man sich eventuell eher ein Eigentor.

Ich sage mir immer: Was Windows selber machen/verwalten kann, soll es auch selber machen. Wozu mir zusätzliche Arbeit machen?