AW: Eure Anregungen für das DEC 5.3 gebraucht
Hallo,
was wäre, wenn manche der Dinge schon in Arbeit wären und es einfach noch helfen würde wenn weitere Personen mitarbeiten würden? Grüße TurboMagic |
AW: Eure Anregungen für das DEC 5.3 gebraucht
Dann wäre das hier genau der richtige Platz um darüber zu sprechen, nicht wahr? :-) Denn augenscheinlich liegt das Projekt in einem Tiefschlaf. Wenn der Schein trügt sollten die Beteiligten das doch einfach sagen.
|
AW: Eure Anregungen für das DEC 5.3 gebraucht
Ihr solltet Euch im Klaren sein, was das eigentlich für eine Arbeit sein wird. Wenn man nicht ein wenig konkret wird, ist das kaum abzuschätzen.
Für mich wäre DEC wieder interessant, wenn
Und das wären ja erst die Bausteine, welche High-Level Protokolle kommen dazu, etc. Ich kann mir ehrlich nicht vostellen, daß jemand das heute alles im Sinne der alten DEC-Philosophie frei (kostenlos) zur Verfügung stellt und wartet, d.h eine umfangreiche, aktuelle, integrierte Pascal-Bibliotek wird's wohl leider noch nur kommerziel geben (zB http://www.streamsec.com/ oder https://www.eldos.com/sbb/) Gruß Gammatester |
AW: Eure Anregungen für das DEC 5.3 gebraucht
Man kann sich auch mal diese Krypto-Seite angucken. Der Einstieg kostet aber auch etwas Zeit.:thumb:
|
AW: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
Machen wir uns nichts vor: Dieses hervorragende Projekt hat seine besten Zeiten hinter sich. Wahrscheinlich wird es aus seinem 5.2-Stadium leider nie mehr herauskommen. |
AW: Eure Anregungen für das DEC 5.3 gebraucht
Das Problem mit dem Outen ist, dass die Wünsche der Anwender vielfältig sind und die Ressourcen der Maintainer begrenzt. Es würden dann ganz schnell mehr Leute hier neue Wünsche äußern als sich neue Maintainer melden würden.
Aus meiner Sicht müsste ein neues Release auf folgendes Wert legen: 1. Für alle Teile PurePascal Versionen bereit stellen. 2. Soweit wie möglich aufrufkompatibel zu DEC 5.2 sein 3. Keine Datentypen verwenden die auf mobilen Compilern nicht verfügbar sind und wenn, dann so mittels $IFNDEF NEXTGEN ausgeklammert, dass die mobilen Compiler das nicht compilieren versuchen 4. Die Struktur evtl. intern so umbauen, dass es wartungsfreundlicher wird 5. Alles besser dokumentieren und zumindest grob mit Unit-Tests absichern => das ist eine größere Aufgabe, neue Crypto-Algorithmen wären da erstmal nur im Weg. Ist diese Aufgabe gelöst kann man sich auch übner neuere Algorithmen Gedanken machen. Aber erst dann. Eine neue Version könnte ruhig auch die Unterstützung für ältere Compiler < D2009 einstellen. Neuere Sprachfeatures sollten nur mit Bedacht eingesetzt werden, eben da wo wirklich sinnvoll. So, würden sich für so etwas weitere Maintainer finden lassen? Grüße TurboMagic |
AW: Eure Anregungen für das DEC 5.3 gebraucht
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. |
AW: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
Zitat:
Code:
direkt gefolgt von einer Zuweisung wie beispielsweise
xor eax, eax
Code:
Warum zum Teufel wird hier vorher das Register nochmal genullt, obwohl es eine Instruction später sowieso komplett überschrieben wird?
mov eax, [ebx]
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:
|
AW: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
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. |
AW: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz