Speichertricks: Alles im RAM

@PC-Welt: leider funktioniert das Drucken nicht :
The web site you are accessing has experienced an unexpected error.
Please contact the website administrator.

The following information is meant for the website developer for debugging purposes. Error Occurred While Processing Request The element at position 2 of dimension 1, of array variable "STMPTABLEARRAY," cannot be found.


Resources:

• 
  [*]Enable Robust Exception Information to provide greater detail about the source of errors. In the Administrator, click Debugging & Logging > Debugging Settings, and select the Robust Exception Information option.
  [*]Check the ColdFusion documentation to verify that you are using the correct syntax.
  [*]Search the Knowledge Base to find a solution to your problem.

Browser Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 Remote Address 127.0.0.1 Referrer http://www.pcwelt.de/know-how/tipps_tricks/betriebssysteme/windows/speicher/130363/index.html Date/Time 15-Mar-07 11:09 PM

 

Auch wenn ich mich mit der unterschiedlichen Struktur der BS nicht besonders gut auskenne:
Macs sind deshalb stabiler, weil viel Software für sie nicht angeboten wird oder diese direkt von Apple, Adobe o.ä. kommt. Bei Windows Server sind bestimmte Hardware Komponenten nicht erlaubt und wahrscheinlich gibt es auch bei der Software Einschränkungen. Die laufen wesentlich stabiler - einfach weil man potentiellen Störfaktoren den "Zutritt verweigert". Dies läßt sich in geringerem Umfang (und aus anderen Gründen) möglicherweise auch auf den Mac übertragen.
Der Hardwaremarkt liefert häufig Treiber ausschließlich für Windows, evtl. noch Mac, bei Linux ist man meist auf Fremdentwicklungen angewiesen von Firmen oder Personen die Ihre Eigenentwicklung bereitstellen. Da hier bei der Programmierung eventuell nicht alle Details bekannt sind oder berücksichtigt werden (können) sind unter diesem Aspekt sicher auch Probleme vorprogrammiert.
Die vielgerühmte Stabilität von Linux bricht ein sobald die gesamte grafische Oberfläche geladen wird und dort gearbeitet oder gespielt wird. Dann kann Linux langsamer und weniger stabil werden als Windows. Stabilität hat man dann, wenn man sich auf Kernfunktionen beschränkt und keine Experimente macht, bei Linux vorzugsweise auf der Konsole.

Das Swappen unter Windows betreffend mag es BS-spezifisch noch Verbesserungsbedarf geben, auch einige MS-Produkte verusachen den einen oder anderen Hänger oder Absturz, meine Erfahrung ist aber, daß es häufig banale Gründe wie mangelnde Kühlung, falsche Treiber oder fragmentierte und volle Festplatten sind, die den PC ausbremsen - oder schlecht programmierte Anwendungen.

 

Naja, Macs basieren auf einem Unix Kernel IIRC, das könnte auch was ausmachen. Die eingeschränkte Hardware Auswahl trägt sicherlich einen großen Teil zur Stabilität und Geschwindigkeit von OS X bei.
Wichtige Software gibt es aber unter OS X und unter XP, Linux nur selten (oder auf Anfrage... es gibt eine Cinema 4D Version für Linux... auf Anfrage für große Filmstudios anscheinend. Warum? Zu problematisch die Vielfalt von Linux zu unterstützen?).
OS X läuft denke ich ein wenig besser, wobei Windows, wenn richtig behandelt, gar nicht mal so übel ist. Dennoch kommt OS X trotz der selben Anwendungen mit Auslagern deutlich besser klar, und das obwohl das OS selber schon ein riesiger Speicherfresser ist. Unter 1 GB ist es nicht wirklich sinnvoll, Windows XP kann man auch mit 512 betreiben. Aber im Fall des Falles...

 

BS-spezifische Benchmarks beim Swappen kenne ich nicht, sicher auch weil ich sie nicht benötige, deshalb kann ich Unterschiede dort auch nicht einschätzen oder beurteilen.
Ich kann jedoch ein Beispiel liefern an dem die Notwendigkeit deutlich wird, daß Anwendungen den Speicherzugriff optimieren.
Ich hatte in den letzten Jahren einen Rechner, der lief mit 512MB RAM. Ich musste Dateien bitweise Scannen, die mehrere GB groß waren und die Analysedaten in Datenbank und per PHP in HTML ausgeben. Da der lokale Server auf dem Rechner laufen musste (mit Apache, PHP und MySQL), der Browser laufen musste und zusätzlich die Datenberechung Speicherplatz benötigte, konnte ich nicht einfach die Datei in den Speicher laden, dort berechnen und die Ergenbnisse ausgeben, wie viele Anwendungen es normalerweise machen - alleine die Daten waren ja 4x so groß wie der Speicher. Ich habe die Datei Blockweise eingelesen und die Blöcke direkt ausgewertet, dadurch habe ich auf einem veralteten Rechner innerhalb von 15-20 Minuten 2 GB mit mehreren regulären Ausdrücken durchkämmt. Alle Funktionen mussten darauf hin erstellt werden, daß die Blöcke einzeln untersucht werden können und Ergebnisse auch gleich ausgegeben werden. Dadurch war die Funktion quasi streamingfähig und der Speicherbedarf war sehr niedrig, da keine Daten gesammelt wurden (bis auf wenige Arrays für eine Gesamtübersicht).
Wäre das ganze in einem compilierten Programm abgelaufen, wäre die benötigte Zeit wahrscheinlich noch wesentlich kürzer gewesen.
Bei Textprogrammen kann man beobachten, daß meist versucht wird jede noch so große Datei in den Speicher zu laden, ist der zu klein wird sofort ausgelagert anstatt den Speicherbedarf durch selektierte Auswahl der einzulesenden Daten zu reduzieren. Von Notepad bis Ultraedit kenn ich keinen Texteditor der diesen "Fehler" nicht aufweist, bei großen Dateien sinkt die Bearbeitungsgeschwindigkeit überproportional. Ein positives Programmbeispiel für optimierten Datenzugriff ist WinHex (Hexadezimal-Editor). Auch bei großen Dateien bzw. Datenträgern erlaubt es raschen Zugriff, schnelles Scrollen und Suchen. Lediglich bei sehr großen Dateien kann es sein, daß die Offsetberechnung versagt (ab mehreren GB). Auch bei der Grafikbearbeitung gibt es Methoden, den Speicherbedarf zu reduzieren: Corel hatte schon sehr früh die Möglichkeit angeboten nur einzelne Bildteile in voller Größe in den Speicher zu laden, Adobe hält im Speicher teilweise nur eine reduzierte Auflösung für die Bildschirmansicht und überträgt die Änderungen erst beim Speichern auf das Original.

Lange Rede, kurzer Sinn: Die meisten Programme sind starr und unflexibel. Während Speichermöglichkeiten und Datenmengen immer größer werden, sind viele Programme immer noch auf relativ kleine Datenmengen ausgelegt, die man in einem Stück im Hauptspeicher bearbeiten kann.
Dies ist sicher nur ein Aspekt, der Einfluß auf den Speicher hat. Allerdings läßt sich dieses Beispiel auch von Laien recht schnell ohne Hilfsmittel prüfen: öffne einfach mal eine Datei mit 500MB Größe ein einem Editor - da kann man schon mal ein Päuschen einlegen, und Arbeiten in dieser Datei ist quasi unmöglich.

 

Hallo ich wolte mal fragen ob der Treiber Ewf.SYS
evtl auch in Windows Server 2003 lauffähig ist bzw in einer Windows XP 64 Bit Version?