AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Multithread und File I/O bei SSD/HDD

Ein Thema von Benmik · begonnen am 23. Apr 2016 · letzter Beitrag vom 24. Apr 2016
Antwort Antwort
Benedikt Magnus

Registriert seit: 6. Jul 2012
Ort: Bonn
190 Beiträge
 
FreePascal / Lazarus
 
#1

AW: Multithread und File I/O bei SSD/HDD

  Alt 23. Apr 2016, 16:37
Wenn das Prüfen auf SSD wegfällt, könntest du als Workaround auch einen kleinen Teil der Dateien normal und einen multithreaded auslesen, anschließend vergleichen, was schneller ging und damit fortfahren.
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
577 Beiträge
 
Delphi 12 Athens
 
#2

AW: Multithread und File I/O bei SSD/HDD

  Alt 23. Apr 2016, 16:50
... vergleichen, was schneller ging und damit fortfahren.
Das merk ich mir schon mal. Das könnte selbst dann gut sein, wenn sich eine Lösung fände.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: Multithread und File I/O bei SSD/HDD

  Alt 23. Apr 2016, 17:33
Das Zauberwort heißt Pipeline.
  1. Bild von der Platte lesen (1 Thread)
  2. Vorschau erstellen (CPU-Count Threads)
  3. Vorschau speichern (1 Thread)
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
577 Beiträge
 
Delphi 12 Athens
 
#4

AW: Multithread und File I/O bei SSD/HDD

  Alt 23. Apr 2016, 18:30
War ja auch meine Idee, aber nach viel Experimentieren fand ich seinerzeit den Weg über IExtractImage (Achtung: Interface! ) mit GetLocation und Extract am schnellsten. Und da kann man Bild-Lesen und Vorschau-Erstellen nicht trennen.

Geändert von Benmik (23. Apr 2016 um 19:08 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#5

AW: Multithread und File I/O bei SSD/HDD

  Alt 23. Apr 2016, 20:44
War ja auch meine Idee, aber nach viel Experimentieren fand ich seinerzeit den Weg über IExtractImage (Achtung: Interface! ) mit GetLocation und Extract am schnellsten. Und da kann man Bild-Lesen und Vorschau-Erstellen nicht trennen.
Warum kann man die nicht trennen?
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benmik

Registriert seit: 11. Apr 2009
577 Beiträge
 
Delphi 12 Athens
 
#6

AW: Multithread und File I/O bei SSD/HDD

  Alt 23. Apr 2016, 20:57
Äh - weil Extract beides macht und in der Shell32.dll sitzt (dachte ich jedenfalls) ???

In gewisser Weise hat sich das aber erledigt, weil ich Benedikt Magnus' simple, aber geniale Idee (fällt ja öfter zusammen) mal ausprobiert habe, und siehe da, Multithread ist auch bei HDD besser, wenn die Dateien noch im Cache sind (ich messe jetzt auch bei FP1 und FP2 um die 25 sec, wie bei der SSD, habe mich also vermutlich bei der ersten Auflistung vertan). Insofern entfällt die Unterscheidung zwischen HDD und SSD. Hat eigentlich auch was für sich, wenn man einfach das nimmt, was schneller ist.
Ich messe jetzt erst n Dateien Single-Thread, dann n Dateien Multi-Thread und vergleiche. n ermittle ich nach der Formel von MaxThreads von AsyncCalls, NumberOfCores * 2 - 2, also einmal eine Poolgröße. Ist die Gesamtanzahl Dateien kleiner als 2 * n, dann ist es eh egal.
  Mit Zitat antworten Zitat
Benutzerbild von Valle
Valle

Registriert seit: 26. Dez 2005
Ort: Karlsruhe
1.223 Beiträge
 
#7

AW: Multithread und File I/O bei SSD/HDD

  Alt 24. Apr 2016, 08:07
Hi,

wenn du noch Optimierungsbedarf hast, dann hab ich noch zwei Anregungen.

Zum einen stelle ich mir die Frage, ob du nach jedem einzelnen Testlauf einen Rechnerneustart durchgeführt hast. Der Festplattencache des Betriebssystems kann dir sonst ganzschön die Ergebnisse versauen.

Zum anderen muss ich Sir Rufo zustimmen. Deine CPU ist immernoch den größten Teil der Zeit damit beschäftigt auf die Festplatte zu warten. Erst wenn das Bild vollständig geladen wurde, kann sie rechnen. Anschließend ist sie erneut mit warten (speichern + neues Bild laden) beschäftigt.

Mitteils einer Pipeline kannst du Laden, Bearbeiten und Speichern in mehrere Threads auslagern. Du kannst damit einen Puffer benutzen, der immer so viele Bilder wie möglich im RAM vorhält; egal ob gerade erst gelesen und fertig zum abspeichern. Mit einer ausreichenden Menge Arbeitsspeicher lässt sich dein Vorgang so sicherlich nochmals drastisch beschleunigen.

Hier ist noch eine Grafik die das schön anzeigt.
Valentin Voigt
BOFH excuse #423: „It's not RFC-822 compliant.“
Mein total langweiliger Blog
  Mit Zitat antworten Zitat
Antwort Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:36 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