scientific computing: mehr als 4 GB RAM nutzen!?

[xcs]

Hallo,

mein Problem ist sehr speziell. Hoffe, jemand kennt sich damit aus.
Ich habe mit Delphi ein Programm für wissenschaftliche Berechnungen geschrieben - sowas wie FEM bzw. Reaktions-Diffusions-Gleichungen aus der Chemie etc.
Mit leistungsstärkeren Prozessoren kann ich nun die Berechnungen genauer machen, d.h. ich bekomme eine höhere räumliche Auflösung.
Problem: obwohl der Rechner 64 GB RAM hat, zeigt das Programm an "Zu wenig Arbeitsspeicher", wenn mehr als 4 GB in den Speicher geladen werden sollen.
Das liegt sicher daran, dass meine Delphi.Version (2006) nur einen 32-Bit-compiler hat.
Aber auch Delphi XE soll nur einen 32-Bit-Compiler haben!
Damit ist es unmöglich, mehr als 4 GB zu nutzen.

Habt ihr eine Idee, wie ich es trotzdem machen könnte? Gibt es schon 64-Bit-Compiler? Gibt es einen Trick oder eine Erweiterung?
(Anmerkung: Nein, ich kann das Programm nicht so optimieren, dass ich < 4 GB brauche)

Danke

[mkinzler]

-Delphi XE2 soll einen 64Bit-Compiler bekommen
-FPC/Lazarus
-PAE

[Memnarch]

ne richtig schmutzige methode wäre, das dein Hautprogramm ein subprogramm pro benötigtes Gigabyte(oder 4GByte) erstellt. Per pipelines/TCP kommuniziert dein Programm zwischen sich und den MemoryNodes. Jede node sollte so für sich 4GByte allokieren können.

Allerdings weiß ich nicht inwiefern die Daten bei dir gestreamed werden können.


MFG
Memnarch

[s.h.a.r.k]

Im Moment würde ich dir den FreePascal-Compiler nahe legen, so wie mkinzler schon gesagt hat.

Ob XE2 einen 64-Bit Compiler enthalten wird, glaube ich erst, wenn ich es in den Händen halte

[Assarbad]

Es gibt noch eine Methode die auch auf 32bit Funktioniert. Man kann eine MMF benutzen, in der immer nur ein Stück gemappt wird, so daß man nie den Adressraum ausschöpft. Macht natürlich die Programmlogik nicht gerade einfacher ...

Übrigens, wenn du diese Methode mit der von Memnarch vorgeschlagenen kombinierst, könntest du noch besser wegkommen, insofern sich deine Berechnungen parallelisieren lassen. Denn: jeder einzelne Prozess hat 4 GiB Adressraum (wovon natürlich normalerweise nur 2 GiB für den UM bereitstehen). In dem Fall hast du eben nicht mehrere Threads im gleichen Prozess die an den Daten werkeln, sondern mehrere Threads in mehreren Prozessen. Damit haste dann (wie gesagt, wenn denn parallele Bearbeitung überhaupt geht) dann die Parallelisierung auch gleich abgedeckt.

[mkinzler]

Wenn es nur um Daten geht wäre hier PAE besser, ich weiss nur nicht, wie/ob das mit Delphi funktioniert

[Assarbad]

Zitat von mkinzler:

Wenn es nur um Daten geht wäre hier PAE besser, ich weiss nur nicht, wie/ob das mit Delphi funktioniert

Hier würfelst du scheinbar etwas durcheinander. PAE bedeutet nur, daß die CPU alles bereitstellt, damit der Kernel auch im 32bit-Adressmodus auf mehr als 4 GiB RAM zugreifen kann. Treiber müssen entsprechend darüber bescheidwissen. Anwendungen hingegen sehen nach wie vor nur 4 GiB (pro Prozeß).

Siehe: http://de.wikipedia.org/wiki/Physical_Address_Extension

Zitat:

Der in einem Prozess bzw. einem Task nutzbare Speicher ist jedoch weiterhin auf 4 GiB begrenzt, sofern man ein lineares Speichermodell („flat memory“) verwendet, da die verwendeten Adressregister nur 32 Bit breit sind.

[mkinzler]

Die 32Bit Version von MSSQL kann damit aber mehr als 4GByte verwenden ( bei einem 64Bit OS)

[Assarbad]

Zitat von mkinzler:

Die 32Bit Version von MSSQL kann damit aber mehr als 4GByte verwenden ( bei einem 64Bit OS)

Ich habe keinen Bock es zu reversen, aber ich bin mir ziemlich sicher, daß dabei der angesprochene Trick mit den MMFs zur Anwendung kommt. Mehr als 4 GiB gleichzeitig innerhalb eines (32bit-)Prozesses geht nämlich einfach nicht, egal was irgendwelche Quacksalber dir verkaufen/verkauft haben ...

Aber welche Version ist es denn, die du meinst? Kann gern mal reinschauen. Glaube aber irgendwie nicht, daß es 32bittige Prozesse sind, wenn doch schon die Anforderung 64bit-OS existiert.

[mkinzler]

Nein, die verwendete Software (Datev) unterstützt keine 64Bit Version des SqlServers ( solange sie noch 32Bit unterstützen, wegen Testaufwand). Früher wurden mehrer Instanzen eingesetzt nun raten sie davon ab und bieten die genannte Version ein (MSSQL 2005 SE).