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

[Elvis]

Zitat:

Zitat von Delphi-Laie

Zur Zeit interessiert mich der Geschwindigkeitsvorteil von 64 gegenüber 32 Bit. Den festzustellen kommt zur Zeit ja nur Lazarus infrage.

Freepascal taugt für diesen Vergleich leider nicht viel. Nicht wenn du daraus schließen willst, was dich mit Delphi64 erwarten wird.
Denn FPC64 scheint nicht großartig anderen Code zu erzeugen als die 32Bit Variante. Es wird nicht "aggressiv" für die Register und den Befehlsatz optmimiert, den man auf AMD64 CPU voraussetzen kann.
Ein Delphi64 compiler würde höchstwahrscheinlich besseren Code erzeugen. Aber das wissen wir erst wenn er da ist, und wenn er 5 Jahre später die meisten Kinderkrankheiten losgeworden ist.

Wenn du also wirklich jetzt wissen willst was dir x64 bringt, wäre wohl eine Test suite für einen Compiler, der x64 auch tatsächlich nutzt, angemessener.
Pascal Code kannsu da natürlich nicht erwarten.

[Delphi-Laie]

Zitat:

Zitat von hoika

Hallo,

Zitat:

Darf ich fragen, welche Einstellung(en)?

Warum sind Leute immer so faul zum suchen ?

Eine Google-Suche "windows 3GB" bringt mir

1


PAE suchen bringt was zur Programmierung


Heiko

Den Faulheitsvorwurf verbitte ich mir und weise ihn brüsk zurück!

Lesen Sie mal bitte, was oben geschrieben wurde:

Zitat:

Zitat von himitsu

"Bernhard Geyer

Zitat:

Zitat von himitsu

Und was noch ein Vorteil wäre:
- über 2 GB Arbeitsspeicher

Eher 3 GB. Man kann einem 32-Bit Prozess über Einstellung im Compiler mitteilen das die Exe auch mit 3GB lauffähig ist.

Die exe! Und so suchte ich natürlich - wo auch sonst?! - in den Compileroptionen meiner Delphis (!) bis hinauf zum Turbo-Delphi nach einer mir bis dato unbekannten 3-GByte-Einstellung/-Option. Natürlich Fehlanzeige.

Die 3-GByte-Startoption kenne ich schon lang und verwende sie auch seit geraumer Zeit. Jedoch werden, soweit mir bekannt, damit nur der gesamten Anwendungssoftware (also wohl den Programmen, die im Usermodus laufen) die 3 GByte zugewiesen, die 2-GByte-Schranke gilt dennoch für jedes Programm.

Also erlaube ich mir, meine Frage zu wiederholen: Wo bitteschön kann man dem Compiler mitteilen, daß die Exe-Datei 3 GByte nutzt?

Edit: FastMM scheint wohl das Stichwort dazu zu sein.

[himitsu]

FastMM oder ein beliebiger SpeicherManager, welcher damit umgehen kann
UND der PF-Flag, welches die Speicherverwaltung seitens Windows (z.B. VirtualAlloc) dafür freischaltet.
Grund:
"Früher" wurde oftmals ein ungültiger Pointer durch (P < 0) gekennzeichnet und/oder oder das oberste Bit für Statusinformationen mißbraucht (dieses Bit konnte ja eh nicht für die Speicherverwaltung verwendet werden).

Darum sperrt Windows erstmal die Nutzung dieses Bits, damit die "älteren" Programme auch noch lauffähig sind.
Programme, welche aber dieser Einschränkung nicht unterliegen, können Windows über das PE-Flag ( {$SetPEFlags $20} ) dieses mitteilen und kommen dann in den Genuß dieser erweiterten Möglichkeiten.

[JamesTKirk]

Zitat:

Zitat von Luckie

Also unter 32-Bit kann man 2^32 Adressen ansprechen und das sind 4294967296 Stück. Mehr Speicher kann ein 32-Bit OS nicht verwalten.

Das ist so nicht ganz korrekt... es gibt nämlich die Physical Address Extension, die ausnutzt, dass 32-Bit Prozessoren einen 36-Bit breiten Addressbus besitzen. diese Erweiterung gilt allerdings nur für den vom OS verwaltbaren Arbeitsspeicher, nicht aber für den Prozessadressraum.

Gruß,
Sven

[Insider2004]

Ich rate dringend davon ab, über 2GB zu gehen. Der Schalter ist nicht ohne Grund optional und versteckt. Sonst hätte ja Borland den per default eingebaut. Es ist durchaus möglich, dass 99% des Codes schön mit 3GB laufen, Aber wehe, ein Programteil castet einen Pointer. Dann wird der Pointer verbogen und zeigt irgendwo hin. Das Programm verabschiedet sich.

[Micha88]

Wirkt sich eine Performancesteigerung auch auf das Arbeiten mit größeren Werten als Int64 aus? Mir schwebt da z.B. Extended vor.

[Medium]

Extended war bereits ein ein Register breit, und der Datentyp ist eigentlich auch mehr ein Hack, da dies nur das FPU interne Format sein sollte. Vor allem: FPU! Ob die ALU dabei 64 Bit, 32 16 oder 8 hat ist der prinzipiell erstmal egal. Einzig, wenn man Floats durch die CPU Register schubsen muss helfen die 64 Bit, aber dann auch nur bei Double so wirklich. Kurzantwort also: Nein, Langantwort: In konstruierten Ausnahmefällen in Nuancen vielleicht, aber für die Praxis wohl nicht relevant.

[Stevie]

Zitat:

Zitat von Micha88 (Beitrag 1135140)

Wirkt sich eine Performancesteigerung auch auf das Arbeiten mit größeren Werten als Int64 aus? Mir schwebt da z.B. Extended vor.

Der Witz an der Sache ist sogar, dass Extended unter 64-bit auch nur noch 8 Byte groß ist und nicht 10, wie unter 32-bit.

Nen bisschen was über 64-bit und floating point Performance kann man bei Eric Grange auf dem Blog lesen:

http://delphitools.info/2011/09/02/f...t-performance/

http://delphitools.info/2011/09/05/x...isappointment/

http://delphitools.info/2011/09/09/h...precision-off/

[Micha88]

Zitat:

Der Witz an der Sache ist sogar, dass Extended unter 64-bit auch nur noch 8 Byte groß ist und nicht 10, wie unter 32-bit.

Mh. Das heißt, die Zahlen sind wohl kleiner.

Was sollte man bei XE2 statt Extended denn dann wohl besser nehmen?

[BUG]

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: