Meine Frage dreht sich um folgendes Problem:
Ich entwickle zur Zeit eine Software mit C++ welche zu Programmstart eine große Datenmenge aus mehreren Files einlesen soll.

-----------------------------------
Hardware Konfiguration:
-----------------------------------
Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz 2.66GHz (Quad Core)
4,00 GB DDR3
Win7 x64
-----------------------------------

Da ich, dank 4 CPU's, mehrere Files parallel einlesen möchte habe ich bei der Software Multithreading eingesetzt. Jetzt ergibt sich folgendes Phänomen beim Einlesen 3 gleicher Files.

SingleThread(seriell): spricht nur 1 CPU an --> 25% CPU Auslastung
--> Programm benötigt 10s/File --> 30s insgesamt
Multithread(parallel): spricht 3 CPU's an (da 1 Thread/File) --> 75% Auslastung
--> Programm benötigt 30s/File --> 30s insgesamt

Meine Frage daher: Warum benötigt der Computer bei einer CPU Auslastung von 75% genauso lange wie bei einer Auslastung von 25%?

Wo kann der Flaschenhals liegen? HardDisk, RAM (wird durch die Files nicht voll ausgelastet), ..... ???

Vielen Dank,
lg,
Andreas

Meine Threads erstelle ich mit

hThread[i] = CreateThread( NULL, 
							  0, 
							  mbsmVtrImporter::vtrToMbsmField_threadEntry, 
							  (LPVOID)i, 
							  0, 
							  &dwThreadID[i] 
							 );

Und für globale Ressourcen verwende ich Mutex nach dem Schema:

HANDLE pathMutex= CreateMutex(NULL,
				FALSE,	
				"PathMutex");
// vor Zugriff auf Resource
static void lockFile()
{
	WaitForSingleObject(pathMutex, INFINITE);
}
// nach Zugriff auf Resource
static void unlockFile()
{
         ReleaseMutex(pathMutex);
}

In der selben Anwendung gibt es einen zweiten Moment in dem die Threads ihre Daten in eine globale std::list speichern. Jeder Thread macht also einfach ein list->push_back(meineDaten).
Ist hier ein lock der list sinnvoll oder auch unnötig?

---> Gibt es eine Möglichkeit die Disk zu beschleunigen/auszutricksen? ...

Ok guter Punkt .. daher bei reinem Lesezugriff muss man globale Resourcen nicht locken (kann man das allgemein so sagen?)

Ja. Die Daten können zwischendurch ja nicht geändert werden. Das locken ist nur notwendig, um sicherzugehen das die Daten zwischendurch nicht von jemand anderes geändert werden. Beachte, dies gilt nur wenn nirgendwo anders nebenbei die Daten beschrieben werden.

GreedyRaccoon schrieb:

In der selben Anwendung gibt es einen zweiten Moment in dem die Threads ihre Daten in eine globale std::list speichern. Jeder Thread macht also einfach ein list->push_back(meineDaten).
Ist hier ein lock der list sinnvoll oder auch unnötig?

Absolut! Geschieht auch nur _irgendwo_ nebenbei ein Schreibzugriff, so muss jeglicher Schreibb- und Lesezugriff synchronisiert werden mittels Locks. std::list ist nicht von sich aus Threadsicher.

GreedyRaccoon schrieb:

---> Gibt es eine Möglichkeit die Disk zu beschleunigen/auszutricksen? ...

Kauf dir ne SSD.

Typ und Anschluss Festplatte - SATA II
Speicherkapazität / Cache 500.0 GB / 16 MB
Geschwindigkeit 7200 rpm

Was wäre eine Platte welche den QuadCores genüge tun würde? (so, dass diese wieder zum Flaschenhals werden?)

Was wäre eine Platte welche den QuadCores genüge tun würde? (so, dass diese wieder zum Flaschenhals werden?)

Gar kein, selbst ein 1GHz-Prozessor wird deutlich schneller sein als ne SSD-Platte.

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

Es sei denn, eine Platte geht kaputt...

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.

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...

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

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.

global_list.splice(global_list.end(), thread1.list);
global_list.splice(global_list.end(), thread2.list);
...

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?

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");
}

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).

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).