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

[s.h.a.r.k]

Aber als Linuxer muss man Google weit aus mehr befragen, als ein Windows-User

[Valle]

Zitat von s.h.a.r.k:

Aber als Linuxer muss man Google weit aus mehr befragen, als ein Windows-User

Das mag sein, aber ich war mir eigentlich recht sicher, dass himitsu was anderes meinte, deswegen hielt ich das nicht für nötig. Außerdem wollt' ich auch mal bisschen klugscheißen, ja?

Liebe Grüße,
Valle

[Horst_]

Hallo,

es gibt doch noch das shootout Spiel:
64-Bit:
http://shootout.alioth.debian.org/u6...p?lang=fpascal

Code:

Program     N    CPU secs   Elapsed secs   Memory KB   Code B
binary-trees     12   0.13   0.13   ?   769
binary-trees     16   2.06   2.08   7,192   769
binary-trees     20   44.93   44.93   131,420   769

32-Bit:
http://shootout.alioth.debian.org/u3...p?lang=fpascal

Code:

Program    N    CPU secs   Elapsed secs   Memory KB   Code B
binary-trees     12   0.10   0.11   ?   769
binary-trees     16   1.60   1.60   4,176   769
binary-trees     20   36.44   36.44   65,684   769

64-Bit ist langsamer, es wird ja auch die doppelte Datenmenge bewegt.
Wenigstens ist 64-Bit bei k-nucleotide 25,000,000 wirksam/ ohne Fehler im Ablauf.

Ein Vorteil von 64-Bit ist der Umstand, dass die 1 Gbyte Grafikkarte Dir nicht den Hauptspeicher um diese Größe eindampft, weil nun in einem Adressbereich oberhalb 4 GByte liegen kann, jedenfalls waren bei mir 3,9 Gbyte frei statt 3,5 Gbyte (ja nur eine kleine Grafikkarte ).
Programmtechnisch könnten die 8 zusätzlichen CPU-Register etwas beschleunigend wirken, wenn die Kompiler das auch nutzt und auch alle Daten schön aligned ausrichtet sind.

Gruß Horst

[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. Unter Windows hat jeder Prozess seinen eigenen, geschützten Adressraum. Dieser ist genau 2^32 GB groß. Da aber ein Prozess nicht aus seinem Adressraum so einfach rauskommt, er aber natürlich die Betriebssystemfunktionen braucht, werden diese in seinen Adressraum eingeblendet. Dem Betriebssystem steht dazu die Hälfte des Adressraumes zu: 2GB. Demzufolge kann ein Prozess über die restlichen 2GB frei verfügen. Mit einem Schalter kann man den frei verfügbaren Adressraum für einen Prozess auf 3GB vergrößern. Dies ist aber nicht zu empfehlen, da dann für das Betriebssystem nur noch 1GB übrig bleiben.

So, womit ich mich noch nicht beschäftigt habe, ist wie der Adressraum und dessen Verwaltung unter 64-Bit aussieht. Wenn ich da mal was gescheites zu lesen finden würde im Internet oder so, wäre das eine schöne Sache. Sehe gerade ist genauso: halbe/halbe. 16TB davon 8TB für das Betriebssystem und 8TB für den Prozess.
http://msdn.microsoft.com/de-de/library/bb978906.aspx

Was jetzt interessant wäre bei der Geschwindigkeit: Ist das gleiche Programm einmal als 64-Bit unter einem 64-Bit OS schneller als 32-Bit unter einem 32-Bit OS.

[Bernhard Geyer]

Es ist eigentlich nebenwirkungsfrei einem 32-Bit Prozess (hier D6 mit FastMM) per Compilerflag eine 3GB-Adressierung zu ermöglichen. Was problematisch ist, in einem 32-Bit Windows diese Adressierung freizuschalten, da es genügend HW-Treiber für Win32 gibt die damit nicht klar kommen.

Für uns war mal dieser Schalter die einzige Möglichkeit ein Problem per Hotfix zu lösen. Normalerweise lassen wir aber das Programm mit max. 2GB laufen. Selbst bei größeren DB's im 2stelligen GB-Bereich kommt unsere Programm sehr selten über 100-200 MB Speichernutzung.

[Luckie]

Zitat von Bernhard Geyer:

per Compilerflag eine 3GB-Adressierung zu ermöglichen.

Dann muss aber auch Windows mit dem entsprechenden Flag gestarte werden:

Zitat:

Virtual Address Space für 32-Bit-Prozesse: 2GB (3 GB, wenn das System mit Option /3GB gestartet wurde)

[FAlter]

Hi,

auch mal was sagen...

Zum Thema 32-Bit-Programm mit mehr als 2 GB (in die DPR):
{$SetPEFlags $20} //IMAGE_FILE_LARGE_ADRESS_AWARE Achtung: Der Standard-Memorymanager von Delphi < 2006 rechnet mit Vorzeichen!

Zum Thema Adressraum:
Unter 64-Bit ist physikalische = logische Adresse. Speichersegmentierung gibt es nicht mehr.

Gruß
FAlter

[Luckie]

Speichersegemente gab es auch unter 32-Bit nicht mehr. der Adressraum ist linear ansprechbar. Nur gibt es unter 64-Bit keinen virtuellen Adressraum mehr, deswegen gilt, wie du sagst physikalische Adresse = logische Adresse.

[Bernhard Geyer]

Zitat von FAlter:

Achtung: Der Standard-Memorymanager von Delphi < 2006 rechnet mit Vorzeichen!

Könnte sein. Da wir aber seit Jahren auf FastMM angewiesen sind (Fragmentierungsproblem des alten Speichermanagers) ist uns das nicht aufgefallen.

[Horst_]

Hallo,

www.ece.neu.edu/students/dye/papers/iiswc06.pdf zeigt einen Vergleich von 64-Bit/32-Bit in der Anwendungsperformance und die Gründe für die Vor/Nachteile.
Wenn viel FPU Rechnerei vorliegt und/oder viele Register von Vorteil sind -> 64-Bit.
Die meisten Anwender werden nicht über mehrere Gigabyte gleichzeitig verarbeiten müssen, aber wer weiß, es reichen ja 640 kByte

Gruß Horst