Delphi bzw. FreePascal neu erlernen?

[Phoenix]

Zitat von Olli73:

Dazu hätte ich auch mal eine Frage, denn ich habe mich bisher nur oberflächlich damit beschäftigt.

Genau das, was du schreibst, habe ich mir auch immer gedacht; nämlich, dass die .net-Programme nach dem ersten Starten (= "Kompilieren für Zielplattform" ?) ja wegen der Optimierungen für die konkrete Zielplattform schneller sein müssten. Man liest aber immer, dass .net i.d.R. langsamer ist. Woran liegt das nun? Ist es nur die garbage collection? Ist das OS/Framework einfach (noch) nicht gut genug dafür optimiert? Oder stimmen die Aussagen nicht, die man überall so liest?

Das wird jetzt tatsächlich etwas Offtopic, daher hier nur soviel dazu:

Die meisten Aussagen die man überall so liest sind in aller Regel stark in die eine oder die andere Richtung gefärbt.
Sagen wir es mal so: Wenn .NET wirklich in der Regel langsamer wäre, würden wir bei Smarthouse nicht um die 200.000 Wertstellungen pro Sekunde von einer Börse auf einem einzelnen CPU-Kern damit verarbeiten können. Das funktioniert aber. Zugegeben, wir mussten auch dort optimieren und ein gutes Know-How über das haben, was das Framework macht. Aber: Assembler-Optimierung in Delphi braucht ein ebenso tiefes Know-How über das was genau auf der CPU abläuft.

Letztlich muss man sich eingestehen, dass sich das nicht viel schenkt.
Managed Code (sei es jetzt .NET oder auch Java) ist nicht grundsätzlich langsamer, und CPU-Kompilate (der Begriff nativ wurde hier in letzter Zeit deutlich überstreckt) müssen nicht zwangsläufig schneller sein. Es gibt Anwendungsfälle, bei denen managed Code massive Vorteile ausspielen kann, und genauso gibt es Anwendungsfälle wo sich diese ins Gegenteil verkehren und die Software tatsächlich ausbremsen könnten.

Wichtig ist aber vor allem auch ein weiterer Aspekt: Wann kommt es bei einer normalen Line of Business Anwendung denn tatsächlich auf das letzte Quäntchen Performance an, das man aus einem System theoretisch rausquetschen könnte? Unser Marktdatensystem ist da eher eine Ausnahme.

Eine normale Desktop-Anwendung - und das ist das, was mit Delphi üblicherweise erstellt wird - verbringt über 90% seiner Zeit damit, auf User-Eingaben oder auf Antworten von Drittsystemen, meist der Datenbank, zu warten. Wenn eine Eingabe erfolgt, oder Daten zurück kommen, dann muss die Anwendung mal kurz etwas hektik betreiben und versuchen möglichst schnell darauf zu reagieren, aber das beschränkt sich in der Regel auf die Anzeige von Daten oder kurzen Berechnungen. Hier wird man als Anwender keinen Unterschied zwischen managed oder unmanaged Code bemerken können.

Der eigentliche Unterschied zwischen den Systemen liegt hier darin, wie effizient eine solche Anwendung mit den jeweiligen Tools erstellt werden kann und um wieviel Code sich der Entwickler tatsächlich kümmern muss. Die Performance der Entwicklung ist hier aussagekräftig. Und die ist für normale Desktop-Anwendungen nunmal auch in aller Regel dort, wo der Entwickler sein tiefstes Know-How hat.

Selbst wenn der Entwickler jetzt aber ein kompletter Delphi-Crack ist, wird er eine Webanwendung für eine Server-Farm damit nur mäßig schnell umsetzen können. Hier sind andere Technologien gefragt. Und hier spielen dann auch managed Umgebungen einen großen Vorteil aus: Sie skalieren in aller Regel deutlich besser. Wenn man in .NET mit der TPL (Task Parallel Library) arbeitet bzw. mit dem Äquivalent für Java, dann weiss ein managed Framework einfach deutlich mehr über die Plattform auf der es läuft und kann die Nutzung der Systemressourcen (CPU-Kerne und Speicher) deutlichst effizienter steuern als man es mit unmanaged Code jemals könnte (ohne krasse Massen an Infrastruktur-Code, der eigentlich ein eigener Task- und Memory-Manager wäre, womit man seinen Code auch managed machen würde).

Es ist grundsätzlich also immer eine Frage von zwei Dingen:
1.) Ist es überhaupt das richtige Werkzeug für die Aufgabe?
2.) Kenne ich mich mit dem Werkzeug auch gut genug aus um es korrekt zu bedienen oder gibt es Alternativen, bei denen ich mit einem gewissen Einarbeitungsaufwand am Ende effizienter bin und/oder ein besseres Produkt erzeugen kann?

[Robotiker]

Zitat von Phoenix:

Letztlich muss man sich eingestehen, dass sich das nicht viel schenkt.
Managed Code (sei es jetzt .NET oder auch Java) ist nicht grundsätzlich langsamer, und CPU-Kompilate

Ich denke bei Herb Sutters Aussagen ging es nicht um Geschwindigkeit, sondern um Effizienz.Ein Grund dafür, dass die Windows 8 Runtime in C++ und COM hochgezogen wurde, dürfte Energieeffizienz gewesen sein.

Auf jeden Fall, um die Kurve zum Thema zurückzukriegen, liest man seine Artikel auch bei Emba. So schrieb David I letzten Monat

Zitat:

While I was in Seattle in April presenting our Delphi for iOS release, I also was able to visit with Herb at the Microsoft campus - that was a real honor!

Vielleicht hilfts ja dem FireMonkey.

Mit seinem Native-GUI Ansatz steht Delphi jedenfalls heute eher in Konkurrenz zu Qt, als zu anderen C++ Entwicklungsumgebungen an sich. MS entwickelt VC++, abseits der Spieleprogrammierung, eher zu einer Systemsprache für die Entwicklung leistungsfähiger Komponenten für andere Sprachen. (In gewisser Weise löst das auch das angesprochene Dotfuscator Problem.) Gleicher Trend bei IBM, wo es neuerdings wieder C++ unterhalb von Java gibt.

Pascal muss da keine schlechter Ansatz sein, es gibt ja auch noch andere native Ansätze, wie D, Go und Rust. C++ ist nicht per se schneller als diese, sondern weil viele Leute an schnellen C++ Compilern und Bibliotheken arbeiten. Der C++ Builder z.B. ist leider nicht schneller als Delphi, andere Compiler schon.