Geschwindigkeitsvorteil 64 ggüb. 32 Bit - woran ermitteln?

[TiGü]

Zitat:

Zitat von BUG (Beitrag 1135270)

Zitat:

Zitat von Micha88 (Beitrag 1135258)

Mh. Das heißt, die Zahlen sind wohl kleiner.
Was sollte man bei XE2 statt Extended denn dann wohl besser nehmen?

Vor allem ist die Genauigkeit geringer.
Mit viel Aufwand könnte man einen Record mit überladenen Operatoren schreiben, der Extended simuliert (nicht zu vergessen die passende Funtionen: Sin, Arcsin, Cos, Arcos, Abs, ...).

Das wäre doch was, wenn wieder jemand fragt, was er machen soll :mrgreen:

Oder man nutzt einfach das, was schon da ist:
http://docwiki.embarcadero.com/Libra...TExtended80Rec

[Medium]

Leider (aus dem Link):

Zitat:

Hinweis: Der Typ Extended80 wird für die Arbeit mit binären Daten mit den 32-Bit-Versionen von Delphi verwendet. Obwohl Extended80 10 Byte groß ist, kommen Berechnungen mit diesem Typ vor, die eine doppelte 8-Byte-Genauigkeitsarithmetik verwenden. D.h., Extended80 dient nur der Darstellungskompatibilität, es fügt 64-Bit-Delphi keine Berechnungsmöglichkeiten für eine erweiterte 10-Byte-Genauigkeit hinzu.

[Micha88]

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

[Darlo]

Zitat:

Zitat von Medium (Beitrag 1135285)

Leider (aus dem Link):

Zitat:

Hinweis: Der Typ Extended80 wird für die Arbeit mit binären Daten mit den 32-Bit-Versionen von Delphi verwendet. Obwohl Extended80 10 Byte groß ist, kommen Berechnungen mit diesem Typ vor, die eine doppelte 8-Byte-Genauigkeitsarithmetik verwenden. D.h., Extended80 dient nur der Darstellungskompatibilität, es fügt 64-Bit-Delphi keine Berechnungsmöglichkeiten für eine erweiterte 10-Byte-Genauigkeit hinzu.

Die Release-Version ist erheblich kleiner.

http://www.delphipraxis.net/164359-x...ml#post1135292

Edit: Ups, war ja Dein eigenes Thema....

[Stevie]

Zitat:

Zitat von Micha88 (Beitrag 1135288)

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

Die Größe einer leeren Anwendung steigt schon seit Jahren durch Erweitung der Runtime und vor allem der RTTI. Wen das in Zeiten von Gigabit Lan, 100 MBit Internet und Terabyte Festplatten stört (weil er eventuell auf Bandbreite etc achten muss), hat die Möglichkeit, die RTTI explizit zu entfernen, mit Runtime packages zu arbeiten (wo man dann beim neu Deployen nur seine Anwendung und nicht die Packages nochmals übermitteln muss).

Beachte aber auch, dass die Größe einer leeren Applikation nahezu keine Aussagekraft hat (übrigens ist die Standard Config auf Debug gesetzt, die sind standardmäßig nochmal um einiges größer). Interessant wird es, wenn es eine richtige Applikation ist, und dann fällt das u.U. nicht mehr ins Gewicht.

[TiGü]

Zitat:

Zitat von Medium (Beitrag 1135285)

Leider (aus dem Link):

Zitat:

Hinweis: Der Typ Extended80 wird für die Arbeit mit binären Daten mit den 32-Bit-Versionen von Delphi verwendet. Obwohl Extended80 10 Byte groß ist, kommen Berechnungen mit diesem Typ vor, die eine doppelte 8-Byte-Genauigkeitsarithmetik verwenden. D.h., Extended80 dient nur der Darstellungskompatibilität, es fügt 64-Bit-Delphi keine Berechnungsmöglichkeiten für eine erweiterte 10-Byte-Genauigkeit hinzu.

Extended80 <> TExtended80Rec!

Oder hab ich mich verguckt?

[Medium]

Ich hab mich verquoted :oops:

Gleich darüber steht:

Zitat:

In Delphi unter Win32 ist der Extended-Datentyp 10 Byte groß. Unter Win64 ist der Extended-Datentyp jedoch nur 8 Byte groß. TExtended80Rec ermöglicht unter Win64 die Durchführung von speicherbezogenen Operationen mit 10-Bit-Gleitkommavariablen, aber keine arithmetischen Operationen mit der Genauigkeit "extended".

[JamesTKirk]

Free Pascal verfügt über eine "SoftFPU" Unit, welche es letztendlich erlauben soll 32, 64, 80 und 128 Bit Operationen in Software durchzuführen (mit dazugehörigen Datentypen). Die Unit soll letztendlich dazu verwendet werden, um von Systemen, die keinen 80-Bit Datentyp unterstützten (x86_64, ARM), auf Systeme zu kompilieren, die das tun (x86). Das Problem ist nämlich, dass Konstanten vom Compiler immer mit der höchsten für die Zielplattform verfügbaren Genauigkeit evaluiert werden sollten. Von x86 nach x86_64 ist das kein Problem, da der Compiler dann einfach nur mit der 64-Bit Genauigkeit evaluiert, aber von x86_64 nach x86 ist das problematisch, da ersterer nur bis 64-Bit Genauigkeit anbietet. Dies kann im Worstcase zu Programmen führen, die sich unterschiedlich verhalten je nachdem ob sie nativ unter x86 oder cross kompiliert wurden. Das darf natürlich nicht sein.
Die Unit basiert auf C-Code und ist leider noch nicht komplett konvertiert (nur die 32 und 64 Bit Operationen sind bereits konvertiert).

Gruß,
Sven

[Lemmy]

Zitat:

Zitat von Micha88 (Beitrag 1135288)

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

um Anwendungen zu schreiben, die nur ein leeres Formular beinhalten ist Delphi mit ziemlicher Sicherheit kein gutes Werkzeug... ;-)

Wobei mich schon brennend interessieren würde woher der massive Anstieg von XE kommt...

[Bernhard Geyer]

Zitat:

Zitat von Micha88 (Beitrag 1135288)

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

Debug-Infos und Erweiterte RTTI abschalten und schon wirds um einiges kleiner.