Langsames Multithreading

[CarlAshnikov]

Zitat von BLin4ik:

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 von CarlAshnikov:

Zitat von BLin4ik:

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 von BLin4ik:

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

Zitat von BLin4ik:

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?