Eure Anregungen für das DEC 5.3 gebraucht

[Codehunter]

Man sollte vorallem auch Prioritäten setzen. Zum Beispiel solche Teile nach hinten schieben, die bisher im DEC nur in Software realisiert waren und inzwischen gegen hardwarebeschleunigte Varianten keine Chance in Sachen Performance mehr haben. Hardwarebeschleunigung wäre zwar schön zu haben, aber eben auch schwer zu implementieren. In Bezug auf Plattformunabhängigkeit sowieso.

Ich bin nicht sicher, warum damals beim DEC auf Assembler gesetzt wurde. Ich vermute aber mal, es ging ebenfalls um Performancevorteile. Da stellt sich ja ohnehin inzwischen die Sinnfrage. Sprich: Wie viel schneller läuft Assemblercode heute noch im Vergleich zu PurePascal auf modernen Prozessoren? Wie viel Wartbarkeit und Portierbarkeit verliert man durch Assembler? Und am Ende muss man Vor- und Nachteile eben abwägen.

[Zacherl]

Zitat von Codehunter:

Ich bin nicht sicher, warum damals beim DEC auf Assembler gesetzt wurde. Ich vermute aber mal, es ging ebenfalls um Performancevorteile.

Genau, Performance spielt eine große Rolle bei Crpyto Anwendungen. Sowohl im Sinne der Geschwindigkeit, als auch im Bezug auf sparsame Nutzung von Resourcen.

Zitat von Codehunter:

Wie viel schneller läuft Assemblercode heute noch im Vergleich zu PurePascal auf modernen Prozessoren?

Das kann man pauschal nicht sagen. Der Delphi Compiler optimiert allerdings derart schlecht, dass man eigentlich gar nicht von Optimierung sprechen kann (im Vergleich zu modernen C/C++ Compilern). Oft sieht man auch total unsinnige Konstrukte, wie

Code:

xor eax, eax

direkt gefolgt von einer Zuweisung wie beispielsweise

Code:

mov eax, [ebx]

Warum zum Teufel wird hier vorher das Register nochmal genullt, obwohl es eine Instruction später sowieso komplett überschrieben wird?

Für "normale" GUI oder Service Anwendungen ist dieser unnötige und schlecht optimierte Code sicherlich nicht relevant, aber wenn es um Algorithmen geht, welche im Zweifelsfalle auch mal eine riesige Anzahl von Iterationen beinhalten, kann man mit Assembler definitiv eine Menge optimieren. Wenn der Code dann noch intelligent, abhängig von den CPU Features, moderne Instruction Sets, wie AVX oder AESNI verwendet, kann das schon einen erheblichen Unterschied machen.

Zitat von Codehunter:

Wie viel Wartbarkeit und Portierbarkeit verliert man durch Assembler? Und am Ende muss man Vor- und Nachteile eben abwägen.

Wartbarkeit ist meiner Meinung nach hier kein großes Problem, da die Crypto Algorithmen sich nicht mehr ändern, nachdem sie einmal standartisiert wurden. Portierbarkeit ist sicherlich ein Argument gegen inline Assembly, wobei es hier eher eine Frage des initial zu leistenden Arbeitsaufwands ist. Ich würde erstmal komplett alles in PurePascal implementieren und später, wo nötig, per IFDEFs entsprechende Assembler Optimierungen für x86 und x86-64 nachrüsten.

[Codehunter]

Zitat von Zacherl:

und später, wo nötig, per IFDEFs entsprechende Assembler Optimierungen für x86 und x86-64 nachrüsten.

Wie sieht das eigentlich mit dem MacOS-Compiler aus? Ist der genauso bescheiden? Was ist dort mit ASM?

Bei den Mobil-Compilern braucht man ja über Performance eh nicht nachdenken. Erst Pascal in Java Bytecode umwandeln und diesen dann in einer Java-VM laufen lassen, da kommt es auf ein paar PurePascal-Routinen mehr auch nicht mehr an.

Auch wenn Windows und x86(-64) der Hauptzielmarkt von Delphi sind, sollte man die anderen Plattformen nicht gänzlich ausblenden und zumindest mal drüber gesprochen haben.

[Zacherl]

Zitat von Codehunter:

Wie sieht das eigentlich mit dem MacOS-Compiler aus? Ist der genauso bescheiden? Was ist dort mit ASM?

Zum MacOS Compiler kann ich leider nichts sagen bezüglich Optimierung und Performance. Ich bin mir auch grade unsicher, ob Delphi überhaupt inline Assembly zulässt, wenn man für Mac compiliert.

Die Mobile Sachen wird man definitiv nicht manuell auf Assembler Ebene optimieren können. Die Performance der PurePascal Routinen sollte sich aber auch von Mobile zu Desktop nicht groß unterscheiden. Die Apple Geräte benutzen ja sowieso natives ARM und auch Android verwendet in der Regel eigentlich keine Java-VM mehr. Das wird alles JIT-compiled und dann nativ ausgeführt.

[Codehunter]

Zitat von Zacherl:

Das wird alles JIT-compiled und dann nativ ausgeführt.

Wobei ich mich schon frage ob diese JIT-Compiler nicht noch lustigere Konstrukte produzieren als dein obiges Beispiel. Vorallem hat man als Entwickler ja überhaupt keine Kontrolle darüber, welcher Compiler dann für das eigene Programm zum Einsatz kommt.

Wegen solcher Probleme bin ich der Meinung, man sollte auf ASM komplett verzichten und lieber nur den Pascalcode optimieren. Ist vielleicht nicht das letzte Quentchen Performance, aber man hätte bei einem Projekt wie DEC auch wichtigeres zu tun.

Hätte, wäre, wenn... Wer macht jetzt was?

[TurboMagic]

Genau: wer macht jetzt was?

Und noch etwas: Delphi für Android compiliert nicht nach Java Byte Code, es compiliert direkt nach ARM code. Deswegen funktionieren solche Apps ja auf x86 Android Geräten nur, wenn dort Intels Houdini Emulation integriert ist (was m.W. bei neueren Android x86 Versionen automatisch der Fall ist aber trotzdem immer wieder Ärger macht weil die Delphi App beim Start eine Kompatibilitätsprüfung durchführt die dann gerne meckert)

[mjustin]

Zitat von Zacherl:

Android verwendet in der Regel eigentlich keine Java-VM mehr. Das wird alles JIT-compiled und dann nativ ausgeführt.

Beziehungsweise (ab Android 5.0) Ahead-Of-Time über ART, nicht mehr mit JIT und Dalvik.