3. Multithreading Flaschenhals

Multithreading Flaschenhals

  • G

    gibts da keine schlauen Tricks wie man das Codemäßig bissl beschleunigen kann?

    Irgendwelche trickserein zwischen HD und RAM? ... gar nix??

    0
  • F

    Tachyon schrieb:

    Fellhuhn schrieb:

    Tachyon schrieb:

    Fellhuhn schrieb:

    Nimm vier Platten im RAID-0-Verbund und du hast damit keine Probleme mehr. 😉

    Es sei denn, eine Platte geht kaputt...

    Who cares? Das Problem hast auch bei nur einer Platte. Oder einer SSD. Backups sind immer sinnig. 😉

    Naja, das Risiko vervierfacht sich...

    Was aber ja nicht heißt das viermal so schnell ein Fehler auftritt. Wenn man dann aber die Arbeit in einem Viertel der Zeit schafft ist das schon lohnenswert. 🙂
    Und noch ärgerlicher ist es mit nur einer Platte langsam zu arbeiten und trotzdem seine Daten zu verlieren. 😉

    Sonst halt RAID-5. Nicht ganz so fix aber sicherer.

    0
  • J

    Festplattenzugriffe sind nunmal langsam, diese solltest du so weit wie möglich vermeiden. Die einzige Möglichkeit es etwas zu beschleunigen ist größere Blöcke gleichzeitig zu lesen, anstatt z.B. Zeichen für Zeichen einzulesen. Aber auch das hilft nur wenig.

    0

  • Ohne Garantie:
    Du könntest ja mal einen Test bauen, der per CreateFileMapping/ViewMapOfFile den Dateiinhalt direkt in den Speicher einblendet und die Daten von dort abholt. Vielleicht bringt das ein wenig Performance.

    0
  • B

    Du könntest zuerst die Dateien am Stück in 4 Strings einlesen. Dann rennen 4 Threads durch die Strings und füllen jeweils eine eigene std::list.
    Wenn die Threads fertig sind, werden die lists zusammengefügt.

    global_list.splice(global_list.end(), thread1.list);
global_list.splice(global_list.end(), thread2.list);
...
    0
  • G

    Ok vielen Dank!

    Die Idee mit dem am stück einlesen klingt verlockend.
    Was ist die schnellste Variante um mit C++ eine ASCII Datei in den RAM zu schieben?

    0
  • B

    Vielleicht gibts schnellere Speziallösungen, aber ich mach das in etwa so

    std::string read_file(const char * file)
{
	std::ifstream ifs(file);
	if (ifs.good())
	{
		ifs.seekg (0, std::ios::end);
		size_t length = ifs.tellg();
		ifs.seekg (0, std::ios::beg);

		std::vector<char> buffer(length+1);
		ifs.read (&buffer[0], length);
		buffer[length] = 0;
		return &buffer[0];
	}
	throw std::runtime_error("file ist doof");
}
    0

  • Ich denke schon, dass die Win32 API da mit den Filemappings schneller sein könnte, weil sie näher am System arbeiten als die C++ Streams. Ist aber, wie gesagt, reine Vermutung.

    0
  • A

    DocShoe schrieb:

    Ich denke schon, dass die Win32 API da mit den Filemappings schneller sein könnte, weil sie näher am System arbeiten als die C++ Streams.

    Zumindest vor einigen Jahren war das auch definitiv so (Und nicht nur um wenige Prozentpunkte).

    0
  • B

    Gilt das auch für ein einmaliges Einlesen? Ich benutze in einem Projekt gemappte Files (aus boost::interprocess), um in einer riesigen Datei viel drin rumzulesen, das ist tatsächlich sehr schnell. Aber nur um die Datei einmal einzulesen?

    0
  • A

    brotbernd schrieb:

    Gilt das auch für ein einmaliges Einlesen?...

    Ich hatte es vor einigen Jahren vor allem für das einmalige Einlesen und analysieren benötigt (und gleichzeitig durfte der Speicherverbrauch nicht massiv ansteigen).

    0
  • V

    Ich habe heuer auf einem Kern es ausgemessen mit 8 threads und scattered io, file mapping, std und einfacher WinApi und die Unterschiede waren auch nur im Bereich eines Prozents.
    Für Einlesen-Und-Vergessen, also Streams, zum Beispiel CRC berechnen, nehme ich einfache WinApi, wenn die Daten ins Ram sollen, um Rumspringen zu können, nehme ich file mapping.

    0
Anmelden zum Antworten