Geschwindigkeit Compiler

Für sonstige Unterhaltungen, welche nicht direkt mit Lazarus zu tun haben
Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Geschwindigkeit Compiler

Beitrag von Michl »

Weil ich gerade bei einem anderen Thema darüber sinniert habe, daß ich den Compiler zweckentfremde und öfters zum überprüfen meines Codes nutze, frage ich mich, wie das eigentlich so bei anderen Programmiersystemen aussieht. Den FreePascal Compiler kann ich ja nur deswegen zweckentfremden, da er so schnell ist.

Hintergrund dieser Frage ist, daß ich daheim jetzt bei fast allen Projekten von SVN auf Git umgestiegen bin. Dort nutze ich hauptsächlich TortoiseGit. Dieses hatte einen Fehler und bei der Behebung des Fehlers schrieb der Autor:
It was kind of funny...
about 2 hours to get any development environment.
5 minutes to fix the bug
then yet 2 hours more to make VC++ compile this triviality...
Mir fehlt da der Einblick. Ist es tatsächlich so, daß der Compiler 2h benötigt, um den vermutlich überschaubaren Code zu übersetzen? Wie ist das bei anderen Entwicklungsumgebungen?

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

PascalDragon
Beiträge: 825
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: Geschwindigkeit Compiler

Beitrag von PascalDragon »

Es ist tatsächlich so, dass die Geschwindigkeit eine der hochgelobten Stärken von TP/Delphi/FPC ist. Schnell genug, dass man einfach schnell kompilieren kann, um zu schauen, ob alles passt.

Wobei ich zumindest bei Visual Studio 2019 sagen kann, dass der C++ Compiler und Linker (muss man ja beides zusammen sehen) recht flott sind, vor allem, wenn man mehrkernig kompiliert.

Leider kann ich jetzt gerade keinen direkten Vergleich zwischen FPC und VS machen, da ich keine wirklich vergleichbaren Projekte habe...
FPC Compiler Entwickler

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Geschwindigkeit Compiler

Beitrag von Socke »

Es liegt nicht nur am Compiler. Auch der gcc kann besser vorkompilieren und wiederverwenden, wenn die Includes besser organisiert sind (https://www.heise.de/news/Linux-Kernel- ... 17264.html).
Genau ist der Linker eine nicht unerhebliche Quelle für den gesamten Bauprozess. Daher hat FPC für Windows auch einen internen Linker an Board und nutzt nicht die GNU Binutils. Für Linux wurde vor kurzem Mold geschaffen, den ich auch gerne mal mit FPC zusammen ausprobieren würde.

In der Tat wurde Pascal aber bereits im Original so konstruiert, dass der Compiler direkt beim Lesen des Quelltext den Assemblercode erzeugen kann. Im Gegensatz zu anderen Sprachen ist kein Vor- und Zurückspringen notwendig. Dass dies ggf. für Optimierungen nur eingeschränkt gelten kann, versteht sich von selbst.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Geschwindigkeit Compiler

Beitrag von Michl »

PascalDragon hat geschrieben:
Mi 9. Feb 2022, 09:14
Es ist tatsächlich so, dass die Geschwindigkeit eine der hochgelobten Stärken von TP/Delphi/FPC ist. Schnell genug, dass man einfach schnell kompilieren kann, um zu schauen, ob alles passt.
Ja genau das mache ich hier andauernd. Ohne dem würde ich Cody nicht auch ständig bemühen können, mir fehlende Units einzufügen. Das ist echt praktisch!

PascalDragon hat geschrieben:
Mi 9. Feb 2022, 09:14
Wobei ich zumindest bei Visual Studio 2019 sagen kann, dass der C++ Compiler und Linker (muss man ja beides zusammen sehen) recht flott sind, vor allem, wenn man mehrkernig kompiliert.
Ok, dann ist das kein Alleinstellungsmerkmal von FPC. Schade, sonst hätte man exklusiv damit werben können :wink:

Nicht desto trotz, gehört mMn so ein Werbespruch wie "Einer der schnellsten Compiler/Linker auf dem Markt" ganz vorn auf die Webseite https://www.freepascal.org/ oder auch "Eine Entwicklungsumgebung mit einem der schnellsten Compiler/Linker auf dem Markt" auf https://www.lazarus-ide.org/.

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Geschwindigkeit Compiler

Beitrag von Michl »

Socke hat geschrieben:
Mi 9. Feb 2022, 09:48
Auch der gcc kann besser vorkompilieren und wiederverwenden, wenn die Includes besser organisiert sind (https://www.heise.de/news/Linux-Kernel- ... 17264.html).
Genau ist der Linker eine nicht unerhebliche Quelle für den gesamten Bauprozess.
Auch in dem verlinkten Artikel steht, daß man den Komplettumbau wohl trotz der Unannehmlichkeiten akzeptieren wird, aufgrund der Baubeschleunigung.
Wie gesagt, wenn das nicht selbstverständlich ist, sollte man mMn damit werben.

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Geschwindigkeit Compiler

Beitrag von Warf »

Die compilezeit von Pascal ist gar nicht so besonders schnell, es ist eher das C und C++, mit welchen es normalerweise verglichen wird besonders langsam sind.
Das hat mehrere Gründe, einer der Hauptgründe ist die verwendung von Inlcude Dateien. Im gegensatz zu Pascal Units hat C und C++ kein Modulares system auf sprachebene, sondern nur auf Linker ebene, d.h. die verschiedenen C und C++ files werden zu Object Files kompiliert die dann zusammengelinkt werden. Wenn eine Änderung nur den Objectfile betrifft ist das auch alles schön schnell, einmal eben den Object File neu Kompilieren und neu Linken, im Grunde was passiert wenn du in Pascal eine Unit änderst.
Das Problem ist allerdings wie Includes gehandhabt werden. Includes werden einfach eingefügt, d.h. bei einem #inclide "foo.h" wird diese Zeile komplett durch den Inhalt von foo.h ausgetauscht. Eine Änderung im Header bedeutet also das jede Datei die den Header benutzt neu kompiliert werden muss, und wenn der Header von einem anderen Header included wird, dann alle die diesen Header benutzen. Eine Änderung im Header kann also gerne mal dazu führen das das gesammte Projekt neu kompiliert werden muss.

Das zweite ist das C und C++ ja auch mehr können als Pascal. Zunächst gibt es in den Sprachen Makros für den Präprozessor, welche Turingvollständig sind. Das Parsen und Ausführen davon ist natürlich entsprechend aufwendig und kostet zeit. Pascal Makros sind einerseitz viel limitierter und andererseits kommen sie viel seltener zum einsatz (man sieht kaum Nutzung außer gelegentliche ifdefs die bei einem Linearen durchlaufen ausgeführt werden können). Mit C++ kamen dann noch die Templates dazu, welche auch wieder eine alleine eine Turingvollständige Compilezeit Sprache darstellen, während Pascal Generics extrem limitiert sind.
Vor allem ist hier auch wichtig die Verwendung, weil Makros und Generics in Pascal so limitiert sind, werden sie sehr selten benutzt, Generics z.B. find Hauptsächlich in Collections ihren einsatz. In C++ sind Templates überall. D.h. nicht nur sind sie potentiell aufwendiger zu parsen, da sie überall benutzt werden, muss der Compiler überall die extra Arbeit machen, während der meiste Pascal Code immernoch so aussieht als käme er aus den 90ern.

Und was sehr viel ausmacht sind auch Optimierungen. Der FPC ist eher zurückhaltend mit Optimierungen, z.B. inlined der FPC allgemein nur kleine Funktionen mit einer geringen inline tiefe, sodass die meldung "XXX marked inline was not inlined" bei fast jedem Programm 90% der Meldungen ausmacht. Konstruktoren werden meines wissens nach z.B. gar nicht geinlined.
Der GCC oder LLVM/Clang sind da deutlich gnadenloser, die optimieren dir komplette klassen hierachien weg, und oftmals durch devirtualisierung sogar virtuelle methoden. Soweit ich weis haben die beiden Compiler auch, im gegensatz zum FPC kein Komplexitätslimit, also die inlinen auch funktionen mit hunderten von Zeilen wenn der Compiler es für Sinnig erachtet.
Das ist grade in C++ auch nötig, da Templates gerne mal hunderte bis tausende von Funktionen aus einem Template erzeugen, die dann durch das inlinen so zu sagen wieder aufgeräumt werden. Und da Optimierungen normalerweise nur auf Objectfile ebene (also C/C++ Datei) gemacht werden, sind große Teile der C++ STL header only, d.h. die gesammte Funktionalität steht im Header, etwas was seit C++ mit dem "inline" keyword geht ("inline" in C macht was anderes als in C++) und somit die Optimierung, vor allem inlining dieser Funktionen über aller Dateien die diese Header verwenden hinweg ermöglicht.
Mit LLVM wird auch öfters mal gerne Link Time Optimization (LTO) gemacht, hier wird das gesammte Programm zusammen gelinkt (als ein großes LLVM programm) und danach wird nochmal Optimierungen auf dem Programm als ganzes gemacht, das erlaubt z.B. das inlinen zwischen verschiedenen objectfiles erlaubt. Das explodiert natürlich die möglichen Optimierungen (Kombinatorik, Fakultätisches wachstum) und kann damit das ganze extrem viel langsamer machen.

Das ist auch übrigens das Problem warum man für größere C und C++ Projekte auch gerne mal minimale RAM anforderungen von 4GB+ hat und die CPU voll auslastet, weil der Compiler einfach so sehr viel macht was Leistung und Speicher zieht.

Also kurz um, der Grund warum der FPC so viel schneller Kompiliert als GCC oder Clang ist zum größten Teil einfach weil er weniger macht als seine C Gegenstücke.
Das sieht man auch gut daran das mit kleineren C Compilern die nicht so viel Optimieren, wie z.B. der Tiny C Compiler, die deutlich schneller sind als GCC oder Clang.

Benutzeravatar
Niesi
Lazarusforum e. V.
Beiträge: 331
Registriert: So 26. Jun 2016, 19:44
OS, Lazarus, FPC: Linux Mint Cinnamon (Windows wenn notwendig), Lazarus 3.0 FPC 3.3.1

Re: Geschwindigkeit Compiler

Beitrag von Niesi »

Warf hat geschrieben:
Mi 9. Feb 2022, 11:35
...

Das ist auch übrigens das Problem warum man für größere C und C++ Projekte auch gerne mal minimale RAM anforderungen von 4GB+ hat und die CPU voll auslastet, weil der Compiler einfach so sehr viel macht was Leistung und Speicher zieht.

Also kurz um, der Grund warum der FPC so viel schneller Kompiliert als GCC oder Clang ist zum größten Teil einfach weil er weniger macht als seine C Gegenstücke.
Das sieht man auch gut daran das mit kleineren C Compilern die nicht so viel Optimieren, wie z.B. der Tiny C Compiler, die deutlich schneller sind als GCC oder Clang.
Nun ja.
Dadurch werden weder C noch C++ besser.
FPC wird dadurch nicht schlechter.
Und das ist es, worauf es ankommt ...
Wissen ist das einzige Gut, das sich vermehrt, wenn es geteilt wird ...

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Geschwindigkeit Compiler

Beitrag von Warf »

Naja C++ Templates haben einige features die ich mir schon oft in Pascal gewünscht habe. Sieh dir z.B. diese Datei hier an: https://github.com/Warfley/STAX/blob/ma ... edures.pas und noch einmal für funktionen: https://github.com/Warfley/STAX/blob/ma ... ctions.pas
Das sind 700 Zeilen Code (zugegeben, er ist automatisch generiert von einem 300 zeilen Python script) um einen callable funktionspointer wrapper zu erstellen für funktionen mit bis zu 5 normalen (also kein const, var, etc.) parametern, was durch die varardic template parameter in C++ mit einem typen in maximal 30 zeilen geht, und dann für alle funktionen mit beliebigen parametern gilt.
Templates sind eines der besten feature von C++ grade weil sie so viel können. Ich bin schon ziemlich oft an den Punkt gekommen wo ich mich geärgert habe das ich in Pascal manche Sachen die in C++ möglich sind einfach nicht machen kann. Das Beispiel oben ist eines der neusten dieser Serie.

Und die das bessere Optimierungen Nützlich sein können liegt glaube ich auf der Hand. Wobei ich da sagen muss das in den allermeisten Anwendungen Performance nicht das Problem darstellt, weshalb mich so sachen wie die inlining begrenzung nicht wirklich stören. Natürlich wäre es schön wenn der FPC so guten code wie möglich erzeugen würde, notwendig ist es allerdings nicht

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Geschwindigkeit Compiler

Beitrag von wp_xyz »

Michl hat geschrieben:
Mi 9. Feb 2022, 10:45
Nicht desto trotz, gehört mMn so ein Werbespruch wie "Einer der schnellsten Compiler/Linker auf dem Markt" ganz vorn auf die Webseite https://www.freepascal.org/ oder auch "Eine Entwicklungsumgebung mit einem der schnellsten Compiler/Linker auf dem Markt" auf https://www.lazarus-ide.org/.
Mit so einer Aussage wäre ich vorsichtig. Denn jeder, der Pascal kennt, wird den Vergleich mit Delphi ziehen, und dagegen ist FPC lähmend langsam.

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Geschwindigkeit Compiler

Beitrag von Warf »

Um mal kurz ein Beispiel für den Unterschied was Optimierungen bei FPC und GCC angeht zu geben, simples Fibonacci program:

Code: Alles auswählen

function fib(const n: Cardinal): Cardinal;
begin
    if n = 0 then Exit(1);
    if n = 1 then Exit(1);
    Result := fib(n - 1) + fib(n - 2);
end;
In O1:

Code: Alles auswählen

fib(longword):
        pushq   %rbp
        movq    %rsp,%rbp
        leaq    -32(%rsp),%rsp
        movq    %rbx,-24(%rbp)
        movl    %edi,-8(%rbp)
        testl   %edi,%edi
        jne     .Lj6
        movl    $1,-12(%rbp)
        jmp     .Lj3
.Lj6:
        cmpl    $1,-8(%rbp)
        jne     .Lj8
        movl    $1,-12(%rbp)
        jmp     .Lj3
.Lj8:
        movl    -8(%rbp),%eax
        leal    -1(%eax),%edi
        call    fib(longword)
        movl    %eax,%ebx
        movl    -8(%rbp),%eax
        leal    -2(%eax),%edi
        call    fib(longword)
        addl    %ebx,%eax
        movl    %eax,-12(%rbp)
.Lj3:
        movl    -12(%rbp),%eax
        movq    -24(%rbp),%rbx
        movq    %rbp,%rsp
        popq    %rbp
        ret
O3:

Code: Alles auswählen

fib(longword):
        pushq   %rbx
        pushq   %r12
        pushq   %r13
        movl    %edi,%ebx
        testl   %edi,%edi
        jne     .Lj6
        movl    $1,%r12d
        jmp     .Lj3
.Lj6:
        cmpl    $1,%ebx
        jne     .Lj8
        movl    $1,%r12d
        jmp     .Lj3
.Lj8:
        movl    %ebx,%edi
        subl    $1,%edi
        call    fib(longword)
        movl    %eax,%r13d
        movl    %ebx,%edi
        subl    $2,%edi
        call    fib(longword)
        leal    (%eax,%r13d),%r12d
.Lj3:
        movl    %r12d,%eax
        popq    %r13
        popq    %r12
        popq    %rbx
        ret
Im grunde extrem ähnlich, also optimierungstechnisch passiert hier nicht viel.

GCC:

Code: Alles auswählen

unsigned fib(unsigned const n) {
    if (n == 0) return 1;
    if (n == 1) return 1;
    return fib(n - 1) + fib(n - 2);
}
O1:

Code: Alles auswählen

fib(unsigned int):
        mov     eax, 1
        cmp     edi, 1
        ja      .L8
        ret
.L8:
        push    rbp
        push    rbx
        sub     rsp, 8
        mov     ebx, edi
        lea     edi, [rdi-1]
        call    fib(unsigned int)
        mov     ebp, eax
        lea     edi, [rbx-2]
        call    fib(unsigned int)
        add     eax, ebp
        add     rsp, 8
        pop     rbx
        pop     rbp
        ret
O3:

Code: Alles auswählen

fib(unsigned int):
        cmp     edi, 1
        jbe     .L20
        push    r15
        mov     r10d, edi
        push    r14
        push    r13
        push    r12
        push    rbp
        push    rbx
        sub     rsp, 56
        mov     DWORD PTR [rsp], 0
.L19:
        mov     DWORD PTR [rsp+4], 0
        lea     r11d, [r10-1]
        mov     DWORD PTR [rsp+24], r10d
.L18:
        cmp     r11d, 1
        je      .L3
        mov     DWORD PTR [rsp+8], 0
        lea     r9d, [r11-1]
        mov     DWORD PTR [rsp+28], r11d
.L17:
        cmp     r9d, 1
        je      .L4
        mov     DWORD PTR [rsp+32], r9d
        lea     r15d, [r9-1]
        xor     r10d, r10d
.L16:
        cmp     r15d, 1
        je      .L5
        mov     DWORD PTR [rsp+40], r10d
        lea     edx, [r15-1]
        xor     r11d, r11d
        mov     DWORD PTR [rsp+36], r15d
        mov     r14d, r11d
        mov     r15d, edx
.L15:
        cmp     r15d, 1
        je      .L6
        lea     r12d, [r15-1]
        xor     esi, esi
        mov     ecx, r14d
        mov     r8d, r15d
.L14:
        cmp     r12d, 1
        je      .L7
        lea     ebx, [r12-1]
        xor     r13d, r13d
        mov     edx, r12d
.L13:
        cmp     ebx, 1
        je      .L8
        mov     eax, ebx
        lea     r14d, [rbx-1]
        xor     r15d, r15d
        mov     ebx, ecx
        mov     ecx, r13d
        mov     r13d, esi
        mov     esi, eax
.L12:
        cmp     r14d, 1
        je      .L9
        mov     DWORD PTR [rsp+44], r14d
        lea     ebp, [r14-1]
        xor     r12d, r12d
        mov     r14d, edx
.L11:
        cmp     ebp, 1
        je      .L10
        lea     edi, [rbp-1]
        mov     DWORD PTR [rsp+20], esi
        mov     DWORD PTR [rsp+16], r8d
        mov     DWORD PTR [rsp+12], ecx
        call    fib(unsigned int)
        mov     ecx, DWORD PTR [rsp+12]
        mov     r8d, DWORD PTR [rsp+16]
        add     r12d, eax
        sub     ebp, 2
        mov     esi, DWORD PTR [rsp+20]
        jne     .L11
.L10:
        mov     edx, r14d
        mov     r14d, DWORD PTR [rsp+44]
        lea     r15d, [r15+1+r12]
        sub     r14d, 2
        jne     .L12
.L9:
        mov     eax, esi
        mov     esi, r13d
        mov     r13d, ecx
        mov     ecx, ebx
        mov     ebx, eax
        lea     r13d, [r15+1+r13]
        sub     ebx, 2
        jne     .L13
.L8:
        mov     r12d, edx
        lea     esi, [rsi+1+r13]
        sub     r12d, 2
        jne     .L14
.L7:
        mov     r15d, r8d
        lea     r14d, [rcx+1+rsi]
        sub     r15d, 2
        jne     .L15
.L6:
        mov     r10d, DWORD PTR [rsp+40]
        mov     r15d, DWORD PTR [rsp+36]
        lea     r10d, [r10+1+r14]
        sub     r15d, 2
        jne     .L16
.L5:
        mov     eax, DWORD PTR [rsp+8]
        mov     r9d, DWORD PTR [rsp+32]
        lea     eax, [rax+1+r10]
        mov     DWORD PTR [rsp+8], eax
        sub     r9d, 2
        jne     .L17
.L4:
        mov     eax, DWORD PTR [rsp+4]
        mov     edi, DWORD PTR [rsp+8]
        mov     r11d, DWORD PTR [rsp+28]
        lea     eax, [rax+1+rdi]
        mov     DWORD PTR [rsp+4], eax
        sub     r11d, 2
        jne     .L18
.L3:
        mov     eax, DWORD PTR [rsp]
        mov     r10d, DWORD PTR [rsp+24]
        mov     edi, DWORD PTR [rsp+4]
        sub     r10d, 2
        lea     eax, [rax+1+rdi]
        mov     DWORD PTR [rsp], eax
        cmp     r10d, 1
        ja      .L19
        add     rsp, 56
        add     eax, 1
        pop     rbx
        pop     rbp
        pop     r12
        pop     r13
        pop     r14
        pop     r15
        ret
.L20:
        mov     eax, 1
        ret
Der GCC optimizer macht hier eine menge an parses mit verschiedenen substitutionsregeln, loop unrolling, etc. Im grunde wird hier die Funktion mehrfach neugeschrieben bis man am ende nicht mehr erkennen kann was es ursprünglich mal war. Der FPC Optimiser hingegen verbessert ein bisschen den code, aber im grunde bleibt es die selbe Funktion mit ein paar kleinen Änderungen. Das benötigt natürlich deutlich weniger parses.

Das alleine macht wahrscheinlich schon einen nicht unerheblichen unterschied in der Compilezeit aus

Michl
Beiträge: 2505
Registriert: Di 19. Jun 2012, 12:54

Re: Geschwindigkeit Compiler

Beitrag von Michl »

wp_xyz hat geschrieben:
Mi 9. Feb 2022, 14:33
Mit so einer Aussage wäre ich vorsichtig. Denn jeder, der Pascal kennt, wird den Vergleich mit Delphi ziehen, und dagegen ist FPC lähmend langsam.
Schade, das letzte mal als ich Delphi getestet habe, war mir das nicht bewusst aufgefallen. Wie auch immer, selbst große Projekte werden per kompletter Neukompilierung innerhalb eins, zwei Minuten neu gebaut. 2 Stunden würden mich wohl komplett aus dem Flow bringen.

@Warf: Danke für die ausführliche Erklärung. Das mit der Optimierung finde ich prinzipiell spannend. Ich habe hier ein Programm, was 24/7 läuft und meine vier Kerne des Prozessors gut beansprucht. Da würden mich z.B. 10% höhere Geschwindigkeit durchaus interessieren, die Größe des Codes wäre mir da egal. Optimierungen habe ich öfters mit kleineren Testprogrammen probiert. Bisher konnte ich dies vernachlässigen. Meistens war es viel sinnvoller meinen eigenen Code zu optimieren.

Code: Alles auswählen

type
  TLiveSelection = (lsMoney, lsChilds, lsTime);
  TLive = Array[0..1] of TLiveSelection; 

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Geschwindigkeit Compiler

Beitrag von Warf »

Michl hat geschrieben:
Mi 9. Feb 2022, 20:36
@Warf: Danke für die ausführliche Erklärung. Das mit der Optimierung finde ich prinzipiell spannend. Ich habe hier ein Programm, was 24/7 läuft und meine vier Kerne des Prozessors gut beansprucht. Da würden mich z.B. 10% höhere Geschwindigkeit durchaus interessieren, die Größe des Codes wäre mir da egal. Optimierungen habe ich öfters mit kleineren Testprogrammen probiert. Bisher konnte ich dies vernachlässigen. Meistens war es viel sinnvoller meinen eigenen Code zu optimieren.
Was eventuell da interessant ist ist LLVM als backend zu benutzen, damit solltest du auch die ganzen Optimierungen für Pascal bekommen. Das gesagt ich weiß nicht wie da aktuell der Stand ist

thosch
Beiträge: 324
Registriert: Mo 10. Jul 2017, 20:32

Re: Geschwindigkeit Compiler

Beitrag von thosch »

Michl hat geschrieben:
Mi 9. Feb 2022, 10:45
PascalDragon hat geschrieben:
Mi 9. Feb 2022, 09:14
... sonst hätte man exklusiv damit werben können :wink:
Da mit Freedos ja DOS wieder gefühlt im Kommen ist, wie wäre es mit einer GUI LIB für GO32v2 zur Erstellung von auf der Konsole startbaren Einzelanwendungen?
Könnte man sowas in Lazarus an die NoGUI Schnittstelle anbinden?

Das wäre für die zahlreichen DOS Spielefans ne feine Sache, da es ja den GO32V2 Compiler nun mal immer noch gibt.
Michl hat geschrieben:
Mi 9. Feb 2022, 10:45
Nicht desto trotz, gehört mMn so ein Werbespruch wie "Einer der schnellsten Compiler/Linker auf dem Markt" ganz vorn auf die Webseite https://www.freepascal.org/ oder auch "Eine Entwicklungsumgebung mit einem der schnellsten Compiler/Linker auf dem Markt" auf https://www.lazarus-ide.org/.
Delphi kann das schneller! Nicht schön reden, sondern einfach verbessern! Vom Reden wird der Compiler nicht schneller.

Mathias
Beiträge: 6163
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: Geschwindigkeit Compiler

Beitrag von Mathias »

Was man nicht vergessen darf, die LCL braucht auch recht viel Zeit.
Ich bin gerade mit X11 und xlib am rumprobieren. Das ist der Compiler extrem schnell, man hat kaum den Finger von F9 startet das Programm schon. So nebenbei ist die EXE nicht mal 250KB, im Vergleich, mit LCL hat sie 6.2MB ! Beides ohne Dubuggerinfos.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

PascalDragon
Beiträge: 825
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: Geschwindigkeit Compiler

Beitrag von PascalDragon »

thosch hat geschrieben:
Mi 2. Nov 2022, 15:43
Da mit Freedos ja DOS wieder gefühlt im Kommen ist, wie wäre es mit einer GUI LIB für GO32v2 zur Erstellung von auf der Konsole startbaren Einzelanwendungen?
Könnte man sowas in Lazarus an die NoGUI Schnittstelle anbinden?
Das wäre nicht NoGUI, sondern ein eigenes WidgetSet. Das es prinzipiell auch auf älteren Systemen geht hat ALB42 mit seinen Port der LCL auf das Amiga MUI gezeigt.
thosch hat geschrieben:
Mi 2. Nov 2022, 15:43
Das wäre für die zahlreichen DOS Spielefans ne feine Sache, da es ja den GO32V2 Compiler nun mal immer noch gibt.
DOS Spielefans werden sich allerdings von einer Bibliothek wie der LCL fern halten und eher direkt auf die Hardware gehen, da sie meist eh Fullscreen brauchen.
thosch hat geschrieben:
Mi 2. Nov 2022, 15:43
Michl hat geschrieben:
Mi 9. Feb 2022, 10:45
Nicht desto trotz, gehört mMn so ein Werbespruch wie "Einer der schnellsten Compiler/Linker auf dem Markt" ganz vorn auf die Webseite https://www.freepascal.org/ oder auch "Eine Entwicklungsumgebung mit einem der schnellsten Compiler/Linker auf dem Markt" auf https://www.lazarus-ide.org/.
Delphi kann das schneller! Nicht schön reden, sondern einfach verbessern! Vom Reden wird der Compiler nicht schneller.
FPC wird letztlich immer langsamer als Delphi bleiben, da FPC einen höheren Grad an Abstraktion hat, um so viele Betriebssysteme und Architekturen zu unterstützen. Delphi ist in dieser Hinsicht etwas einfacher gestrickt. Und letztlich gilt bei uns: Maintainability ist wichtiger als Performance. Da wir ja in unserer Freizeit an FPC arbeiten, wollen wir uns das Leben nicht durch irgendwelche komischen Verrenkungen, nur um ein paar Prozent mehr Performance rauszuquetschen, schwerer machen.
FPC Compiler Entwickler

Antworten