Geschwindigkeit Compiler

[thosch]

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.

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.

Wäre diese Bibliothek besser geeignet?: https://disk.yandex.com/d/A-_dk3NJYj74iw. Ich füge da gerne noch paar Grafikdemos hinzu. Guck aber erst mal den vipgfx Quellcode an, Ordner /vipgfx-code/src

Diese Grafiklibrary funkt in go32 genauso gut wie in Windows und Linux, dort sogar mit Linux Framebuffer Unterstützung. Im Ordner /vipgfx-code/src ist die Unit vipgfx die Entscheidende, In ../../gfxinc ist die Grafik codiert und im Ordner /tycoonuserinterface-code/src/tuicode ist die GUI dazu. In /tycooninterface-code/src befinden sich mit Test.pas und Test.lpr sowie für die letzten programmierten Controls die Datei ToolbarPageControlSliderTest.lpr eine weitere Testanwendung. Soll die Fähigkeiten der GUI aufzeigen. Wäre die was für DOS?

Demos für die Geschwindigkeit der VipGfx füge ich gerne noch hinzu.

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.

Ich programmiere auch in meiner Freizeit, hätte daher schon gerne einen schnelleren Compiler. Der ist mir wichtiger als Abstraktion und Mainability, die eh immer komplexer und damit auch noch anwenderunfreundlicher wird, was wieder andere Interessnkonflikte einbringt. Ich programmiere genau so in meiner Freizeit, wie derjenige der Lazarus benutzerfreundlich macht. Hinzu kommt, dass ich im stillen Kämmerlein alleine programmiere, oft ohne jeden Support. Lazarus ist nicht von einem alleine im stillen Kämmerlein programmiert, sondern da sind hunderte Entwickler dran.

[Niesi]

Das sehe ich anders - der Compiler kann von von mir aus "halb so schnell" sein - die compilierte Anwendung sollte akzeptabel laufen und für möglichst viele Plattformen 1:1 "compilierbar" sein. DAS ist stark!

Die Geschwindigkeit des Compilers ist absolut zweitrangig (für mich) ...

[Winni]

Hi!

Das sehe ich so wie Niesi.

Und die ganzen unsauberen Tricks und Hacks in Delphi beruhen ja auf der Monokultur DOS/Windows,
Wenn man das für jedes OS einzeln machen will, wird es unübersichtlich. Und es fragt sich, wer das alles coden soll.

Anders Hejlsberg als Vater von Turbo Pascal und am Anfang auch von Delphi hat in den 90ern in enem Interview zugegeben, dass eine Menge Code nicht nach der "reinen Lehre" programmiert ist, sondern viele Hacks zugunsten der Geschwindigkeit benutzt wurden. nicht meine Idealvorstellung einer stabilen Programmier-Umgebung.

Winni

[Socke]

Die Geschwindigkeit des Compilers ist absolut zweitrangig (für mich) ...

Bedenkt auch, dass aus einem Compiler noch keine ausführbaren Programme herausfallen. Dazu bedarf es noch eines Assemblers und eines Linkers. Vielleicht möchte ja jemand mold in Free Pascal integrieren?

[PascalDragon]

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.

Ich programmiere auch in meiner Freizeit, hätte daher schon gerne einen schnelleren Compiler. Der ist mir wichtiger als Abstraktion und Mainability, die eh immer komplexer und damit auch noch anwenderunfreundlicher wird, was wieder andere Interessnkonflikte einbringt. Ich programmiere genau so in meiner Freizeit, wie derjenige der Lazarus benutzerfreundlich macht. Hinzu kommt, dass ich im stillen Kämmerlein alleine programmiere, oft ohne jeden Support. Lazarus ist nicht von einem alleine im stillen Kämmerlein programmiert, sondern da sind hunderte Entwickler dran.

Schön, dass du gerne einen schnelleren Compiler hättest, aber irgendjemand muss diesen entwickeln und pflegen zusammen mit der Unterstützung für viele verschiedene Prozessoren und Betriebssysteme. Noch dazu arbeiten mehrere Leute daran. Es ist also essentiell, dass der Compiler maintainable ist. Gleiches gilt für Lazarus. Wenn da die Performance darunter leiden muss, dann ist das eben so, die andere Möglichkeit wäre nämlich sonst, dass es weder FPC noch Lazarus in der jetzigen Form gibt.

Wenn wir allerdings eine Möglichkeit sehen den Compiler zu beschleunigen ohne die Maintainability (zu) negativ zu beeinflussen, dann nehmen wir diese im Normalfall auch durchaus wahr. Oft auch im Zusammenhang mit neuen Optimierungen, die nicht nur Anwendungen, sondern auch den Compiler selbst (Stück für Stück) beschleunigen.

Die Geschwindigkeit des Compilers ist absolut zweitrangig (für mich) ...

Bedenkt auch, dass aus einem Compiler noch keine ausführbaren Programme herausfallen. Dazu bedarf es noch eines Assemblers und eines Linkers. Vielleicht möchte ja jemand mold in Free Pascal integrieren?

Du kannst ja gerne ausprobieren, ob du relativ trivial mold als alternativen Linker hinzufügen kannst. FPC hat die nötige Infrastruktur, um mehrere Linker zu unterstützen. Unter Windows nutzen wir allerdings eh einen eigenen, internen Linker, da uns schon vor Jahren klar wurde, dass ld unter Windows extrem langsam ist und andererseits gab es damals keinen ld für Win64.

[LazarusFuchs]

Ich lagere Lazarus vor Beginn der Arbeit in eine Ramdisk aus. Das schont die SSD und liefert schnellere Ergebnisse, die IDE und die ganzen Komonenten auf der RAM-Disk liegen und beim Linken braucht nur mein Source-Code, der zur Sicherheit auf der SSD liegt und das auszugebende Programm auf der SSD bearbeitet werden. Änderungen bei Lazarus kopiere ich mit einer Batch, die nur die Änderungen zurückschreibt auf die SSD zurück. Kommt ja nach fertiger Konfiguration nicht so oft vor.

[Mathias]

Da frage ich mich, was der Vorteil der Ramdisk ist. Ein Geschwindigkeitsschub wirst du kaum merken, da die Daten der HDD vor zu in den Cache(RAM) gehen.
Was das Schonen der SSD anbelangt, macht dies auch kaum Sinn. Lesezugriffe verschleissen die SSD nicht.

[PascalDragon]

Was das Schonen der SSD anbelangt, macht dies auch kaum Sinn. Lesezugriffe verschleissen die SSD nicht.

Fun fact: Je nach Hersteller kann es sein, dass SSDs bei mehrfachem Lesen langsamer werden und erst wieder schneller werden, wenn man sie neu beschrieben hat (wir hatten da einen Fall bei uns in der Arbeit, bei der eine SSD von der vorwiegend gelesen wurde extrem stark in der Performance eingebrochen war; jeden Sektor 1-zu-1 neu zu beschreiben hat die Performance wieder verbessert )

[corpsman]

Also ich habe letztes Jahr das Biosim Projekt von David Miller von C++ nach FPC übersetzt ( https://github.com/PascalCorpsman/biosi ... ranslation ). Am Ende war natürlich auch die Frage nach den "Zeiten" und Geschwindigkeiten. In der Entsprechenden Präsentation kommt da am Ende ein kurzer Vergleich.

Zusammengefasst:
Beim Compilieren ist FPC deutlich schneller (das kann bei Biosim aber auch daran liegen, dass die C++ Version von riesigen Externen Libs abhängig ist, und mein Port, alles "im Code" hat).

Bei der Ausführung ist der FPC Code Langsamer, das hat verschiedene Ursachen. Eine Recherche zu dem Thema gab zumindest bei mir nur diesen Brauchbaren Link. Generell scheint es aber viele zu geben die das Thema immer wieder versuchen an zu gehen.
Auch kommt es auf die Metrik an:
- Laufzeit
- Kompilierzeit
- Energieefizienz

Alles Kriterien nach denen man gehen kann und nach denen man einzeln Optimieren kann.

Ich Persöhnlich finde Compilierzeit bei sehr viele Programmen die ich so schreibe wichtiger (einfach weil sehr viele Aufgaben auf Aktueller Hardware so schnell gelöst werden, dass der Unterschied in der Laufzeit egal ist). Bei einer Langläufigen Anwendung wie Biosim, macht es dann aber schon einen Unterschied ob meine Simulation 1h oder 1h30 braucht bis sie gerechnet ist. Deswegen hatte ich mich dort dann auch mit Geschwindigkeiten beschäftigt. Im Falle der tanh Funktion sehe ich aber die "Ursache" nicht unbedingt in FPC sondern viel mehr in der Langsamen Implementierung,..