Delphi vs Visual C++

[Assarbad]

Zitat von himitsu:

Ich hab dem Windows hier gesagt, es soll den RAM "vorzugsweise" für Programme nutzen, aber dennoch wird die WFC bevorzugt.
12 Kerne und auch 64 GB RAM

Diese Annahme geht dem grundlegenden Design von Windows aber zuwider. Du kannst zwar in die eine oder andere Richtung lenken, aber du kannst keine tiefergehenden Entscheidungen des MM beeinflussen. Im Benutzermodus haste ohnehin keinen Zugriff auf den echten Speicher, es sei denn ein Treiber gibt dir irgendwie Zugriff. Allerdings ist auch der Speicher den Treiber anfordern können begrenzt. Wobei eben der NonPagedPool (also Speicher der nicht ausgelagert wird) noch immer nicht der echte RAM ist, sondern noch immer eine Abstraktion des physischen Speichers bei welcher die CPU mithilft. In den meisten Fällen spielt das aber keine Rolle, weil der MM zwar faul konzipiert ist, bei Zugriff auf ausgelagerten Speicher aber fleißig wird. Und eine MMF ist nunmal quasi das Gegenteil der Auslagerungsdatei. Sozusagen eine Einlagerungsdatei von der aus Daten in den Speicher gescheffelt werden müssen.

Bei einem Problem mit derlei vielen Daten die im Speicher vorliegen müssen, könnte es auch hilfreich sein nachzudenken inwieweit die Daten komprimierbar sind ohne die Berechnung zu behindern. Buchempfehlung: "Programming Pearls" von Bentley.

RamMap von Sysinternals/Microsoft bietet übrigens einen guten Überblick über die aktuelle Speicherverwendung.

@BigAl: die eine FirePro von AMD ist glaub ich auch mit 32 GB RAM verfügbar.

Zitat:

Die S9170 verwendet den gleichen Grafikchip wie die S9150. Er stammt aus der Hawaii-Serie, enthält 2816 Rechenkerne und ist zu OpenCL 2.0, OpenMP 4.0 und OpenACC kompatibel; zum Nvidia-exklusiven CUDA freilich nicht.

[himitsu]

Nee, "direkten" Einfluss hat man eh nicht.
Es gibt da nur so 'nen Registry-Flag, womit man dem MM sagen können soll, was er "mehr" bevorzugen solle.

Aber wenn man schon 50 GB Cache im RAM liegen hat, dann wäre es nett, wenn der MM zuerst "älteren" Cache entsorgen würde, anstatt "jüngere" aktive Programme auszulagern, die ne halbe Minute später wieder zurück in den RAM geladen werden müssen.

Die Seitenfehler im DWM, im Explorer und im Delphi waren auch immer schön viele.
Arbeitsspeicher (privat) gegen Zugesicherte Größe sahen da im Taskmanager auch immer schön ungleichmäßig aus.



Und so sinnlose Programme, die sich RAM-Cleaner schimpfen, will auch keiner benutzen.

[BigAl]

[QUOTE=Assarbad;1354834]

Zitat von himitsu:

Bei einem Problem mit derlei vielen Daten die im Speicher vorliegen müssen, könnte es auch hilfreich sein nachzudenken inwieweit die Daten komprimierbar sind ohne die Berechnung zu behindern. Buchempfehlung: "Programming Pearls" von Bentley.

Windows komprimiert ja schon von sich aus. Im Taskmanager von Windows 10 (und 8 auch glaube ich) heißt es ja "In Verwendung (komprimiert)". Wenn ich die leere Matrix (alle Felder 0i0) im Speicher erzeuge, dann werden für die Größe mit 25.000 Elementen = 25.000 * 25.000 * 16 Byte = 1e+10 Byte (~9,3 GB) nur ein paar MB belegt. Erst wenn ich die "echten" Daten hole, dann bläht sich der Speicher auf. Leider handelt es sich nicht um eine dünnbesetzte Matrix. Da bringt komprimieren nicht viel...

Alex

[himitsu]

Wenn noch nichts in den Speicher geschrieben wurde, also nur Nullen drin stehen, dann reserviert/mappt Windows dafür keinen physichen Speicher.

[Assarbad]

@himitsu: https://en.wikipedia.org/wiki/Virtua...ry_compression ... ist in Windows 10 enthalten. Er meint sicher das. Man könnte es als das Gegenstück zu "sparse files" betrachten.

Und zumindest die Strukturen für die Buchhaltung dieser vielen Speicherseiten muß Windows bereits bereitstellen. Ich schätze mal, daß dies der beobachtete Overhead ist.

@BigAl: ich meinte eher weniger klassische Komprimierungsalgorithmen als clevere Methoden um deine Daten auf weniger Speicher abzubilden. Das Buch ist auf Deutsch unter dem Titel "Perlen der Programmierkunst" im Handel oder vielleicht bei einer Bibliothek in deiner Nähe erhältlich. Seitdem wir nämlich Speicher- und Plattenplatz im Überfluß zur Verfügung haben und uns ggf. zukaufen können, machen sich viele Entwickler keine Gedanken mehr über die Algorithmen. Dabei liegt dort oft das eigentliche Optimierungspotential.

[Rollo62]

Wie sieht eigentlich Bcc vs Vc aus ?

[Namenloser]

Eine ziemlich coole Sache in C/C++ ist übrigens auch OpenMP. Noch nie war Parallelisierung so einfach.

[BigAl]

Hallo zusammen,

ist ja doch eine recht rege Diskussion geworden. Folgende Fragen / Kommentare bleiben allerdings doch:

1. Was soll Komprimierung bringen? Das ist doch noch einmal zusätzliche Rechenleistung die benötigt wird, oder?

2. Ja, meine Matrix ist dicht besetzt. 0-Felder gibt es praktisch keine.

3. Über Multigrid habe ich schon oft nachgedacht. Allerdings bräuchte ich da ein Beispiel um es zu verstehen.

4. Karten mit viel VRAM wären nur interessant wenn die nach oben offen / erweiterbar wären oder ich eine Möglichkeit hätte meine Matrizen in Schritten zu berechnen. Je nach Feinheit der Berechnungen kann die Größe auch noch ansteigen...

5. Richtig interessant finde ich AMP. Da muss ich mich mal intensiver mit beschäftigen.

Alex

[Assarbad]

Zitat von BigAl:

1. Was soll Komprimierung bringen? Das ist doch noch einmal zusätzliche Rechenleistung die benötigt wird, oder?

Lies dir bitte nochmal meinen Vorschlag durch.

Wenn du eine Zahl als String und Dezimalzahl darstellst, ist die üblicherweise auch länger als der gleiche Wert als Hexadezimalzahl (ohne spezielle Formatierung) dargestellt. Das ist auch eine Form von Komprimierung.

Wenn du bspw. sechzehnbittige Dezimalzahlen hast und sollst bei Speichermangel herausfinden ob es Lücken in der Zahlenreihe gibt, kannst du wahlweise eine Liste mit 16-bittigen Einträgen bauen und diese durchsuchen (2 x 2^16 == 2 x 65536 == 131072 Bytes), oder du bastelst dir ein Bitfeld aus 65536 Bits (8192 Bytes) und setzt jedes Bit je nach Index (== Zahlwert) oder eben nicht. Und jetzt denken wir uns das mal mit 32-bittigen Werten und dann kommt es auch näher an die Größenordnung deines Problems.

Das ist auch eine Komprimierung ohne klassische Komprimierungsalgorithmen (Deflate, bzip2, LZMA, PPMd).

Aber selbst klassische Algorithmen können manchmal was bringen, bspw. beim Abspeichern auf der Platte und darauffolgendem Einlesen in den Arbeitsspeicher. Es ist nämlich manchmal deutlich flotter etwas im Speicher per Inflate (Brotli usw. kämen auch in Frage) zu dekomprimieren als die bereits dekomprimierte Menge Daten vom Festspeicher zu lesen. Kommt natürlich auf den Festspeicher an, bei einer SSD wären die Vorteile deutlich geringer als bei einer Festplatte. Aber das ist auch einer der wenigen Gründe warum EXE-Packer manchmal Sinn machen. Sie können tatsächlich das Laden eines großen Programms beschleunigen (auch wenn sie danach CoW verhindern und somit ab einer zweiten Instanz mehr Speicher verbrauchen).

Und es ist klar, daß solche Ansätze wie die oben genannten nur dann infrage kommen, wenn die Struktur deiner Daten das zuläßt. Aber du könntest ja mal ne Woche so tun als gäbe es noch keine Grafikkarten mit viel RAM und als hätte dein Rechner nicht soviel RAM und versuchen anhand dieser Einschränkungen nach Optimierungen zu suchen. Manchmal fällt es einem dann wie Schuppen von den Augen.

Das ist so ähnlich wie bei den Fragen in einschlägigen Foren und F&A-Seiten ala "Wie kann ich mit meinem Spannungsprüfer am besten diese Sechskantschraube mit Mutter in meine Wand bekommen?". Das eigentliche Ziel ("Bild an Wand befestigen") bleibt bei solchen Fragen ungenannt und der Fragesteller erwartet eine sinnvolle Antwort die seinen Vorgaben folgt.

Kurzum: schau über den Tellerrand.

(Es kann natürlich sein, daß es andere Sachzwänge gibt, die - ebenfalls ungenannt - bedingen, daß viele unserer Vorschläge unsinnig sind. Dann solltest du diese Sachzwänge erwähnen.)

Zitat von BigAl:

5. Richtig interessant finde ich AMP. Da muss ich mich mal intensiver mit beschäftigen.

Wenn du nach wie vor mit Linux liebäugelst ist dies eine Einbahnstraße.

[BigAl]

Zitat von Assarbad:

Kurzum: schau über den Tellerrand.

Das man komprimieren kann ist schon klar. Aber:

1. Speichermangel habe ich nicht. Hauptspeicher lässt sich (nahezu) nach belieben kostengünstig hochrüsten.
2. Laden und Speichern der Daten ist recht flott (10 GB Matrix etwa 10 Sekunden)
3. Den Zugriff möchte ich so effizient wie möglich halten. Es wird eine Adresse berechnet. In Delphi z.B.:

Delphi-Quellcode:

function TMatrixMMF<T>.GetValue(Y, X: Cardinal): T;
type
  P = ^T;
begin
{$IFDEF CheckRange}
  if (X >= FCountX) or (Y >= FCountY) then
    raise EMatrix.CreateFmt('TMatrixMMF<%s>.GetValue(Y=%d, X=%d). Parameter out of Range', [GetTypeName, Y, X]);
{$ENDIF}
  Result := P(UInt64(FMMFPtr) + (Y * FCountX + X) * SizeOf(T))^;
end;

In C++ sieht das bei mir dann halt so aus (ohne generischen Type):

Code:

std::complex<double>& MatrixMV::get_Value(UINT32 Y, UINT32 X)
{
  return  *(std::complex<double> *)((UINT64)m_pMapFile + (Y * m_SizeX + X) * sizeof(std::complex<double>));
}

Ich denke also alles Zusätzliche erhöht nur den Rechenaufwand. Obige Funktion ist nur ein Beispiel. Natürlich ist es effizienter im Programm direkt mit den Zielpointern zu arbeiten und nicht erst die Werte durch die Gegend zu kopieren...

Alex