Zufallsarray erzeugen

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Hallo,

ich hab einen Testcode,der meine Streams testen soll. Dabei habe ich festgestellt, dass die Streams selber nur 15ms brauchen, aber die Erzeugung der Testdateien immer 16 Sekunden (in Summe) benötigt

.

Weiß einer von euch, wie ich das optimieren kann?

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:

  procedure WriteNewTestBlock;
  var
    j: integer;
  begin
    for j := TestFileSize-1 downto 0 do BigBuf[j]:=random(256);
    for j := TestFileSize div i downto 0 do
    begin
      case random(3) of
        0: BigBuf[j*i]:=13;
        1: BigBuf[j*i]:=10;
        else
        begin
          BigBuf[j*i]:=13;
          BigBuf[j*i]:=10;
        end;
      end;
    end;
    FSW:=TFileStreamW.Create('Test.txt', fmCreate);
    FSW.Write(BigBuf[1], TestFileSize);
    FSW.Free;
  end;

  for i:=10 to 609 do
  begin
    WriteNewTestBlock;
    ...

Marc. · Verfasst: Di 03.06.08 19:45

markieren

Delphi-Quelltext

1:
2:
3:
4:

        begin
          BigBuf[j*i]:=13;
          BigBuf[j*i]:=10;
        end;

Was soll das bringen? Du setzt den Wert erst auf 13 und anschließend auf 10, oder habe ich da irgendetwas völlig übersehen?

Warum überhaupt ein End-Else-Block? Es reicht vermutlich auch, wenn du die Instanz FSW nur einmal zu Beginn erzeugst und am Ende freigibst.

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Hallo Marc,

der Fehler ist mir noch gar nicht aufgefallen (Copy & Pastefehler). Beim zweiten fehlt ein +1. Der Code soll eben die 3 verschiedenen Zeilenumbrüche "willkürlich" verteile: also #13 (Mac), #13#10 (Win) und #10 (Unix).

Horst_H · Verfasst: Mi 04.06.08 11:07

Hallo,

was mich wundert, das Du einzelne #13, #10 überhaupt erzeugst. Die müßten doch mittels der Zufallszahlen schon vorkommen. Wie groß ist den die Textdatei. Kann es sein, das Random bremst, vielleicht dort mit word,3-byte Werten arbeiten? Du erzeugst ja 600 mal diese Datei.

Gruß Horst

arj · Verfasst: Mi 04.06.08 11:26

Was mich noch wundert ist warum du Zeilenumbrüche reinmachst.
Du erzeugst ja eine Binärdatei welche auch nicht-ascii Charaktere
enthält?!?

alzaimar · Verfasst: Mi 04.06.08 11:37

Was ist eigentlich 'i' ?

Wie wäre es so:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

i := 0;
While i<maxbuffersize-1 do begin
  case random(80) of
    0 : buf[i] := 10;
    1 : buf[i] := 13;
    2 : begin
      buf[i] := 13;
      inc(i);
      buf[i] := 10;
      end;
    else buf[i] := Random(256); // ist zwar nicht so wichtig, aber vielleicht ohne 13 und 10....
  end;
  inc(i);
End;

Das sollte rein statistisch im Mittel alle 77 Zeichen ein CR/LF oder CRLF einfügen.

Ach, und runterzählen musst du nicht. Das macht der Compiler automatisch, wenn es geht. So ist es imho unübersichtlich.

_________________
Na denn, dann. Bis dann, denn.

Horst_H · Verfasst: Mi 04.06.08 12:05

Hallo,

i ist global.( hätte man auch übergeben können )

Zitat:

for i:=10 to 609 do
begin
WriteNewTestBlock;
...

Zudem wird i als Abstand für ein Zeilenende( die drei Varianten ) genutzt.
Aber das macht es nicht langsam.
Wir glaskugeln hier herum.

Gruß Horst

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Ich habe mal die ganzen Probleme, die hier angesprochen wurden, rausgenommen

.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:

{$APPTYPE CONSOLE}

const
  TestFileSize = 1048576;

var
  FT : Textfile;
  FH : file of Byte;
  FS : TFileStream;
  FSW: TFileStreamW;

  MS : TMemoryStream;
  MSW: TMemoryStreamW;

  BigBuf: array of Byte;
  Buf: array[1..2] of Byte;
  t, t1, t2, t3: Cardinal;

procedure readLnTest;
var
  i: integer;
  StrBuf: String;

  procedure WriteNewTestBlock;
  var
    j: integer;
  begin
    for j := TestFileSize-1 downto 0 do BigBuf[j]:=random(224)+32;
    for j := TestFileSize div i downto 0 do
    begin
      case random(3) of
        0: BigBuf[j*i]:=13;
        1: BigBuf[j*i]:=10;
        else
        begin
          BigBuf[j*i]:=13;
          BigBuf[j*i+1]:=10;
        end;
      end;
    end;
    FSW:=TFileStreamW.Create('Test.txt', fmCreate);
    FSW.Write(BigBuf[1], TestFileSize);
    FSW.Free;
  end;
  
begin
  WriteLn('== Start: ReadLn speed test ==');
  SetLength(BigBuf, TestFileSize);
  t1:=0;
  t2:=0;
  for i:=10 to 609 do
  begin
    WriteNewTestBlock;
    AssignFile(FT, 'Test.txt');
    Reset(FT);
    t:=GetTickCount;
    while not eof(FT) do readln(FT, StrBuf);
    inc(t1, GetTickCount-t);
    CloseFile(FT);

    WriteNewTestBlock;
    FSW:=TFileStreamW.Create('Test.txt', fmCreate);
    t:=GetTickCount;
    while FSW.Position<>FSW.Size do FSW.ReadLn(StrBuf);
    inc(t2, GetTickCount-t);
    FSW.Free;
  end;
  WriteLn('ReadLn:');
  WriteLn(' AssignFile    '+IntToStr(t1)+' ms');
  WriteLn(' TFileStreamW  '+IntToStr(t2)+' ms');
  SetLength(BigBuf, 0);
  WriteLn;
end;

Das dürfte jetzt mehr klarheit verschaffen.

Horst_H · Verfasst: Mi 04.06.08 13:35

Hallo,

eher doch so:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:

{$APPTYPE CONSOLE}
uses
  classes,sysutils,windows,
  uniCodeFileStream in 'UniCodeFileStream.pas';// http://www.delphi-forum.de/viewtopic.php?p=501098
const
  TestFileSize = 1048576;


var
  FT : Textfile;
  FH : file of Byte;
  FS : TFileStream;
  FSW: TFileStreamW;


  MS : TMemoryStream;
  MSW: TMemoryStreamW;


  BigBuf: array of Byte;
  Buf: array[1..2] of Byte;
  t, t1, t2, t3,tg0,tg1: Cardinal;


procedure readLnTest;
var
  i: integer;
  StrBuf: String;


  procedure WriteNewTestBlock;
  var
    j: integer;
  begin
    for j := TestFileSize-1 downto 0 do
      BigBuf[j]:=random(224)+32;
    for j := TestFileSize div i downto 1 do
    begin
      case random(3) of
        0: BigBuf[j*i]:=13;
        1: BigBuf[j*i]:=10;
        else
        begin
          BigBuf[j*i]:=13;
          BigBuf[j*i+1]:=10;
        end;
      end;
    end;
    FSW:=TFileStreamW.Create('Test.txt', fmCreate);
    FSW.Write(BigBuf[1], TestFileSize);
    FSW.Free;
  end;

begin
  WriteLn('== Start: ReadLn speed test ==');
  SetLength(BigBuf, TestFileSize);
  t1:=0;
  t2:=0;
  tg0:=GetTickCount;
  for i:=10 to 100 do
  begin
    WriteNewTestBlock;

    AssignFile(FT, 'Test.txt');
    Reset(FT);
    t:=GetTickCount;
    while not eof(FT) do
      readln(FT, StrBuf);
    inc(t1, GetTickCount-t);
    CloseFile(FT);


//    WriteNewTestBlock; Damit beide die gleiche Datei nutzen
    FSW:=TFileStreamW.Create('Test.txt', fmOpenRead);
    t:=GetTickCount;
    while FSW.Position<>FSW.Size do
      FSW.ReadLn(StrBuf);
    inc(t2, GetTickCount-t);
    FSW.Free;
  end;
  tg1:=GetTickCount;

  WriteLn('ReadLn:');
  WriteLn(' AssignFile    '+IntToStr(t1)+' ms');
  WriteLn(' TFileStreamW  '+IntToStr(t2)+' ms');
  WriteLn(' Gesamtzeit    '+IntToStr(tg1-tg0)+' ms');
  SetLength(BigBuf, 0);
end;
begin
  readLnTest;
  readln;
end.

Ausgabe freepascal für i von 10..100:

markieren

Quelltext

1:
2:
3:
4:
5:

== Start: ReadLn speed test ==
ReadLn:
 AssignFile    1561 ms
 TFileStreamW  20299 ms
 Gesamtzeit    36473 ms

