FPC frisst überlange Konstante nicht

[Mathias]

Für einen Versuch, habe ich eine sehr grosse Konstante mit 8.7MB generiert.

Code: Alles auswählen

program project1;
{$i buffer.inc}

begin
  WriteLn(MyBuffer);
end.       

Code: Alles auswählen

const MyBuffer : PChar =
  '1: 8667337 6657247 9989023 8666694 5356299 3086797 1983360 7283568 198799'#10 +
  '2: 3733523 0163628 2024979 3399135 7401421 2038737 7839880 8783239 251237'#10 +
 ......
  '99999: 9801814 9298929 0894958 0292101 6679204 9447630 2950644 7967425 002018'#10 +
  '100000: 8128275 3971393 6448130 8459206 8757951 4880245 0596409 6346621 995270'#10 +
  ' ';

Nur wird mir dies mit folgenden Fehler quittiert, wen ich es kompilieren will.

Code: Alles auswählen

Error: /home/tux/fpcupdeluxe_trunk/fpc/bin/x86_64-linux/ppcx64 can't be executed, error message: Failed to execute "/home/tux/fpcupdeluxe_trunk/fpc/bin/x86_64-linux/ppcx64", error code: -139

Probiert mit Lazarus 3.99 / FPC 3.3.1, ( Linux 64bit ), welches ich vor einer Woche gebaut habe.

Ist dies ein Bug, oder ist dies so gewollt ?

Das ganze habe ich auch in einem C-Programm probiert, dort wird es problemlos gefressen.

[Nixsager]

Das Scheint dann ein Fehler unter der Linux-Version zu sein.
Unter Win10 wird es kompiliert und in der Konsole wird mir die Konstante ausgegeben.

P.S.
Sind das spezielle Daten?

Nachtrag:
Die Linux-Version wird unter Win10 auch kompiliert, nur kann ich es leider nicht testen.

P.S.
Interessanter Benchmark. Wenn ich die Konsolenausgaben in eine Datei umleite, ist das Programm innerhalb einer Sekunde fertig, die Ausgabe in der Konsole dauert wesentlich länger.

[Mathias]

P.S.
Sind das spezielle Daten?

Nein, ich mache native Versuche mit dem Clipboard von Linux, die Konstante dient nur dazu, um etwas grosses durchs Clipboard zu jagen.

Nachtrag:
Die Linux-Version wird unter Win10 auch kompiliert, nur kann ich es leider nicht testen.

Deine bin läuft. Somit muss es ein Bug im Linux-Compiler sein.

P.S.
Interessanter Benchmark. Wenn ich die Konsolenausgaben in eine Datei umleite, ist das Programm innerhalb einer Sekunde fertig, die Ausgabe in der Konsole dauert wesentlich länger.

Die kann ich nachvollziehen. Für eine Ausgabe in der Konsole braucht es recht viel Overhead. ZB. Muss bei NewLine das ganze VRAM verschoben werden. Ob dies Hardware beschleunigt ist ? Keine Ahnung.
Das GNOME-Terminal ist ein wenig schneller als xterm.
Beim schreiben in eine Datei, ist es nur ein linearer Strom, und da wirkt dann auch noch der Cache des OS und der HDD.


Nachtrag:
Ich habe gerade die buffer.inc halbiert, jetzt kompiliert er, aber er braucht fast ein Schaltjahr dafür !
20s reichen nicht auf meinem nagelneuen i7 !

[Nixsager]

Ich habe gerade die buffer.inc halbiert, jetzt kompiliert er, aber er braucht fast ein Schaltjahr dafür !
20s reichen nicht auf meinem nagelneuen i7 !

Das mit dem kompilieren dauert bei mir auch ewig.
Ich glaube der Parser ist nicht so schnell, das fällt halt an der Menge der Zeilen auf.

Versuche mal die Konstante so einzubinden wie sie ausgegeben wird, und nicht wie es jetzt es.
So müsste der FPC nicht bei jeder Zeile den String neu berechnen und #10 nicht jedes mal konvertieren.

Da ich jetzt nicht weiß wie das zu bewerkstelligen ist, übergebe ich mal die Aufgabe an dich weiter.

Ich habe mal in Notepad++ alle ''#10 +' durch '/n' ersetzt, und das dauert auch relativ lange.
Die meiste Zeit geht nur für die Konstante drauf. Ist auch kein Wunder, denn das Programm selber ist ja nicht groß.

[Mathias]

Das mit dem kompilieren dauert bei mir auch ewig.
Ich glaube der Parser ist nicht so schnell, das fällt halt an der Menge der Zeilen auf.

Da hat der C-Compiler ausnahmsweise die Nase von, kaum F9 gedrückt und das Programm läuft.
Sonst ist doch FPC an C weit überlegen, was den Compilier-Speed anbelangt.

Versuche mal die Konstante so einzubinden wie sie ausgegeben wird, und nicht wie es jetzt es.
So müsste der FPC nicht bei jeder Zeile den String neu berechnen und #10 nicht jedes mal konvertieren.

Ich verstehe nicht, was du meinst ?
Den ganzen String in eine Zeile packen ?

Nachtrag:
Ich habe nun die Konstante so gebaut, sie ist etwa 42MByte gross.
Die Zeilennummerierung habe ich nun weggelassen, dafür habe ich meine Schleife verdoppelt.
Der Creator hat nun eine Ewigkeit, immerhin kommt 200'000 mal s+s+#xx vor.
Aber dafür wird es kompiliert, und erst noch in Echtzeit.

Code: Alles auswählen

const MyBuffer : PChar = #56#54 ... #55#54#54;  // 42MB !

Alte Test-Date mit deinem Beispiele hat 7,8M und die neue sogar 14MB !

Unter dem Strich scheint der Compiler Probleme zu habe, wen er sehr viele Zeilen addieren muss, bei Win10 wie du sagst, es geht sehr lange, bis zum Totalversagen wie bei mir mit Linux.

[Nixsager]

Ich verstehe nicht, was du meinst ?
Den ganzen String in eine Zeile packen ?

So ähnlich. Versuche es mal.
Ich dachte an sowas wie eine Art Ressource, so das der Compiler den Code nicht konvertieren muss.
So könnte man genauer sehen, wo es bei dem FPC genauer hängt.
Du könntest es ja auch mal byteweise versuchen. Ich glaube dann hättest du Zeit dir eine Kanne Kaffee zu kochen.

[Mathias]

Nachtrag:
Ich habe gerade die buffer.inc halbiert, jetzt kompiliert er, aber er braucht fast ein Schaltjahr dafür !
20s reichen nicht auf meinem nagelneuen i7 !

Nächste Erkenntnis, wie da schon gesagt, bin ich von 100'000 Zeilen auf 50'000 runter gegangen, so kompiliert er wenigstens.
Aber jetzt der interessante Teile, ich habe die Spalten Zahl von 80 auf 8'000 erhöht. Und er kompiliert es !
Die Inc ist von den anfänglichen 8MB auf 350MB gewachsen.
Er kompiliert immer noch während ich jetzt diese Zeilen eintippe, mal gucken, wie lange es noch geht.

Nachtrag: Nach 30min würge ich den Compiler ab.

[Mathias]

Anstelle den Puffer extern zu berechnen, habe ich es jetzt direkt in mein Clipboard-Programm genommen.
Der Puffer wird so schnell berechnet, man merkt es kaum. Es sind (nur ) 1'000'000 Zeilen und das ganze Volumen ist 100MB
Das übertragen über das Clipboard zu xed, dauert dann aber fast 20s.
Lazarus/Synedit frisst die Daten gar nicht, nur im TMemo geht es, aber dies wird ein anderes Problem sein, als die übergrosse Datenmenge.

Code: Alles auswählen

  function CreatBuffer: string;
  const
    LineSize = 90;
    size: SizeInt = 1000 * 1000 * 100 - 10;
  var
    i, j: integer;
    s: string[9];
  begin
    SetLength(Result, size);
    for i := 1 to size do begin
      if i mod LineSize = 0 then begin
        Result[i] := #10;
        s := IntToStr(i div LineSize);
        for j := Length(s) + 1 to 9 do begin
          s[j] := '-';
        end;
        for j := 1 to 9 do begin
          Result[i - LineSize + j] := s[j];
        end;
      end else if i mod 9 = 0 then begin
        Result[i] := '-';
      end else begin
        Result[i] := char(Random(10) + 48);
      end;
    end;
  end;