Datei kopieren ohne CPU auslastung

[cracker0dks]

Hi
geht nochmal um das Kopier programm... ich kopier nicht mit der Copy() (oder wie die heißt) sondern ich les meine Datein in einen Puffer ein und Schreib die Datei neu...

*auszug*

fh_out = fopen( zieldat.c_str(), "wb" );
fseek( fh_in, 0, SEEK_END );
filesize = ftell(fh_in);
fseek( fh_in, 0, SEEK_SET );
while( fread( Chunk, chunksize, 1, fh_in ) )
{
if( bytesread > filesize -chunksize )
chunksize = filesize - bytesread;
bytesread += chunksize;
fwrite( Chunk, chunksize, 1, fh_out );
}

*auszug*

Dadurch wird aber die CPU bis zu 60% stänig (wärend des kopiervorgans) ausgelastet...

Kann ich das irgendwie reduzieren ?

Danke Cracker0dks

[Christian Marquardt]

Stärkere CPU kaufen oder mehr als 1 Byte lesen und schreiben

[mez]

man kann den threads doch auch irgendwie mitgeben, welche priorität die haben sollen, mein ich mich zu erinnern. damit würde man zwar die cpu-auslastung nicht veringern, aber zumindest wären andere prozesse und threads berechtigt, dem thread einfach ressourcen zu entziehen.

[Manfred Pawelzik]

Im Konstruktor kannst du die Prio angeben.
Z.b.

Priority = tpLower;


tpIdle
Der Thread wird nur dann ausgeführt, wenn sich das System im Leerlauf befindet. Für einen Thread mit der Prioritätsstufe tpIdle unterbricht das System keine anderen Threads.

tpLowest
Die Priorität des Threads liegt zwei Stufen unter der normalen Ebene.

tpLower Die Priorität des Threads liegt eine Stufe unter der normalen Ebene.
tpNormal Der Thread besitzt normale Priorität.
tpHigher Die Priorität des Threads liegt eine Stufe über der normalen Ebene.
tpHighest Die Priorität des Threads liegt zwei Stufen über der normalen Ebene.
tpTimeCritical Der Thread besitzt höchste Priorität.

[Christian Marquardt]

Schön und gut mit dem Thread, was ja nicht wirklich das Problem ist. Die benötigte Leistung wird benötigt, egal ob im Hauptprogramm oder in einem Thread. Der Thread würde mit einer Priorisierung lediglich die Last verrringern. Ggf. wäre dann die Frage warum das Kopieren so lange dauert (Extremfall)

a) benötigt kopieren nun mal Systemleistung
b) wenn man nur 1 Bytes liest und schreibt benötigt man halt mehr Systemleistung. Ständige Lese- und Schreibzugriffe

Erstmal wäre hier anzusetzen

Ggf. geht man noch ganz anders ran und verteilt das Kopieren auf mehrere Threads.

Thread 1 kopiert die Bytes von 0-1000
Thread 2 kopiert die Bytes von 1001 - 2000
.....

[mez]

aber wäre dann nicht das problem, die datei wieder in der richtigen ordnung zusammen zu setzen?? schließlich kann man nicht beeinflussen, welchem thread gerade die systemressourcen zugeteilt wurden. könnt mir vorstellen, dass dann ein wildes durcheinander der daten entsteht.

[Christian Marquardt]

Wieso?

Wenn Thread 1 nur von 0-1000 schreibt, kommt doch ein anderer Thread der von 1001-2000 schreibt ,nicht in Gehege

[mez]

wenn die nacheinander arbeiten nicht. aber dann wäre das ja nur in dem sinne gelöst, dass das kopieren quasi unterbrochen wird, so dass andere prozesse für ne bestimmte zeit die ressourcen beanspruchen können zwischendrin.

wenn beide prozesse gleichzeitig arbeiten, gibts ein durcheinander.

[Christian Marquardt]

wenn beide prozesse gleichzeitig arbeiten, gibts ein durcheinander.

Aha, dass muss man aber nicht verstehen, oder?

Wenn du einen Zollstock hast und setzt nun zwei Leute ran, die sollen auf jeden Zentimeter einen Kieselstein legen. Der Erste von 0-1, der Zweite von 1-2. (Die Kieselsteine stammen von einem anderen Zollstock und sind in der gleichen Reihenfolge auf den aktuellen zu legen)

Wo sollte es ein Durcheinander geben?
Egal wann oder wie schnell oder langsam einer arbeitet

[mez]

ok, wenn man auch im ziel festlegt, dass der erste thread die ersten 1000 bytes füllt und der zweite die nächsten 1000 bytes etc. ok, dann könnt das klappen.

[Christian Marquardt]

ok, wenn man auch im ziel festlegt, dass der erste thread die ersten 1000 bytes füllt und der zweite die nächsten 1000 bytes etc. ok, dann könnt das klappen.

Was stand anderes seit Beitrag 5 zur Debatte?? Anderes würde nicht viel Sinn ergeben.

[hwoess]

Würde mich jetzt aber stark interessieren, ob es was bringt, zB bei einem 400 Mb großen File 4 Threads anzulegen, die jeweils 100 Mb kopieren. Wir haben dann ja den Overhead der Threadverwaltung und wahrscheinlich auch mehr Kopfbewegungen der Festplatte, die ja immer wieder neu positionieren muss.
Was ich mir als leistungssteigernd vorstellen könnte, wäre es mit einem Lese-Thread und einem Schreib-Thread zu arbeiten, wenn man von einer Platte auf eine andere kopiert, damit das Lesen des nächsten Blocks nicht warten muss bis der vorige Block fertiggeschrieben ist, sondern parallel neue Daten gelesen werden während alte Daten geschrieben werden.
Hoffe, mez hält uns über seine Ergebnisse am Laufenden

bye,
Helmut

Habe ich gerade noch gefunden, auch ein wichtiger Faktor - die Blocksize. Da sieht man, wie diese Größe sowohl Geschwindigkeit als auch CPU-Last stark beeinflusst (erklärt auch die hohe CPU-Last bei byteweisem Kopieren). So wie es aussieht, wären 8192 Byte die optimale Größe, bei der man minimalste CPU-Last bei fast optimaler Geschwindigkeit hat:
Artikel hier

bye,
Helmut

[Christian Marquardt]

Moderne Platten optimieren die Schreib- und Leseoperationen

und mit der Blocksize...nun das schreibe ich seit dem 2. Beitrag, dass das Lesen von 1 Byte inperformant ist.....

[Hans G]

und mit der Blocksize...nun das schreibe ich seit dem 2. Beitrag, dass das Lesen von 1 Byte inperformant ist.....

Wo wirdt hier dann mit 1 Byte gelesen?

[Hans G]

So wie es aussieht, wären 8192 Byte die optimale Größe, bei der man minimalste CPU-Last bei fast optimaler Geschwindigkeit hat:

Das kann ik nicht bejahen.

Mann nehme besser grössere puffer.

Bei 8192 nimt dass hier für eine 50 MB file 14 secunden. Bei eine chunksize von 1000000 nur 2,5 sec.

Aber womit macht der OP es?

Uebrigens is die "*auszug* hoffentlich nur ein auszug denn sie copiert nicht dass letzte stuck der datei