Delphi 2006 ist AssignFile 1600 ms TfileStream 19890 ms da tut sich nichts.
Eigentlich sollte man mal testen, ob jeder gleichviele Zeilen liest.
Gruß Horst

Oh ich Narr, das Schreiben mittels Deines streams ist doch so elend langsam...
Wenn 20 Sek für's zeilenweise Einlesen gebraucht werden, sind 10 Sekunden fürs wegschreiben wohl nicht zuviel.
Ich habe das wegschreiben auskommentiert:

markieren

Delphi-Quelltext

1:
2:
3:

    FSW:=TFileStreamW.Create('Test.txt', fmCreate);
    FSW.Write(BigBuf[1], TestFileSize);
    FSW.Free;

markieren

Quelltext

1:
2:
3:
4:
5:

== Start: ReadLn speed test ==
ReadLn:
 AssignFile    1170 ms
 TFileStreamW  8296 ms
 Gesamtzeit    16444 ms

Also 90 Mbyte random erzeugen in etwas mehr als 6 Sekunden

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Hallo Horst,

die Optimierung von WriteNewTestBlock geht leider nicht - Festplattencache... .

PS: Haste ja glück, dass die alte Version mit der neuen an der Stelle kompatibel ist

.
PSS: Der Test hier ist nur dazu da, um die Geschwindigkeitsunterschiede zwischen der alten und neuen, ASM-optimierten, Version zu ermitteln

.

Horst_H · Verfasst: Mi 04.06.08 19:31

Hallo,

die neu geschriebene Datei ist doch schon im Festplattencache, wo liegt denn jetzt der Unterschied mit jeweils neu erstellen, außer dass man nicht kontrollieren kann, wieviel Zeilenumbrüche die jeweilige Leseart erkennt.

Mir ging es nur darum, zu zeigen, das Dein Erstellen der Datei selbst auch eine Bremse ist und nicht nur die Zufallszahlen.
Zeit zum erzeugen ohne Wegschreiben ~ 9 Sekunden.
Zeit zum erzeugen mit Wegschreiben ~ 14,7 Sekunden.

Anbei eine Version, die bei mir zum Erzeugen und Wegschreiben 3,7 Sekunden braucht, indem einmal random für 4 Byte genutzt wird. Natürlich mit Einschränkung des Wertebereiches statt 224 eben 215 verschiendene Werte.

markieren

Quelltext

1:
2:
3:
4:
5:
6:

== Start: ReadLn speed test ==
ReadLn:
 AssignFile    1431 ms
 TFileStreamW  20086 ms
 Gesamtzeit    25177 ms
 Randomzeit    3660 ms

Übrigens wird in Freepascal div Faktor (=215) durch Multplikation und shift erzeugt

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

# [43] rz := rz div Faktor;
  movl  %edi,%ecx
  # Register eax allocated
  movl  $1278501893,%eax
  # Register edx allocated
  imull  %ecx
  sarl  $6,%edx
  shrl  $31,%ecx
  addl  %ecx,%edx

Gruß Horst
P.S.:
Dir ist doch klar das man alles mit #32 vollschreiben hätte (fillchar ) können und dann nur die Zeilenumbrüche reinkopiert, also gänzlich auf random verzichten kann

Einloggen, um Attachments anzusehen!

Horst_H · Verfasst: Fr 06.06.08 10:33

Hallo,

@Heiko:Mir ist doch etwas aufgefallen:

Zitat:

ich hab einen Testcode,der meine Streams testen soll. Dabei habe ich festgestellt, dass die Streams selber nur 15ms brauchen

Du glaubst selber nicht, das dein Computer 600 x 1 Mbyte in 15 ms~ 1/60 s einliest (36 Gbyte/s), geschweige denn verarbeitet.
Das ist doch illusorisch.
Mein Rechner schaufelt die Daten mit ca. 650 Mb/s aus dem Festplatten-Cache von WinXp. Da bin ich schon bei fast einer Sekunde.
Also ist das höchstens eine Zeit für die Verarbeitung einer 1 Mb Datei.

Gruß Horst

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Hallo Horst,

da war noch ein Fehle im Testcode drin. Durch fmCreate wurde die Datei ja auf 0Bytes reduziert. Da ist er dann natürlich dem entsprechend schnell

.

Horst_H · Verfasst: Fr 06.06.08 12:34

Hallo,

in der angehängten StreamTest.dpr ist ja auch fmOpenRead benutzt

Gruß Horst

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Hallo Horst,

ich weiß. Ich nutze die nur nicht, da die TestSuite in Wirklichkeit größer ist (sind nicht nur die 80 Zeilen, sondern momentan bin ich schon bei 200)

. Nachdem du festgestellt hast, dass meine Unit langsamer ist, bin ich erst auf den Fehler aufmerksam geworden. Da es bei mir immer andersherum war

.

Gruß
SunBlack

€: rdtsc ist imho hier übertreien. Die Festplatte ist ne größere Unsicerheit als die Zeitmessung (parallel Festplattenzugriffe von Windows etc. [WMP etc. schalte ich schon bei der Messung ab, aber einige Proggis greifen trotzdem auf die Platte zu

])

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

Was willst du damit jetzt eigentlich testen? Die Verarbeitung eines Streams oder die Geschwindigkeit deiner Festplatte? Denn Festplattenzugriffe in einem Geschwindigkeitstest sind immer relativ außer es handelt sich um einen Festplattenbenchmark. Nicht jede Platte ist gleich. Ich sagen 5000, 7200 und 10.000 Umdrehungen Pro Minute. PC oder Laptop. Cache 2mb, 4mb oder 8mb. Außerdem spielt es noch eine Rolle ob die Festplatte fragmentiert ist und Windows beim Schreiben der Datei immer wieder neu ansetzen muss. Und ich weiß jetzt selber nicht so genau ob es auch noch eine Rolle spielt ob du in einem Innenkreis der Festplatte die Datei schreibst oder am äußeren Rand. Bei CDs macht es einen riesen unterschied. Aber dabei gibt es nur eine Spur und die Fetsplatte ist glaube ich in blöcken unterteilt. Aber trotzdem sollte innen weniger hinpassen als außen. So gut kenn ich mich mit Festplatten aber nicht aus. Deswegen stellt sich mir die Frage, ob dieser Test überhaupt eine Aussagekraft besitzt oder nicht.

Um die Verarbeitungsgeschwindigkeit deiner Methode zu testen solltest du so gut es geht auf alle Hardware verzichten. Also kommt eigentlich nur Speicher zu Speicher in Frage. Auch da gibt es genügend Abweichungen.

Wobei im letzten Schritt natürlich noch der Test mit Festplatten ansteht. Das steht völlig außer Frage. Denn dort genügt eine ungünstige Konstelation und schon wird man ausgebremmst. Habe ich beim Einlesen von komprimierten TGAs selber gut gemerkt. Dort muss Pixelweise eingelesen werden und das war richtig langsam. Kaum, dass ich einen 4K Cache dazwischen geklemmt hatte war es um ein vielfaches schneller. Warum? Weil die Platte so nicht viele kleine Leseoperationen hatte sondern Blockweise und das macht sie in einem Rutsch wärend sie sonst immer warten muss bis sie sich passend gedreht hat. Was bei vielen Operationen zu einer großen Menge Zeit ansammelt.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Hallo Lossy. Ein Festplatenbenchmark soll es nicht werden. Nur will ich eben die Performanceunterschiede zw. AssignFile und meinen eigenen Stream feststellen. Bei den normalen Operationen sind alle Streams ungefähr gleichschnell (+- 1000ms, bei 10 Sekundentests). Mir geht es momentan um die Optimierung des ReadLn-Befehls. Da AssignFile aber leider nur für die Festplatte zur Verfügung steht (der MemoryStream von Borland kann es ja leider nicht), muss ich es leider auf der Festplatte austesten

.

@pixelweise: japp - wobei die WinAPI schon selber puffert - also ein Warten auf den Lesekopf eher selten vorkommen sollte (allerdings scheint der WinBuffer nicht so effizient dahingehend zu sein). Und eigentlich greift auch der Festplattencache - den die Platte liest imho immer ganze Blöcke, die dann im Cache landen - weil es eben viele programmierer gibt, die nicht in großen Blöcken einlesen

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

AssignFile vs. TStream: Okay. Wenn du genau den Unterschied testen willst, dann bleibt dir nichts anderes übrig. Wobei TStream aber auf einem Windowsdateihandel arbeiten und entsprechend alles über die Windowsapi erledigt werden muss. Wärend AssignFile mit direkter Ein und Ausgabe arbeitet. Deswegen hast du auch noch folgende Unterschiede

- AssignFile arbeitet gepuffert. WindowsFileHandle meines wissens nicht. Bzw nicht in dem Umfang. Wenn man etwas eingelesen hat ja aber nichts vorrauslesendes. So mein Eindruck. Speziell, wenn du Byteweise einliest denke ich wird es irgendwo zeit kosten. Und der Cache in der Platte. Darauf muss erst mal zugegriffen werden und der ist weit weit weg.

- ReadLN etc sind Methoden in Assembler. Die Paramater werden in den Registern übergeben, weswegen alleine der bloße Aufruf der Windows API Funktion ReadFile langsamer ist, da die Parameter über den Stack gegeben werden müssen. Wer weiß was in der API noch alles passiert. Das File/Textfile bei AssignFile ist ein Pointer auf ein Record. Ich meine das Handle nicht. Also muss ReadFile erst mal das passende Record ausgraben. Bei Assign entfällt also vermutlich suchaufwand. Wobei ich aber denke, dass dieser Punkt eher nicht so den Ausschlag geben wird.

Aber so recht weiß ich nicht ob der Vergleich für dich überhaupt entsprechend fair ist. Wobei ich persönlich sogar recht stark davon überzeugt bin, dass alleine ein eigener Cache einiges ändern wird. Eben weil ich selber so was schon mal hatte. Als kleiner Anreiz. Mit cache ca 6.5 ms und ohne 86ms. Beides male war die Datei im Windowscache. Wobei du bei dir einen solchen Cache aus etwas inteligent machen musst! Wenn jemand einen Block lesen will, dann sollte das nicht über den Cache gehen und dann auch nichts vorrausschauenendes gelesen werden.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

Heiko · Beiträge: 3169 Erhaltene Danke: 11

Lossy eX hat folgendes geschrieben:

AssignFile vs. TStream: Okay. Wenn du genau den Unterschied testen willst, dann bleibt dir nichts anderes übrig. Wobei TStream aber auf einem Windowsdateihandel arbeiten und entsprechend alles über die Windowsapi erledigt werden muss. Wärend AssignFile mit direkter Ein und Ausgabe arbeitet. Deswegen hast du auch noch folgende Unterschiede

Nö: Ich habe mal AssignFile debugt (CPU). AssignFile ist nix anderes Nicht-OOP-Filestream (nutzt die gleichen Befehle). Ich muss nur noch gucken, wie groß der Puffer ist, den er für ReadLn nutzt - denn wenn nicht kann ich evtl. die fertige Funktion nutzen

.

Lossy eX hat folgendes geschrieben:

- AssignFile arbeitet gepuffert. WindowsFileHandle meines wissens nicht. Bzw nicht in dem Umfang. Wenn man etwas eingelesen hat ja aber nichts vorrauslesendes. So mein Eindruck. Speziell, wenn du Byteweise einliest denke ich wird es irgendwo zeit kosten. Und der Cache in der Platte. Darauf muss erst mal zugegriffen werden und der ist weit weit weg.

IMHO nicht. Wie bereits geschrieben - siehe CPU. @Puffer: Lies hier die Remarks

.

Lossy eX hat folgendes geschrieben:

- ReadLN etc sind Methoden in Assembler. Die Paramater werden in den Registern übergeben, weswegen alleine der bloße Aufruf der Windows API Funktion ReadFile langsamer ist, da die Parameter über den Stack gegeben werden müssen. Wer weiß was in der API noch alles passiert. Das File/Textfile bei AssignFile ist ein Pointer auf ein Record. Ich meine das Handle nicht. Also muss ReadFile erst mal das passende Record ausgraben. Bei Assign entfällt also vermutlich suchaufwand. Wobei ich aber denke, dass dieser Punkt eher nicht so den Ausschlag geben wird.

Für ReadLn habe ich noch keine WinAPI gefunden

. Nur für Read, wo AssignFile den gleichen Weg geht (des wegen haben auch alle 3 die gleiche Geschwindigkeit).

Lossy eX hat folgendes geschrieben:

Aber so recht weiß ich nicht ob der Vergleich für dich überhaupt entsprechend fair ist. Wobei ich persönlich sogar recht stark davon überzeugt bin, dass alleine ein eigener Cache einiges ändern wird. Eben weil ich selber so was schon mal hatte. Als kleiner Anreiz. Mit cache ca 6.5 ms und ohne 86ms. Beides male war die Datei im Windowscache. Wobei du bei dir einen solchen Cache aus etwas inteligent machen musst! Wenn jemand einen Block lesen will, dann sollte das nicht über den Cache gehen und dann auch nichts vorrausschauenendes gelesen werden.

Dazu gibt es MemoryStreams. Ich habe aber schon überlegt, noch einen Stream mit Puffer zu basteln (das Risiko steigt da aber, das bei einem Absturz z.B. die Log-Datei noch nicht geschrieben wurde).

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme