VC++ 6.0 mit RAM Drive

[Woerns]

Ich habe es irgendwo gelesen, dass sich einer ein virtuelles Laufwerk eingerichtet hat, um das Kompilieren zu beschleunigen. Da das Visual Studio bei jedem Kompilat alle Files auf Platte schreibt und von dort auch wieder liest, kann ich mir vorstellen, dass es eine ziemliche Beschleunigung sein kann, weil der Plattenzugriff wohl ein Flaschenhals ist.

Hat das mal jemand ausprobiert? Und wenn ja, wie groß sollte der RAM Drive sein, wie richtet man den überhaupt ein unter XP Prof? Wie bewegt man das Visual Studio dazu, vornehmlich auf dem RAM Drive zu arbeiten, schließlich müsste man ja am besten auch gleich die gesamten MFC Sourcen dort lagern? MfG

[flybyray]

... was da in den tiefen des forums an unbeantworteten fragen schlummert. 8)
Darf ich einfach mal mit 42 antworten? ;D

Hat sich das damals wirklich gelohnt? Heute mit wesentlich mehr Arbeitsspeicher und einem Windows XP das nur 3GB nutzen kann wäre es cool wenn man das verlorene 1 GB als Laufwerk für die Auslagerungsdatei Nutzen könnte.

Ob und wie das geht kann man hier nach lesen.
4Gb-Ram unter XP nutzbar machen (http://www.computerbase.de/forum/showthread.php?t=305236&highlight=gavotte&page=7)

Gibt aber auch noch andere nützliche Seiten, vielleicht auch was von Planet3dNow (so genau hab ich nicht nachgeschaut.)
search@groups.google.de (http://groups.google.de/groups/search?hl=de&ie=UTF-8&oe=utf-8&q=gavotte+ramdisk&btnG=Suche&sitesearch=)

[andr_gin]

Bringt sich heute nicht mehr wirklich viel. Vista macht das alles schön brav im Hintergrund bei der x64er Version. Da bleibt alles so lange im Cache, bis der Platz wieder gebraucht wird. Bei wenig RAM (<=2GB) tötet das zwar die Performance des ganzen Systems, aber mit 8GB funktioniert das richtig schön. Wer wirklich mehr als ein paar 100 MB an Source Code auf einmal kompiliert, der kann sich meistens auch schon eine entsprechende Workstation leisten und füllt die an bis zum geht nicht mehr.

[TiKu]

Hat sich das damals wirklich gelohnt? Heute mit wesentlich mehr Arbeitsspeicher und einem Windows XP das nur 3GB nutzen kannDas liegt nicht an Windows XP, sondern an der Rechnerarchitektur.

[flybyray]

Das liegt nicht an Windows XP, sondern an der Rechnerarchitektur.
Welche Rechnerarchitektur verwendest du denn? *suspect*
Ich habe noch nie etwas von einem 31,584962500721156181453738943948 bit breiten Adressbus gehört. ;D

Es liegt nicht an der Rechnerarchitektur! Eher an einer Softwarearchitektur.
Normal kannst du mit einem 32bit Adressbus auch 4GB adressieren.
Microsoft´s 32bit Systeme haben das aus Gründen der Kompatibilität (?ich glaube älteres BIOS oder so?) einfach nicht unterstützt, die vollen 4GB zu verwenden.
"Mit Linux wäre das nicht passiert!" ;D Jedenfalls gibt es 32bit Linux Versionen die es unterstützen 4 GB anzusprechen.

[TiKu]

Der Adressraum ist auch 32 Bit breit. Nur wird damit nicht nur der RAM adressiert, sondern auch Geräte - und das unabhängig vom verwendeten 32-Bit-Betriebssystem. Wenn du also eine Grafikkarte mit 512 MB hast, kannst du noch 3,5 GB RAM adressieren. Davon werden dann noch weitere Geräte abgezogen.

Zu Linux: Da wird dann die Krücke PAE genutzt. Kann Windows auch (die Serverversionen). Nur müssen dazu die Treiber mitspielen und das BIOS muss es glaube ich auch explizit unterstützen.

[PuckPoltergeist]

Der Adressraum ist auch 32 Bit breit. Nur wird damit nicht nur der RAM adressiert, sondern auch Geräte - und das unabhängig vom verwendeten 32-Bit-Betriebssystem. Wenn du also eine Grafikkarte mit 512 MB hast, kannst du noch 3,5 GB RAM adressieren. Davon werden dann noch weitere Geräte abgezogen.

Zu Linux: Da wird dann die Krücke PAE genutzt. Kann Windows auch (die Serverversionen). Nur müssen dazu die Treiber mitspielen und das BIOS muss es glaube ich auch explizit unterstützen.
Vorsicht, nicht physikalischen Adressraum mit Prozessadressraum zusammen schmeißen. Auch mit PAE lässt sich Speicher nicht ansprechen, der von Geräten verdeckt wird. Zumindest wäre mir das neu. PAE ermöglicht es lediglich, insgesamt mehr als 4GB RAM zu verwalten. Dabei ist mal aber immer noch auf 4GB pro Prozess beschränkt. Und ich wüsste jetzt auch nicht, dass PAE den Adressraumsplit aufhebt. Das heißt, die 4GB teilen sich immer noch jeweils Prozess und Betriebssystem.

[flybyray]

Ja stimmt, das mit den Geräten habe ich vergessen. Wie Geräte in den verfügbaren Adressraum integriert werden hängt dann stark von den Treibern und Biosen ab.
Würde man zum Beispiel für diese fetten (bezieht sich auf den Speicher der) Grafikkarten von heute ausschließlich ältere VESA-Treiber verwenden, dürfte es da nur eine minimale Verwendung des Adressraums geben und wirklich beinahe volle 4GB zur Verfügung stehen.

Dieses PAE macht glaube ich eh kaum Sinn für normale Tätigkeiten am Rechner. Bei Virtualisierung unter einem 32 Bit System kann man das vielleicht gut ausnutzen wenn man mehr als 4GB im Rechner hat.

[TiKu]

@Puck: Richtig. Man braucht wenn schon PAE + dieses Address Space Relocation oder wie sich das schimpft (wird von manchen BIOSen angeboten).

[PuckPoltergeist]

@Puck: Richtig. Man braucht wenn schon PAE + dieses Address Space Relocation oder wie sich das schimpft (wird von manchen BIOSen angeboten).
Gibts das? Ich kenne das nur in Verbindung mit x86_64. Weil, sofern ich mich jetzt nicht total irre, braucht es mehr als 32bit um das aus der Applikation adressieren zu können.

[flybyray]

hm vielleicht ist ja da in den 32bit rechnerarchitekturen noch etwas aus 286er zeiten vorhanden. 2x16bit wurden so überlagert das man physikalisch 20bit adressieren konnte. ;D
wie wurde damals eigentlich so erweiterungsspeicher EMS XMS oder wie die noch alle hießen adressiert?

[TiKu]

Gibts das? Ich kenne das nur in Verbindung mit x86_64. Weil, sofern ich mich jetzt nicht total irre, braucht es mehr als 32bit um das aus der Applikation adressieren zu können.Hmm, so ganz sicher bin ich mir da auch nicht.